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.
element /vob/project/reader.c /main/3 # Use fixed version element /vob/project/writer.c /main/4 # Use fixed version #element * /main/LATEST element /vob/project/… /main/LATEST
You kind of define a view on the files you are working on where the rules are applied in the order of appearance in the Config Spec. The
/vob-directory has its name from the fact that ClearCase repositories are called VOBs. You can use comments and of course you can comment out rules. The above example is still really easy. In that very project the Config Spec files had dozens of dozens of lines. Specifying what to see from other projects and from your project. I think at least once every two weeks one was visiting the office with the SCM admins to get some support in cleaning up a mess that was easily created when using the wrong Config Spec.
Things became even more interesting due to the fact that ClearCase is storing VOBs in a kind of region-concept. If I remember correctly we had two or three different regions that needed to be synchronized – you remember the ClearCase admin team. In the end this was a quite resource-consuming exercise and not really the most lightweight SCM approach one can think of ;-).
SVN – Apache Subversion
We are having a centralized repository on some server that is running the SVN server software and is accessible via some kind of network connection, probably most of the time via the internet. Then we have the SVN client installation locally and we are checking out projects from the server to some local directory. For each directory SVN keeps track of local changes in some hidden
.svn-directory inside that directory.
Working with Subversion was quickly feeling good. The way branches and tags are handled was feeling quite natural and merging files also works quite well. There is good tool support on the client-side – e.g. TortoiseSVN – and also for continuous integration with corresponding subversion PlugIns, e.g. for the Jenkins CI-server.
This way I was happily working unless Git came along.
Our recent project was switching quite late from Subversion to Git. And it took me a while – not having concerned myself with Git before – to realize how big a step forward this was.
Torvalds quipped about the name git (which means unpleasant person in British English slang): “I’m an egotistical bastard, and I name all my projects after myself. First ‘Linux’, now ‘git’.” The man page describes Git as “the stupid content tracker”. – from the Git Wiki page
With Git you have a local repository and a remote repository. Basically you are working on your local repository most of the time to do commits or create branches. You can then synchronize your local repository with the remote repository to push your changes or to pull in the changes done by other team members.
It might not sound too amazing unless working with it. Locally switching branches by just checking them out is really straightforward. Generally it was never easier to work with branches. And while with Subversion I was using some GUI client quite a lot with Git I switched back to use the command line most of the time. Stashing local changes to apply them again after pulling in changes is another feature I have learned to love.
The infrastructure build around Git is quite amazing. Probably Github and Gitlab are best known here. And of course there are really a lot of guides around for Git. One I really like a lot is this one.
Going back from Git to Subversion, no way – well, unless some project is urging me to do so ;-). Of course Mercurial is offering similar features as Git does. But with that one I do not have any first hand experiences.
Coming from RCS to Git was a really interesting journey. Let’s see what will come next :-).