Question

I’ve added a legend in the picture to make it self explanatory.

Initially, the code in trunk for my project is at version 1.0.

I would create 4 branches with this version of the code: Vendor-A, Vendor-B, 1.1 and 1.2. The red lines represent these parallel development branches. Vendor-specific development and releases are carried out on vendor branches, and code in vendor branches will never be merged with trunk. When releases are made to a vendor, those releases are tagged.

Now, my questions are these:

1. How accurate is this methodology for product development?
2. Say, the Trunk is at 1.1 and 1.1 branch ends (expires) after merging 1.1 code into trunk, after which I find a bug in 1.1 code. Now, I would immediately create a bugfix branch and commit the fix into Trunk. So, Should this bugfix be pushed into 1.2 branch and vendor branches? Or should it not be pushed, because these branches are dealing with a different version of the Trunk (1.0)?
3. How do I tackle development under a vendor branch? Say, I need to fix bugs in Vendor branch, should I just commit changes directly into the Vendor branch?

I would appreciate your suggestions in restructuring / redesigning the process, as well.

Answer 1

Seems okay to me. I’d simplify it a bit however – if I am right in thinking that vendor branches get periodic refreshes from trunk, then you don’t need to do an explicit merge from bugfix branches – just merge bugfixes (e.g. 1.1 bugfix) back to trunk, and then do a merge from trunk to all vendor branches.

The trick when merging from trunk to vendors is to keep an accurate track as to what has merged already. Ideally you’ll merge everything, and do it in blocks in chronological order. (I find marking commits with a ticket/feature number useful, so I can see from svn log what needs to be merged at a particular time. This ensures that I don’t send half-a-feature to another branch.

When I commit a merge, I’ll add in the merge string (e.g. “(merge -r1234:2345 -r2667:3123 ../../trunk)” together with a description for the merge. This really helps when looking through logs (say on a vendor branch) to discover the earliest unmerged trunk revision.

I would however also be inclined to maintain 1.0 and 1.1 on different branches. So, if the 1.0 trunk becomes 1.1 once 1.1-branch is merged in, then it may be appropriate to take a branch 1.0 copy from trunk just prior to this. Initially bugfixes will be made to the trunk (1.1) and then merged directly to any vendors who are derived from the 1.1 branch. However it may not apply cleanly (or may not be relevant) to vendors who are derived from 1.0. In this case, apply them to the 1.0 branch first, and then merge from there to all vendors on the earlier version.

Of course, you may find bugs that relate only to 1.0, and are not relevant or do not exist in 1.1 – so this separate branch will assist there too.

With this approach in mind, it is therefore a good idea to upgrade each vendor away from very old versions when you can, so that the number of concurrent versions you need to maintain is minimised. Whether you do that as a matter of course, or as part of a new license/contract, is a matter for your business.