Question

at the moment we use Subversion for source control, but all of the merging work for our releases is done manually. We release several times a year, so create a branch for each release. All work from earlier branches must make it into later ones. Work on later branches must not make it into earlier ones (this is in our contracts). I believe this is known as the Promotional Model.

I think the following diagram best illustrates our desired workflow, with branches being created whenever work starts on a new release, and changes flowing from earlier branches to later ones.

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

• Would this model work smoothly using Subversion despite the lack of a meaningful trunk?
• Would automated merge tracking work for the updates from earlier branches to later ones?
• Would it be ok to close/delete/ignore a branch (in this example release branch ‘a’) without reintegrating?
• Would it be ok to create feature branches off of each release branch, and would merge tracking work for these? (They would follow the recommended create/merge/reintegrate model.)

Edit – add more info.

The reason that the traditional Unstable Trunk model might not be suitable is illustrated by the following diagram. Features for each release are not necessarily completed in order of release (some customers can be slow to confirm requirements). We want to propagate changes from earlier branches to later ones as soon as possible.

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

In this case, we want feature 2 (completed in branch a) in branch b, but as this is a child-to-parent merge, and therefore not supported by Subversion, it will have to be done manually. Similarly, feature 6 would have to be manually merged twice. I anticipate this to be a relatively slow and error-prone process compared to automatically tracked merges.

Answer 1

If I understand your situation, there is nothing in your requirements that make things as complex as you seem to be making them. You’re also putting way too much emphasis on the merits of automatic vs. manual merging (more on that later). CVS branches would have been another matter, but not with the way SVN handles “branches” (i.e., it doesn’t).

You could have a primary (unstable or stable) development line and create branches for each customer or release (or both). As features are validated, they either get merged back to the main line so later branches can include those changes or you always merge unidirectionally from a parent branch. Nothing requires you to close the branch and the merge is no less automated than it would have been to support your first (chaotic) diagram given you have multiple concurrent development lines.

The requirement that you only merge forward sounds like you just need to merge subset revisions from the main line, revisions after a given branch revision. Doing your merges this way will let you merge changes from arbitrary branches back to the main line as often as you like (as they are confirmed with your customers) and can be applied forward with confidence that only validated changes are getting applied. You can set up automatic merging to track that copy revision (see –stop-on-copy and range-based merges). Release branches then pick up sets of confirmed changes that have occurred from a given point forward.

SVN doesn’t “track merges” any more than it supports branches (which it doesn’t, they are just lightweight copies). You tell it (or svnmerge tells it) ranges to merge and it applies those changes. You can get the effect that you’re contractually required to support, regardless.

To answer your posed questions:

• I don’t think the model you proposed is very effective. To the contrary, it has increased potential for feature tracking chaos as you may have to scan branches for changes and merge forward multiple times. Moreover, it will undoubtedly confuse developers familiar with SVN and more traditional SVN organizational structures.

• Sure. That should be fairly independent of the structure you chose too. You’re going to need/want to keep track of your revision points regardless (perhaps via some simple scripting at worse).

• Sure. Branches have effectively no cost in SVN on the server side. The client side has a cost if you do entire root checkouts but that is generally a dumb thing to do regardless. Similarly, there’s no problem ignoring/deleting a branch. It’s just another change to the global revision hierarchy like any other copy/delete/rename/etc.

• That should work regardless of the “branching” organizational structure put in place. It sounds like there is a maybe little bit of misunderstanding on what it means to be a “branch” in SVN. You should be able to set up what you want and perform ‘manual’ merges with relative ease regardless and then later set up automatic merging after a few customer updates so you can understand your merge steps a little better.

Cheers!