Which versioning system is the simplest to use??

[Tom Huppi]

On 22:44 Tue 11 Sep     , David Christensen wrote:
> Agus wrote:
> > I am doing a little bit of security and log watching with sec.pl and
> > was trying to mantain de secconf files organized...  So whenever one
> > is changed it keeps track of the change and can rollback....
> > O that is what i am going to use de versioning sytem for...

This is just my experiance on this stuff.  There are no right or
wrong ways to do it, and happily, all kinds of altrnatives.

> If you only have a file or two, I'd suggest RCS.  "man rcs" should get you going.
> An earlier version of this book helped me understand RCS well enough to write
> custom scripts that used RCS on sets of files:
> 
>     http://www.oreilly.com/catalog/rcs/index.html

I've use RCS pretty religiously for system administration...but
in fact rarely do I actually refer back to older revisions in
practice.  I've always just refered to this document:

http://www.samag.com/documents/s=9367/sam9812a/9812a.htm

which has been enough to get me by.  The biggest hassle is the
$LOGNAME deal which can different depending on how one gets a root
shell.


> Then I heard about CVS, which uses RCS format archive files (so you can use
> either tool) and provides the set functionality I needed plus more.  "info cvs"
> is the online resource, but I did better with an earlier version of the book:
> 
>     http://cvsbook.red-bean.com/cvsbook.html
> 
> 
> I now use CVS to maintain version control of the configuration files on my
> various systems.  I build a CVS tree which is a sparse mirror of the root file
> system.  Whenever I want to change a configuration file in the "live" tree, I
> copy the intervening directories and/or file into the CVS tree, check everything
> in, make my changes, copy the changed filed back to the original location, test,
> and repeat the edit/ copy/ test sequence as necessary.  When all is well, I check
> in the file to CVS.  As a variation on a theme, I sometimes move the "live" file
> and replace it with a symbolic link into the CVS tree.  But this approach can be
> messier when you make a mistake and destabilize the system.  YMMV.  Using CVS in
> this way provides for the use cases you've identified, and it also allows me to
> check out the trees from other machines to compare/ contrast.  Best yet is when I
> rebuild a machine -- restoring configuration is a matter of installing CVS, check
> out the system configuration file tree, and copying/linking.

I tend to use revision control for (software) systems I
create or maintain installations of, but find it worthwhile
to create a Makefile to actually install the files (and often
the system itself.)  I find this more flexible in that I can
create different targets to do different things, structure my
repository differently than the destination, ensure proper
ownership and modes of the files, etc.  A script would work to,
but I happen to know gmake reasonably well.

CVS is pretty easy to set up and maintain, and works fine for
reasonable source trees in my experiance.  CVS is simple enough
so that all kinds of games can be played, but often these games
(like moving thing in the repository) invalidate revision
control at a basic level.  My experiance is that people figure
out what is possible some time before they figure out what
exactly they have done...but also that in practice, it rarely
matters.

> I suspect that there is are open-source projects that already do much or all of
> what I'm doing with CVS.  You might want to look or ask around -- try "tripwire".
> 
> 
> SVN is supposed to be a "better CVS", etc..  But as I understand it, SVN assigns
> a the same version number to every file in a set whenever any one of them
> changes.  I prefer the RCS and CVS approach of numbering each file independently,
> so I can easily determine which files in a set have changed and which haven't.
> This ability was critical for me when I was doing kernel/ device driver
> development and comparing/ using various FreeBSD, NetBSD, and OpenBSD source
> files.  At the time they all used RCS/ CVS numbering, so it was easy to see what
> files were the same and what were different between the platforms.

I much prefer SVN to CVS after using it some in the context of a
somewhat bloated repository...though I prefer it for small ones
as well.  I very much consider the revision scheme you mention a
feature rather than a bug.  It almost completely invalidates the
need for static tagging among other things.

SVN is considerably more complex to install and manage than CVS,
but not to bad with ports and a simple mode of access (of which
there are several.)

Many open-source projects are switching or starting out under
SVN these days, so that would be a choice factor...if I were
making the choice.

http://svnbook.red-bean.com/

Thanks,

 - Tom

> 
> 
> HTH,
> 
> David
> 
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 

--