a companion discussion area for blog.codinghorror.com

Software Branching and Parallel Universes


#1

Source control is the very bedrock of software development. Without some sort of version control system in place, you can't reasonably call yourself a software engineer. If you're using a source control system of any kind, you're versioning files almost by definition. The concept of versioning is deeply embedded in every source control system. You can't avoid it.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html

#2

Echoing David’s comment on TFS/Team Foundation Server…I’ve used VSS, CVS, StarTeam, and TFS. TFS is the real deal…it’s the source control product the MS SCM world always wanted.

While other SCM products integrate with Visual Studio.Net, the real power of TFS is its OOtB integration with work item tracking (tasks, bugs, etc.), unit testing, analytics, builds, check-in policies (e.g. can’t check in without passing all unit tests, without a comment, etc.), and project management. When implemented correctly, your PM will never again bother you with Bill Lumbergh inquiries about your percent complete on tasks.


#3

Nice article… well written.


#4

This isn’t true at all-- your local work is not revision controlled, it will have no history, so it’s not a branch. A branch is an alternate set of history. No history, no branch.

Sorry for the harsh tone Jeff, but frankly, please talk about DVCS once you’ve used them.

Local work is revision controlled and does have all the history you want, and you can branch it further by creating clones of your local working copy. In a DVCS, each working copy is a repository.

How exactly do these distributed version control systems make merging easier, though? I think merging two people’s independent work is hard no matter how you slice it. This sounds awfully silver bullet-ish to me. Can someone explain this better?

I’ll just redirect you to the “official” documentations.

Here’s the relevant part of the Mercurial Book, http://hgbook.red-bean.com/hgbookch3.html#x7-530003

Didn’t find anything as clear cut for Git, it works pretty much the same way as Mercurial except it’s faster, and Git tracks the whole tree as one single blob instead of tracking individual files.

Anyway yes merging can be hard when there’s a conflict, but it should be trivial when there isn’t.

DVCS make the “no conflict” merge pretty much automatic and painless, and make it much easier to deal with the “with conflict” merge. And keep full history of all the merged branches.


#6

A few people have mentioned that they don’t trust their source control and therefore won’t branch/merge … I’d say if you don’t trust your source control then you need new source control. You may as well not use it in that case…

We use SVN and branch/merge all the time with little or no problems. This is for a very large web project working with many types of files and at least 4 or 5 people at all times. We have many new features in dev at once all slated for different release dates, that’s why we need branching.

If I need to start dev on a new feature now and it doesn’t launch for three months, we have to branch. That way we can launch other features in the meantime and merge my new feature in when it’s ready for release.

SVN handles all this perfectly…


#7

At my current place of work, we use Changelogic ( http://www.changelogic.com/HomePage ), which somewhat automates branch and release management for SVN and/or CVS.

If you work with Changelogic, THERE IS NO HEAD. All the work is done in branches – called “changes” – and when a change is integrated, it is merged with the version (tag) it was based on, to create a new version (tag). Each developer usually works in his own branch, but sometimes 2-3 people work together in one.
The version numbers (like 2.3.1.15) are managed automatically. For example, you can do some changes based on the 2.3.x versions, but other changes in the 2.4.x versions. The changes based on older versions will also be integrated forward into the new versions. This is actually one of the few annoying bits of CL.

Usually you just create a new change from a task/issue/ticket (pretty much automatically) based on the latest version and check it out using the correct change number. After you’re done, you commit it (actually it’s called “end_edit”), have someone review it and then integrate it with the previous version to create a new version. If versions were added by others in the meantime, you usually have to merge those changes into your branch (pretty much automatic) before integrating.

I think this mode of development is a great relief, as it almost frees you from having to think about managing branches yourself. But it can also lead to Branch Mania if you’re not at all paying attention to what you are doing. We did wander into branch mania when we started with the tool, but learned since then to keep changes/branches more coarse grained.


#8

Nice article – I recently wrote about version control, which beginners may find useful(http://betterexplained.com/articles/a-visual-guide-to-version-control/).

Inside of Microsoft, each team has its own branch which is eventually merged into the mainline (reverse integrated). Changes are also propagted from the mainline to the branches (forward intergrate).


#9

Beware of letting Project Managers know about branches. They end up jealously guarding their branch and refusing to allow merges.


#10

We use branches primarily to deliver slightly different functionality to various clients, and it’s quite a havoc I must say. :slight_smile:


#11

Very interesting simile, and one that I had though about before. Actually, last week I discussed with some other programmers (almost entirely in jest) creating a time traveling game with a subversion back-end, where branches would be alternative time-lines, which could be merged, and wher conflicts would be bad for the overall space time continuum. :wink:


#12

We’re using ClearCase and have around 6 active branches. One branch is as old as 1 year, and has been all the time merged into the main line. But we have huge problems when merging between branches. We do a big bang merge for every version that is shipped of to QA.

There are many times that the merge tool has managed to an automatic merge as it was simple, but the result was that we lost code that did not show until the customer sees it again. Many times the automatic merge has produced code that didnt compile, cut of half of a cs file.

Is the automatic merge in CC just plain stupid or is this a problem with all merge tools?

What is the best way to counter problems from merging?

Unit tests, but what happens if the unit tests must be merged? (This makes me believe that less code reuse in unit tests is better and is there is less to merge)


#13

Branching is sometimes a necessary evil, but it’s still that one feature where you’re likely better off never using it. Call me branch paranoid.

It’s not even the concept that’s difficult, it’s the implementation. I can understand what I want to do; it’s getting the marriage of source control ui’s and development tools to also come together and see my point of view (without taking an eternity).

  1. Do I completely trust my source control. If using VSS, then please answer no.
  2. Do I trust other developers not to screw up. I’d like to say yes, but nobody’s perfect.
  3. Will source control allow me to do things the way I want?

Maybe it’s just the terminology and the crappy tree-surgeon metaphor that confuses me. Branching is Hard ™ - let’s call it O(n^3) - easy enough on hello-world applications quickly ramping up to mentally exhausting as the project starts to get hard. (Yes we use agile, run tests and have build machines. )


#14

Branching is not evil. Merging is evil.
The solution to the delbranching/delmerging problems is distributed source control systems.


#15

I have to laugh. I’m in the middle of merge hell today caused by a mix of premature branching and source code reformatting.

I strongly believe that for branching and merging to work well a coding style must be rigidly enforced (preferably by the source control system).


#16

In the day job, we have a team of 40-50 engineers working on a common codebase. We maintain a branch for active development of future product revisions and a branch for each historical version that is in maintenance. This makes three branches. Additionally, for one customer we maintain a branch that mirrors their live environment for critical hotfixes that can not wait for a maintenance release to pass full UAT.

In a recent phase working on a new major release, a significant development was isolated to it’s own branch. As work was active on the trunk, and a number of defects were raised by customers and fixed over multiple branches, the resulting Merge was a hideous nightmare and has now invoked “Merge Paranoia” at certain important decision making levels.

Branching is in theory great, but, if we’re branching for more /production/ versions of our product, then that increases the overhead in any defect fixing massively. We have to have a build and test environment for each branch. The maintenance team have to merge and retest the fix in yet more locations, which decreases the number of issues they can resolve in parallel and affects our ability to hit SLAs.

If we branch for development to isolate a number of trunk based developments, we run into hideous merges that need to be performed. With a large codebase and development team, branching needs extreme planning and consideration.


#17

I might point out: for many corporate developers, branching is something of a solution in search of a problem. Everything I’m working on has one currently running version, in one environment. Usually with just one person working on that particular component at a time.

Heck, I’ve never actually done a branch. I keep getting tempted to just do one on my personal Subversion server just for the sake of trying it - except every time I think of it I’m kinda busy :stuck_out_tongue:


#18

Even that Conan story you reference was a second revision: http://the-isb.blogspot.com/2006/06/hypothetical-adventures-of-conan-part_19.html


#19

Nice article.

A previous employer now requires manager approval to make a branch, but thats not the only thing that off at that place.

I agree except on the branch per target OS. Yes, maybe while developing for that target OS, but your build system should be able to handle all target OSs from the same branch. Maybe its a bit zen like, but I enforce it on all projects I manage.

It keeps an OS particular branch from getting stale.


#20

The section on branching in Brad Appleton’s ACME project http://www.cmcrossroads.com/bradapp/acme/branching/ is one of the best references available on the web, and his SCM Patterns book (http://www.cmcrossroads.com/bradapp/acme/#ScmPatterns) written with Stephen Berczuk should be required reading for anyone who’s looking to “do version control” properly.


#21

Branching is a solution to the problem Jivlain doesn’t have - that of having several people working on the same thing at once. If your application is split into many discrete modules, and you have 1 person who works on each module, then you never need branching. You have a single-user control problem that by definition isn’t a problem.

The next step downwards is to have some of those modules shared by other modules (eg a database schema that everyone uses). if one person changes the schema, everyone else has to upgrade to it, or their code will not work. This is still not much of a problem, you just need a bit of communication among your colleagues.

The next step though is where you have several people working of multiple modules at once, and this is where branching really makes sense. This is doubly true if your project is going to take a long time to complete.

In this case, you branch off, do whatever you want with a stable (to you) system, and merge your changes in when your system has been completed and tested. At no time do you break anyone else’s code.

Using branching to handle released versions is a mistake IMHO, and is where Subverison falls down. I don’t think making a branch that is designed never to be merged is a good thing, you should ‘snapshot’ the code for this using a Tag or Label mechanism instead (and use patches to update historical versions).

The time I used branches in anger was with a large application, we used the ‘branch per task’ model which worked well. It wasn’t perfect, and we sometimes still had pain at merge time, but I think you wouldn’t get any better.