Why is it that we are drawn to particular revision control systems like CVS and SVN? If you have never used version control, then this post will make no sense so you should save yourself and walk away. Cheers, and apologies.
My first encounter with Revision Control was using CVS on an engineering work term. At the time it seemed like a revolutionary concept. You could actually track source code changes with a list of notes explaining the changes made (a task I previously thought was only possible to do manually and primarily done so in a log book). So enthusiastic about CVS that during the following academic term I ran my own CVS server with SSH logins for my team to use in the term software project.
During that term I rapidly discovered some serious limitations of CVS, notably renaming and directory versioning. The idea of losing revision history after renaming a file seemed crazy to me. I went looking for a replacement to CVS and predictably stumbled upon Subversion (SVN). It gave me a CVS-style interface plus my desired rename support and versioned directories. Beyond that it allowed arbitrary metadata properties to be attached to files and directories and provided cheap branching. Branching, I thought to myself, why had I not been using that in CVS? I quickly went through the tutorials in the now-famous SVN Book and imagined a world of branch strategies to handle all the times code had been blindly overwritten during the previous term.
During the following work term I tried, unsuccessfully, to affect a migration from CVS to SVN at my then employer. I had more success in the following academic terms when I replaced CVS with Subversion on my server and convinced a good number of people in my class to use it rather than the school's provided CVS server. The project team I was on used SVN branches in a purely exploratory way and we eventually abandoned the idea as causing more trouble than it was worth due to the idiosyncrasies of Subversion's approach to merging. I later discovered that SVN had inherited its merge to working copy model from CVS.
Subversion's merge to working copy and commit model has some weaknesses which are not obvious on initial inspection. Among others, it cannot track the parents of a merge and it requires a revision range. My only successful approach to coming up with the revision range has been to go back through the change logs until I find roughly appropriate dates or a previous merge log message which a colleague entered showing the last revision range merged. I have never understood why SVN and CVS require a revision range, but my searches for better alternatives at the time turned up nothing.
It was not until over a year later while I was hunting for random learning topics in Google's TechTalks series that I stumbled upon a video about The Mercurial Project. The topic description was not even obviously about SCM and I only watched it out of pure random exploration. I am very glad that I did. Bryan O'Sullivan's presentation was concise and comprehensible and opened my eyes to a substantially more robust approach to branching: representing branches as revisions with more than one parent revision. Mercurial does much more with branching than that, but without strangling the user with complexity that discourages the use of branching. Mercurial is Consise Software to the core. Even a passing glance at the Behind the Scenes look from Distributed Version Control with Mercurial makes that clear to me. Unlike most systems I have used I cannot see anything which I would remove from Mercurial.