Let’s start this post with a question: Have you worked productively with RCS in any software development project? If the answer is “yes”, then you are either old – so am I 🙂 – or you are really unlucky if you have used that one recently – read “in the past 15 years”.
RCS – Revision Control System
Interestingly enough the latest RCS-release is from beginning of 2015 and thus much younger than what I was expecting. And luckily it can be installed on Mac OS using
brew install rcs. This way we can reminisce a bit about RCS doing some real stuff. Let’s create a new file and check it in to RCS:
Thomass-MacBook-cc:rcs thomasjaspers$ ls config.cfg Thomass-MacBook-cc:rcs thomasjaspers$ mkdir RCS Thomass-MacBook-cc:rcs thomasjaspers$ ci config.cfg RCS/config.cfg,v <-- config.cfg enter description, terminated with single '.' or end of file: NOTE: This is NOT the log message! >> This is an important configuration file >> . initial revision: 1.1 done Thomass-MacBook-cc:rcs thomasjaspers$ ls RCS config.cfg,v Thomass-MacBook-cc:rcs thomasjaspers$ ls RCS
There are two things that might look a bit strange to people only used to more modern SCM tools. First thing is that we need to create the RCS-directory explicitly. And second that the file vanished from the working directory after the checkin. Anyway the later issue can be avoided by using the “-u” switch when checking files in. This will checkout the file immediately again without a lock. A lock? Yes a lock :-)!
So let’s checkout the file again, make some changes and commit it again:
Thomass-MacBook-cc:rcs thomasjaspers$ co config.cfg RCS/config.cfg,v --> config.cfg revision 1.1 done Thomass-MacBook-cc:rcs thomasjaspers$ ls RCS config.cfg Thomass-MacBook-cc:rcs thomasjaspers$ vi config.cfg Thomass-MacBook-cc:rcs thomasjaspers$ ci config.cfg RCS/config.cfg,v <-- config.cfg ci: RCS/config.cfg,v: no lock set by thomasjaspers
Probably this is the next surprise. You need to always checkout files with a lock if you want to make changes to them. Furthermore RCS is working completely locally. Thus if you want to work on the same files with a team these files must be located on some shared disk or on some common server.
Obviously RCS does not really make any sense for our typical software development projects. But consider maintaining configuration files on some server. Unless those are coming from some deployments – and are thus under version control there – RCS might be a good choice to keep track on changes. It works completely locally and the need to apply a lock when changing files seems to be quite meaningful in this context.
When I started software development I was using RCS in real-life C/C++ development (for a short period in time). The thing I remember the most is the possibility to break other peoples’s checkout locks if you need to urgently make some fixes to some files. That was typically something where a few colleagues have been gathering around one PC – or workstation 🙂 – to perform those changes. Thus an early version of pair or mob programming :-). And of course interesting discussions that one should not leave the office while having locks on important files.
Bummer! That was a really big jump coming from RCS to ClearCase. And ClearCase was definitely the most esoteric SCM system I ever worked with. And it was the only project that had all the time two to three full-time SCM administrators on the project :-).
The central element in ClearCase is a Config Spec. This is a piece of configuration that is describing which files you are seeing from which branch or release. It can be as simple as:
element * CHECKEDOUT element * /main/LATEST
That is something most people working with other SCM systems will recognize quite easily. But things can get pretty interesting pretty quickly with ClearCase.