Version Control Blog

We’ve reorganized the information from the famous Better SCM: Comparison project, and presented it in a more useful way.

Announcing: Version control systems comparison 2.0.

You may compare any number of systems against each other. See for example:

• CVS vs Subversion;
• bzr vs Mercurial;
• Subversion vs svk;
• Distributed version control systems;
• Choose your own set of version control systems;

TODO: add (at least) Git, PlasticSCM and Microsoft TFS information to the original Better SCM database and re-import it here. Stay tuned for updates.

Damon Poole (CTO of AccuRev) wrote a teaser post in AccuRev blog about AccuRev streams: Damon Poole: “Streams vs Branches”.

This article links to a whitepaper: Damon Poole: “Stream-based architecture for SCM.

As far as I understood from the first reading, idea of streams is very straightforward and simple concept making “streams of development” a first-class object in AccuRev repository. Streams are very easily presented on UI level, making them easily understood for software developer and release manager. Branches, tags, and private workspaces could be superseded by various flavors of streams.

E.g. “Release 4.0″ is a stream. “Release 4.0.1″ is the child stream. Changes made in 4.0.1 could be “promoted” to 4.0. When we start the “5.0″ line of development, it automatically gets everything that was promoted to 4.0, either from older version or from bug-fix version (4.0.x).

I understand that streams could be enormously useful if they actually do the merging well. Technically this is handled easily by modern standards. Something like this could be done (and may be is already done) in many GUI clients for most open source version control systems.

Second part of the whitepaper is dedicated to AccuRev TimeSafe, which is the underlying repository format. I have to remark that the article only compares TimeSafe features with CVS and ClearCase repository features. Those are embarrasingly easy targets for criticism. Why are modern repository formats such as Subversion FSFS and Git not mentioned? Are they technically superior? ;)

Article on Timesafe: Damon B. Poole “The Timesafe Property - A Formal Statement of Immutability in CM”.

See also: DaveOnSCM: “Agile: Branches vs. Streams”.

Important opinions from Subversion developers:

Karl Fogel: “Subversion, decentralized version control, and the future”

Ben Collins-Sussman: “The Risks of Distributed Version Control”

Mark Shuttleworth (of Thawte, Ubuntu, and Canonical fames) wrote four posts on rename tracking feature in version control systems, and its impact on merging as a social process.

Read at his blog:

• “Renaming is the killer app of distributed version control”;
• “Further thoughts on version control”;
• “Choose lossless VCS if you have that luxury”;
• “Merging is the key to software developer collaboration”;

Those posts caught a lot of attention back in June, but frankly it seems to me the issue is somewhat overrated (but nevertheless a recommended reading). Mark’s Canonical Ltd. supports the development of Bazaar. Bazaar has the discussed feature of merging with renames tracking. Git does not have it, but it has another argument in this discussion: huge merging traffic — Linux kernel development is all about merging, and the codebase is huge. So, I guess this feature is not that crucial: Linus is well-known by his uncompromising approach to tools.

Microsoft Patterns and Practices team has released first several topics as a part of Visual Studio 2005 Team System Guidance. This project will be the “single best repository of Visual Studio Team System guidance”, including practical scenario-based guidance for roles such as PMs, developers, architects, testers. It contains thoroughly engineered and tested set of recommendations, and it will be the single entry point for videos, roadmaps, and task-based how-tos. Particularly interesting part of this project is the Team Foundation Server Branching Guide. This is an on-going work, and it gets announced in J. D. Meier’s blog as new parts appear:

• 28 Feb: patterns and practices Visual Studio Team System Guidance Now Available;
• 20 Feb: Team Foundation Server Branching Guidance Now Available;
• 26 Mar: Video-Based Guidance for Visual Studio Team System Now Available;
• 26 Mar: New Prescriptive Guidance for Visual Studio Team System

(via Brian Harry’s Blog)

A well-known SCM comparison resource “Better SCM Initiative” has updated the table, adding three more version control systems: Rational ClearCase, AccuRev, and Mercurial. So, now it has a feature-by-feature breakdown comparison of nineteen systems, open-source and commercial. Sadly, it does not yet cover GIT. Read at: “Better SCM Initiative: Comparison”

Dan Moore writes about MolhadoRef. MolhadoRef is a research project developed by Danny Dig, which implements a version control system where refactoring is first-class concept. That is, when you use well-known refactoring techniques in Java, such as “rename package, rename class, rename method, move class, move method, and changing the method signature”, MolhadoRef detects that you’re doing just that, and records this refactoring information. Later, during merging, it tries to use refactoring history to resolve merging conflicts in a more intelligent way. Usual text-level conflict resolution is left as a fall-back. Dig’s experiments show radical decrease in number of merging conflicts when using this merge strategy (see “Evaluation: effectiveness”). Also, you can see the history of code objects, such as methods and classes: how they evolved over time. See Dan Moore’s post on MolhadoRef for notes from Dig’s talk “Refactoring-Aware Software Merging and Version Control for Object-Oriented Programs”. P.S.: About two years ago during the discussion of early GIT development, Linus Torvalds outlined his idea about tracking the movement of code objects, as opposed to simply tracking file renames and line changes. See the discussion at Linus Torvalds: Re: Merge with git-pasky II
(Message-ID: Pine.LNX.4.58.0504141728590.7211@ppc970.osdl.org).

Xaprb takes on agile approach to version control, warning about the possibility that some non-obvious objects could sometimes be erroneously left out of it. This advice sometimes goes to the extreme, such as putting your backups under version control, but it’s a good idea to keep versioned at least init scripts, scheduled tasks and configuration files, in addition to usual code.

This article is about how to find and safeguard all the hidden code you don’t know your business relies on.

Xaprb: “So you think your code is in version control?”

James Shore and chromatic are currently writing a book, “The Art of Agile Development”. Drafts are published for pre-publication review at The Art of Agile Development. In particular, a chapter on version control.

Joel Spolsky forwarded more information about source control in Windows team:

“… prior to the restart effort of Longhorn, there were about seven [branches], reverse-integrating into one main branch every two or three weeks perhaps. Now, imagine several thousand developers checking in directly into seven branches. This will lead to two things: “1. you check in frequently, and there’s a very high chance of either breaking the build, or breaking functionality in the OS, or 2., as a counter-reaction, you don’t check in very often, which clearly is bad, since now you don’t have a good delta history of what you did. “So this clearly didn’t scale. As part of the restart effort, we decided that each team would get its own feature branch, each feature area (multiple teams) would go up to an aggregation branch, and those would lead up to the final main branch. (As such there’s now north of a hundred branches in tiers, leading up to about six aggregation branches.) Teams were free to choose how many sub-feature branches they wanted, if any, and they were free to choose how often they wanted to push up their changes to the aggregation branch. As part of the reverse-integration (RI, i.e. pushing up) process, various quality gates had to pass, including performance tests. Due to how comprehensive those gates ended up being, this would take at least a day to run, plus perhaps a day or two to triage issues if any cropped up; so there was a possibly considerable cost to doing an RI in the first place. However, these gates were essential in upholding the quality of the main branch, and had they not existed, the OS would have never shipped. I suppose it’s one of those ‘what doesn’t kill you…’ type deals.

Joel adds:

When you’re working with source control on a huge team, the best way to organize things is to create branches and sub-branches that correspond to your individual feature teams, down to a high level of granularity. If your tools support it, you can even have private branches for every developer. So they can check in as often as they want, only merging up when they feel that their code is stable. Your QA department owns the “junction points” above each merge. That is, as soon as a developer merges their private branch with their team branch, QA gets to look at it and they only merge it up if it meets their quality bar.

Read all at Joel Spolsky: “Using source control tools on huge projects”.