Bazaar branching strategy with a Subversion trunk

Edit: This post has been superseded by Bazaar branching strategy with a subversion trunk – revised

When creating a feature branch from a Subversion trunk, there are a few things to be aware of.

Consider the following Subversion repository structure representing components that are independently releasable:

trunk
  WebService1
  WebService2
  WindowsService1
  WindowsService2
  UiApp1

With this repository I am suggesting it is completely reasonable to release, say, just UiApp1 without releasing any web or windows services.

With Subversion I could create a feature branch as follows:

branches
  MyFeature
    WebService1
    WebService2
    WindowsService1
    WindowsService2
    UiApp1

Then, if MyFeature actually only needed changes made to WindowsService2, I can safely just merge WindowsService2 back into the trunk – i.e. I would use TortoiseSVN to right click on trunk\WindowsService2 and merge from branches\MyFeature\WindowsService2.

Things are different in the Bazaar world: you can only merge/pull/push from the level you branched at.
If you created a branch like the one above using Bazaar, you would have to merge/pull/push the entire branch – i.e. at the same level as your .bzr folder.

Why is this a problem?
Well, if you know that you have only changed WindowsService2, you can’t just push that back to the trunk. You have to push all folders back into the trunk. The problem arises if someone else has changed, say, WebService2 in the trunk. Bazaar will make you merge those changes into your branch first before you can push your branch back.

Example scenario (this situation happened in our team):

• Developer 1 creates MyFeature branch and works on WindowsService2 only.
• Developer 2 creates TheirFeature branch and works on UiApp1 only.
• Developer 2 commits change back to trunk and creates TheirFeature_Phase2 branch.
• Developer 1 attempts to commit change back to trunk. Bazaar says a merge in needed (even though Developer 1 hasn’t touched UiApp1).
• Developer 1 does the merge and pushes the branch back to the trunk.
• Now Developer 2 attempts to push back to the trunk – Bazaar says UiApp1 has changed even though only Developer 2 has worked on this bit of code!
• Developer 2 has to merge before pushing back to the trunk.

So, there are a few pain points here. From commit logs it appears as though MyFeature changed UiApp1 when it didn’t.
Both developers had to do unnecessary, potentially confusing merges.

So, to get around this issue, we now create branches at “component level”.
If MyFeature only needs to work on, say WebService1 and WindowsService2, we only create branches for those components.

The full feature branch area on the shared server may look like this:

branches
  MyFeature
    WebService1
	  .bzr
    WindowsService2
	  .bzr
  TheirFeature
    UiApp1
	  .bzr

Now we only have to push back the code that we have actually changed.

This strategy has been successful on our team – we use the great Bazaar features to make our renames/refactors/merges simple, and with just a small amount of extra branch creation work we can keep our synchronisation back to the trunk at the right level.