RCS should not be your first choice for version control
A while back I wrote that sysadmins should version control everything and kind of advocated using RCS for it. Based on one link to the entry I think that I may have confused people here about the merits of RCS, so let me clarify a bit.
RCS is a very old and rather primitive single-file version control system. Today it only has two real virtues: it works on single files and it's trivial to start using it on text files. It's not your best choice for a version control system in most circumstances, merely the easiest to start using so that you have some version control. And you want to have version control. If you're working on whole directories (and you should be if possible) any modern VCS is both better and more convenient than RCS. I'm partial to Mercurial for this but anything that you and your coworkers like will work fine. If you're already using git for other things and thus know it well, go with git.
(There are some situations where RCS may be a better choice. If you run into them you'll know it.)
Similarly, if you have a choice between using RCS on your configuration files and setting up good automation using Chef, Puppet, CFEngine, or whatever, you should set up automation. Full scale automation will get you much further than simply version controlling your configuration files in place on all of your different systems. Again, using RCS is the basic first step; you should start using it because you can do so right now and RCS is better than nothing. But once you've taken the first step you should keep moving towards an even better environment, not stop.
(I'm simplifying the issues surrounding full scale automation a lot, but again this is basic advice. Most people are better off automating and if you're going to automate, most of the time you're better off using a standard framework for it.)
|
|