Tuesday, September 04, 2007

Merging New trunk Features to a Development Branch

When I was on the development team for Zenoss, I tried to get them to use branch-based development, including Divmod Combinator. They eventually did switch to using branches for any big changes, but they didn't embrace Combinator. When I'd taken over development of the Zenoss community code, there were only two developers, so I only implemented a very basic branch management process. But having used Combinator a lot recently, I wish that I'd taken that opportunity to get them using Combinator... man, their lives would be so much easier right now if I'd taken that step.

I am now managing all of my svn-based projects with Combinator. Even the ones were I am sole developer. The time saved and convenience gained is enormous.

Below is a perfectly good example of how Combinator makes svn management less painful. I don't know about you, but every time I have to manually to push new trunk changes into my current development branch, my brain does a little freak-out dance. I stress, thinking "Crap; I have to get this right. What are the exact commands I have to use again?" Thanks to Combinator, this is no longer a problem, and my brain does a happy dance instead.

These days, I am using Combinator on an almost hourly basis. It's very simple (to get setup with Combinator, see the tutorial and other example usage).


Assuming you've got a Combinator-managed project called "Project", let's do some background first. Say you want to branch trunk for a new feature, one that you're tracking in ticket #836. Here's how:
$ mkbranch Project viking-feature-836
Now, just to make sure that you are no longer in trunk, check which branch you are in:
$ whbranch
Project: viking-feature-836
Divmod: trunk
Twisted: trunk
(Note that every project that you are managing with Combinator will be listed.)

Say you've got another ticket you're working on, #1066. You created the branch with this command, just like the other branch:
$ mkbranch Project norman-feature-1066
After starting this branch, you complete 836 and merge to trunk:
$ chbranch Project viking-feature-836
$ unbranch Project
$ svn commit -m "Completed 836."
unbranch updates trunk with the latest changes and then merges the branch it just came from (viking-feature-836) into trunk. Running svn diff will show you just how true this is.


So much for the background! Now for the merging I'd promised:

If the norman feature depends on the viking feature, we need to "merge" trunk to branch. Using Divmod Combinator, this is how that is accomplished:
$ chbranch Project norman-feature-1066
$ unbranch Project
$ mkbranch Project norman-feature-1066-2
$ cd ~/Project/branches/norman-feature-1066-2
$ svn commit -m "Merged changes from norman-feature-1066."
In other words, we:
  1. merge our work to date from norman-feature-1066 to trunk (without committing!)
  2. make a new branch, based on that trunk, which includes the norman feature to-date and all the latest changes made to trunk
  3. commit the branch changes to our new branch
We're using trunk to get what we need by only making changes to trunk in the working directory, without making any changes in the repository. Keep in mind that the changes from the first branch were added (and not committed) to trunk before creating the second branch. Since the second branch was created from this modified trunk, we will need to commit those additions. Also, you will most definitely want to revert your tweaked trunk once you have finished creating your new, updated branch!


As a side note, Combinator is especially excellent for python projects, because of its python path management features. Any python tools, scripts, pluggins, or applications that use the code in your Combinator-managed projects will import from the current, active code (whatever shows up in whbranch). So when you're working in branch and you run your unit tests, you know that it's the branch code that's getting tested. When you switch back to trunk, all your code is running against trunk. Very nice :-)

Technorati Tags: , , , ,

1 comment:

  1. Good post! It's good to see more people writing about branch-based development.

    Take a look at my reply.