Version Control Blog

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”.

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.

Drupal development team has released Drupal 5.2 on July 26, 2007. It fixes two security vulnerabilities, so it is highly recommended that you upgrade as soon as possible. Many Drupal installations often contain extra Drupal modules, and almost always the also contain local customizations.

Question arises: how to upgrade your Drupal installations

• timely,
• safely,
• with confidence that none of your local customizations are lost;
• without need to remember each line that was edited and re-applying those edits to new version;
• without need to drastically change your workflow (very little discipline is needed actually);

We show that Git solves those problems easily. (more…)

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)

Brian Harry shares an inside story about how the branches are organized in Developer Division at Microsoft. They use many branches (called “virtual build labs”), with strict rules for moving changes between labs. Private branches and release branches are also used extensively. The post is quite old (November 2005), and they seem to be already switching to feature branches. But nevertheless, it’s a good read. Some arithmetics: I’d estimate that we have on the order of 800 developers[…]. Let’s imagine for a minute that any given developer has a brain fart and checks in a build break, serious bug, etc once every 6 months (which in my opinion would be a team of 800 of the best developers I’ve ever met). There’s about 250 working days in a year and simple math says 800 * 2 / 250 > 6 serious bugs checked in every single working day. The fact is it’s higher than that. Read more on how they cope with that scale of bugs at Brian Harry: “Branch structure in Developer Division at Microsoft”. (via notgartner blog)

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”.

Buck Hodges writes about branching, merging and shelving in Team Foundation. Branching and merging are business as usual, with many details specific to Team Foundation. Shelving, as far as I understood, is the implementation of lightweight temporary branches. This may be a good feature for occasional use. Read more at Overview of Branching, Merging, and Shelving (in Team Foundation’s Weblog).

Chris Birmele has written a small but useful essay on branching and merging as one of the aspects of proper Software Configuration Management. He lists the following benefits of good SCM practices:

• it safeguards your intellectual property– the software assets!
• it helps improve communication among team members;
• it provides a way to establish clear responsibilities and accountability;
• it provides traceability and reproducibility;
• it facilitates reusability of software assets;
• it provides consistency, reliability and integrity of software assets;

Chris also briefly describes common branching strategies and provides a short list of branching and merging anti-patterns. Read the “Branching & Merging Primer” article (7 pages, in Microsoft Word format).

linux(at)horizon.com has published the draft document on branching and merging in Git.

I know it took me a while to get used to playing with branches, and I still get nervous when doing something creative. So I’ve been trying to get more comfortable, and wrote the following to document what I’ve learned.

Read it at LWN.net: “Branching and merging with git”

Our favourite optimism-inducing The Daily WTF shares a story about version control done strictly wrong. Read at “Happy Merge Day”.