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:
1Thomass-MacBook-cc:rcs thomasjaspers$ ls 2config.cfg 3Thomass-MacBook-cc:rcs thomasjaspers$ mkdir RCS 4Thomass-MacBook-cc:rcs thomasjaspers$ ci config.cfg 5RCS/config.cfg,v <-- config.cfg 6enter description, terminated with single '.' or end of file: 7NOTE: This is NOT the log message! 8>> This is an important configuration file 9>> . 10initial revision: 1.1 11done 12Thomass-MacBook-cc:rcs thomasjaspers$ ls RCS 13config.cfg,v 14Thomass-MacBook-cc:rcs thomasjaspers$ ls 15RCS
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:
1Thomass-MacBook-cc:rcs thomasjaspers$ co config.cfg 2RCS/config.cfg,v --> config.cfg 3revision 1.1 4done 5Thomass-MacBook-cc:rcs thomasjaspers$ ls 6RCS config.cfg 7Thomass-MacBook-cc:rcs thomasjaspers$ vi config.cfg 8Thomass-MacBook-cc:rcs thomasjaspers$ ci config.cfg 9RCS/config.cfg,v <-- config.cfg 10ci: 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.
Rational ClearCase
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:
1element * CHECKEDOUT 2element * /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.
1element /vob/project/reader.c /main/3 # Use fixed version 2element /vob/project/writer.c /main/4 # Use fixed version 3#element * /main/LATEST 4element /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
Naturally the next system would have been CVS (Concurrent Versions System) . But somehow this one was skipped in the list of projects I have been working on and I jumped immediately to SVN .
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.
Git
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 .
Conclusion
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 :-).
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.