Mike M wrote:
Well, CVS is descended from RCS. CVS has a nice commitI 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.
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.
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 theLeaving 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. :)
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.
With CVS, you import at time_0. Then you checkout your module. As you go you simplyWith 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. :)
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.
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 -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
