Bazaar branching strategy with a Subversion trunk
Posted by Kash Farooq on November 23, 2009
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.