Software Branching and Parallel Universes

blog
22

Very timely post!

Here where I work we are currently researching source control solutions, and have stumbled on the complexity of branching.

The overall negative responses here so far worry me a bit. Isn’t there anyone out there with a positive experience of branch (and merge)?

Would I be right in saying that having automated builds and tests reduces the risk of big bangs, or at least lets you know sooner if something is broken?

We had a look at TFS, but given the price, and that (as I understand it) you can’t visualise branches graphically, it’s a no-no, at least for the moment.

The remaining options we a looking at are SVN and AccuRev. AccuRev does ‘streams’ instead of branches. Still trying to get my head around what the difference is - quite difficult, because as Jeff points out, even with branches there are n different ways to branch…

23

I like this article, which was in IEEE Computer a while back: http://www.accurev.com/product/docs/SCMBranchingModels1.pdf

24

And that’s why one should use a branching based source control system like Mercurial! It’s no publicity, but using that kind of software implies good habits, whereas using softwares like CVS implies missing some of the better habits.

25

At the outset, I should say that we’re a contract development company working basically as an outsourced IT department producing custom software, with a few components that are reused between solutions which are run a little more like commercial software. Because the projects are relatively small, it’s rare to have multiple developers working in the same codebase concurrently, and even then generally only for the first release or major additions of new features.

We operate like this:

All new development work is done in trunk. Each release is labelled.

On the rare occasions that a customer needs a patch to a previous version that has to happen out-of-stream, i.e. while developing the next major release, a bug is discovered in the previous release that can’t wait, we branch at the label and make the fix in the branch. The check-in MUST only contain that one fix - keeping the check-ins small keeps the merge small. The fix is then merged into the trunk.

On even rarer occasions we’ve already found and fixed the bug in developing the new release, but the customer then asks for the fix earlier. Then we do the merge the other way, but it’s less likely that the fix was isolated, so it may need the fix to be implemented manually.

If you’re unlucky the bug is in an area that has been heavily revised so you have to work out whether the bug even occurs in the new code and if so, how to fix it.

Anything truly experimental is generally not checked in until validated. If it looks like it’s going to need to be backed up - it covers more than a few days of work - or if the experimental work requires more than one developer, then we would use another branch for that, even if no development were happening in trunk. At some point the experiment will either get accepted and merged back into trunk, or get thrown away.

In a few cases we’ve sold very similar systems to customers, where we’ve developed it a little more proactively, and these are also organised as branches in case a fix is required in common code. Generally I’d prefer to make the common code a project in itself, with per-customer customisations, but that wasn’t possible in the timescales agreed.

Tools: SourceGear Vault 3.1 with the companion SourceGear DiffMerge tool.

26

Thank you for this pedagogic presentation of branching.

What makes git so different (better?) than subversion on this aspect ?

27

Excellent post!
It seems many development houses approach source control in a haphazard way, and do not bother to learn about the power and dangers of various features, branching especially.

Another interesting guide to SCM and branching is from Perforce: http://www.perforce.com/perforce/bestpractices.html

I’d like to share a success story about branches, since so far it seems most commenters had negative experience with branching.
I used to work in a place that used ClearCase (and ClearQuest) for SCM. We had a branch per task system, with an “integration” branch which was the ancestor of all development branches. We had about 20 developers, and about 10-15 branches. We used this system for a few years (afterwards I left, they are still using it), and it was a great success.
Yes, there were troubles, and ClearCase is in my opinion a suboptimal tool. But!
We had many branches, and many merges between them (up and down the branch tree). Some developers worked on several branches. Some worked on just one. Some performed frequent merges (every week or two), some infrequent (every two months or so). Some developers shared tasks and
branches, some had a branch all to themselves.

Yet with all the chaos, the product (a very large, complex, embedded system) was progressing well. All the branches were almost always stable (it was a rare occasion when someone broke the build, but it happens). We had nightly builds of the integration branch. Through all the many times that source files had to be merged, we almost never had to perform manual merging, and I can remember maybe one time where an actual merge error was introduced.

Compare this to the alternative, and I say hurray for branches. They saved us from the sort of inevitable chaos that would have happened otherwise.

Of course, your tools need to be industrial strength for this to work. Don’t even THINK of trying it with a tool that doesn’t support atomic changesets, changeset tracking, hierarchical branches, etc.
Not all tools that claim to support branching do it well enough for branches to be useful. I know of one tool which supports branching, but its merges do not always work as advertised.

28

Branching and merging is no problem for our team since we have started using SnapShotCM ( http://www.truebluesoftware.com )

29

Based on my limited experience, distributed version control and Branch per Task are the way to go. Merges are not a problem when your tool is designed to facilitate them, especially if your branches are focused (in purpose) and short-lived. It’s a matter of using one’s tools properly. (And yes, sometimes that means not using them at all.)

30

Eric Sink, the founder of SourceGear, also wrote a good article on branching at http://software.ericsink.com/scm/scm_branches.html as part of his ‘Source Control HOWTO’ series.

31

Just to go off topic a bit.
After reading your blog for over 2 years I never know you were a comic book fan. That is so awesome!!

…back on topic
My company is also researching source control solutions. We’re a Microsoft shop so we automatically were going to use Visual Source Safe because of its integration with VS.

I wanted ask anyone here what they thought about VSS and there experiences with it? Also if anyone has any other solutions they recommend that plays well with VS?

32

I strongly believe that for branching and merging to work
well a coding style must be rigidly enforced (preferably
by the source control system).
Steve Bosman on October 3, 2007 04:42 AM

A friend of mine had what I consider a brilliant idea: let the version control system operate on the abstract syntax tree, and let each user check it out via her own formatter. There are issues, of course - like how to deal with code that doesn’t compile, and how to keep comments in the mix - but I really hope someone puts such a system together.

33

Donny V.: For the love of your source code, don’t touch Visual Source Safe with a three-hundred-foot pole!

a href="http://www.highprogrammer.com/alan/windev/sourcesafe.html"Visual SourceSafe: Microsoft’s Source Destruction System/a is an excellent article on everything that’s wrong with Source Safe. Even Jeff’s written an a href="http://www.codinghorror.com/blog/archives/000660.html"article/a on the subject.

Most source control tools out there provide some sort of integration with Visual Studio. If you’re looking for something similar but less flaky than VSS, SourceGear’s Vault is likely a good choice.

I’m personally a fan of Subversion. I’m inot/i a fan of VS integration, but I know that there are plug-ins available; I just haven’t tried them out to speak to their quality.

34

I worked for a medium sized software house who catered for different customers using branching. It was hell on wheels. Don’t do it unless you have a compelling reason - even then I’d rather have if statements or something like that in the code base … so when you’re trying to test a problem for a specific customer you know you’re testing the right thing.

I’d also use subversion, even with Visual Studio, Tortiose SVN gives you a nice windows front-end and it doesn’t lock files or get lost and start daydreaming when you’re in a hurry. VSS also didn’t used to like lots of activity (as in 30+ people checking in), it may have been fixed.

Subversion has a lovely facility where you make a note of the check in number and can just say “give me build 24”, or whatever. Great for testing or trying to work out when a bug was introduced. I think you have to annotate VSS by hand? Unless it’s changed since I last used it, which is a long time ago.

35

Sorry, didn’t realize my links would get stripped out (the bright red “no HTML” maybe should have tipped me off).

Visual SourceSafe: Microsoft’s Source Destruction System http://www.highprogrammer.com/alan/windev/sourcesafe.html

Jeff’s Article: http://www.codinghorror.com/blog/archives/000660.html

36

@Donny:

remember that VSS has a limit of 5GB of file changes database, you can go way over that but corruption will pester you quite frecuently.

Here we are using VSS with a combination of branching and pinshare. For each new version we branch, and if we fix a bug on a later version we can move the pin up for earlier versions.

If it is a MS only shop, go for TFS, if you can get away with it and you feel adventurous, give a go to subversion.

37

Jeff,
have you ever used branching AND merging in real production projects? Ever?
I guess not. Otherwise you would mention in your post tremendous complexity associated with merging branches.

That’s very rarely worth an effort to branch and merge projects.

Almost all the time it’s better either to keep everything in one project. Even if branch, you’d better never merge.
And if you never merge (because it’s too complex) – why not just cutpaste new project into fully separate project?

38

For cvs replacement use :

Save As . . .

39

Donny V. I recommend not using Visual Source Safe. We just moved from Source Safe to SVN. Using VSS we had multiple database corruptions and the whole process of pinning was very inefficient. We now use SVN with Visual SVN plug-in for visual studio 2005.

Read his previous blog: http://www.codinghorror.com/blog/archives/000660.html

40

Even single developers like Jivlain can benefit from branching. Any time you want to experiment, start adding something new, anything, just make a branch. You can even switch back and forth between working on two (or more!) different features without having to worry about an incomplete edit screwing up your ability to compile and test in your other branch. I find this quite nice because sometimes I get a bit bored working on just one atomic task at a time.

41

Im looking for a good, simple and free version control system for a small team (around 5 persons) that is compatible with Visual Studio (no Visual SourceSafe). Im going crazy trying to find something easy to install and configure to no avail.

Do you guys can give me a suggestion??