[TriLUG] Keeping track of system changes

[Aaron S. Joyner]

Mike M wrote:

>Well, CVS is descended from RCS.  CVS has a nice commit
>capability built-in that uses vi/vim by default.  As an ex-RCS user I
>agree that its no-overhead-get-started-now aspect is attractive.  But with a 
>few canned commands, you can be up and running with CVS and you'll be using
>a mainstream tool instead of a relic.
>  
>
I would have to say that RCS is far from a relic.  It's a simple tool 
for a simple job.  CVS is great for software repositories, as that's 
what it was designed for, but I think it's serious overkill for system 
configuration files.  Yes, CVS is descended from RCS, but almost 
exclusively in the theory-of-operation department, under the hood 
they're really different.  More below about specific concerns.

>If you use RCS much, you'll soon find out about hanging lock files.
>  
>
I use it constantly, ever day - and the last time I had a unresolved 
lock was probably a month ago (and it was a co-worker's fault, and 
easily resolvable).  Hanging lock files from not from using RCS, but 
from mis-using it.  :)  The wrapper script I use nicely takes care of 
those problems, by not only requiring that you check in a file as soon 
as you're done editing -- but by doing it for you!  In fact, it even 
keeps one of my co-workers who always constantly grumbles about having 
to use RCS (I require it at work), from ever really causing any 
problems.  He neglects to talk about the few times it's really saved his 
butt to be able to go back to a previous revision of a file.  :)

>You also have to check-out and check-in for every change.  There is the
>problem of changing a file before checking it out.  Then you have to
>save the changed file, co the file, diff and merge with the checkout
>file, then check in.  I guess you could always have your files checked
>out, but there are problems with that scenario.
>  
>
Leaving the files checked out and locked, mostly defeats the point.  Use 
a wrapper to prevent forgetfulness, always use it, and it becomes really 
easy.  If you forget to use cvim (my name for the wrapper, as in 
change-controlled vim) - the file which has been previously edited with 
cvim will be marked read-only.  Normal vim will complain when you 
attempt to modify a read-only file, and will warn you as soon as you 
do.  If you *really* have to make that change right then and there, go 
ahead and do it, forcibly write your changes, and then go back and run 
cvim.  It will detect that the file was modified outside of RCS, show 
you a diff of the changes, and ask if you'd like to commit them 
permanently, or remove the changes entirely.  Make your choice, and if 
appropriate it will ask you for a revision comment.  :)

>With CVS, you 
>import at time_0.  Then you checkout your module.  As you go you simply
>commit periodically - no more co-ci-co-ci etc.  CVS is a little harder
>to get started but a lot easier in day-to-day use. 
>  
>
With RCS, you can import at revision 1.1 (the equivalent of time_0) and 
of course your file can be at what ever state you'd like it to be.  As 
you edit, you have the option to stop and commit at any time - just exit 
the editor, and open the file again.  When you exit it will check in the 
file and ask you for a comment.  When you open it again, it'll 
automatically be checked out and locked.  No more co-ci-co-ci (which is 
tedious to do by hand, with either system).  Either one can be made 
easy, neither of them are easy-by-default.  :)  Since you're going to 
boil them both down to no-brainer operations, it comes down to technical 
differences between the systems.  RCS requires no daemon, requires no 
setup, requires no overhead, requires no central repository.  By 
contrast, RCS tends to store configuration with the file your 
version-controlling (either in an RCS subdirectory, or in the same 
directory as filename.txt,v - your choice) as opposed to using a central 
repository that can be placed "out of the way", which some might 
consider as an advantage.  Personally, someone's example earlier of 
having blown away their entire repository in an upgrade, makes me think 
that perhaps it's not as convenient as the user might have suggested.  :)

Anyway, we could debate the merits of this all day long.  As it is, I'll 
post a modified version of the "cvim" script later today some time, and 
perhaps we can get some more interesting debate going on about it.

Aaron S. Joyner