[Infrastructures] RCS/CVS

Bob Proulx bob@proulx.com
Mon, 13 Jun 2005 10:55:44 -0600


Brendan Strejcek wrote:
> I prefer RCS to CVS for system administration. It is much simpler and
> easier to understand, which means it is less likely to get in the way.

It also means that your version control vault files are very close to
your source files.  This means more reliance on backup to recover from
a local oops.

Also, RCS is not network aware.  Using RCS to manage a local working
copy traditionally means relying upon NFS and symlinks of the RCS
directory to get to the repository.  That can be a much more
complicated system than one designed to be network aware.  Most
newbies find that to be confusing.

Of course many people just use RCS on live configuration files.  That
works very easy.  And at least it leaves a history behind after the
change.  But you would not want to do that for infrastructure
management.

> I also find that simply locking files is almost always what I actually
> want. For example, if I am editing DNS zone files, other sysadmins
> really should just wait, not take their own checkout and manage the
> merge later.

Of course we know that the zone serial number is always a merge
conflict on DNS zone files.  Fortunately that is also an easy one to
understand.

> I was left several CVS systems by a predecessor, and replacing them
> with similar RCS setups has resulted in a more understandable and less
> brittle system.

Since there is nothing inherently brittle about CVS I assume this is
referring to operational errors.  Which means the same could be said
for RCS or for any VCS.  People are people and people will make
mistakes.

One thing I miss when using RCS is the lack of hook scripts.  With CVS
(or Subversion or others) I have pre-commit checkers that double check
to make sure commits are good.  As an example, any changes to the
sudoers file for example must result in a sudo syntax clean result.
(e.g. 'visudoers -c -f newfile' must pass)  This helps to prevent
typical events before they become a problem.

> Further, teaching CVS to someone who has not used it for a development
> project is difficult, while teaching someone RCS is a snap.

I am not sure you are doing your newbies any real favors.  RCS was a
great system for its day.  But clearly the momentum of the world is
moving to a network aware, fully tree versioned, copy-modify-merge
solution.  Regardless of whether you love it or hate it knowing how to
drive these version control systems is almost manditory today and I
don't think this is going to change any time in the next ten years.
By avoiding it you are avoiding the day to day experience and learning
that comes from using it.

> Unless you really need advanced version control system features like
> branching or tagging, I would recommend RCS over CVS.

I disagree.  I believe the benefit from a nonlocal repository for the
master vault files is enough just by itself.  But also the other basic
features such as being able to update a working copy also weigh
heavily toward CVS.  Also the lack of features such as not being able
to list out who has RCS files locked.  (We have all written that
script three times.)  Being able to do true tree versioning has
dragged me to subversion.  Being able to do distributed versioning
pushes me to other tools.

This discussion could quickly become a my VCS is better than your VCS
discussion.  I don't mean to turn it that way.  I still use RCS for
some things.  I just think there are better options for doing
infrastructure adminstration.  But I agree it is a judgement call.
Today for infrastructure use I would recommend subversion for the best
all around feature set.

Bob