Branching Strategy Questioned

It is an exciting time for Subversion as its adoption continues at a dizzying pace in enterprises. I’m out there helping that adoption so I’m a bit late in posting the questions and answers I promised around the three basic branching strategies that I covered in the last two webinars in which I presented (Branching and Merging Strategies for Subversion 1.5 and Advanced Merge Tracking and Branching with Subversion 1.5). Hopefully these will be useful to many of you.

First, a quick reminder on what the three branching strategies were:

1. The unstable trunk which mimics the way that Subversion itself is developed. In this model, development is done on the trunk and a release branch is created around the time of feature completion with the formal promotion process carried out on that branch.

2. The stable trunk where development is done on system version branches and the promotion process is also conducted on that branch. The trunk is the branch point where the production releases are merged in and parallel development efforts are branched out.

3. The agile release strategy where development is done on individual feature branches and a release branch is created late in the process with the feature branches merged to it that will define that release. The formal promotion process is conducted on the release branch and the production version merged to the trunk as well as to all remaining active feature branches.

So on to the questions, first general branching questions:

Does the number of branches affect performance of the Subversion server?

No, branches are not just cheap in space and fast to create, they are alo just additional paths not unlike directories in the directory structure of your project. Of course, every tool has scalability issues at some point and Subversion logically has its limits, but in practical use, a scalability issue for Subversion around branches has not yet been experienced.

Can we use multiple strategies on one project?

Absolutely, there are many times when you may find a need to mix at least two branching models on the same project. For example, Internet applications may have very frequent releases focused primarily to address defects along with longer term release efforts to address broader feature development. The frequent releases may follow the unstable branch approach where they are worked primarily on the trunk and are branched, sometimes weekly or even more frequently, to do the formal QA to get to the release. The longer running enhancement releases may use the stable trunk philosophy though obviously the trunk isn’t actually stable, but the rest of the strategy is followed.

What strategy is best for a repository with multiple projects?

There is no need to have a single strategy in such a case. Instead one should use the appropriate method for each of the projects. Since each project should have its own top level directory for its branching model, there is no reason to force a particular method on all projects.

How does continuous integration affect branching strategies?

I’d hope that this isn’t the deciding factor in determining an appropriate branching strategy, but certainly the feasibility of continuous integration is impacted by the strategy chosen. With the unstable branch, continuous integration would be focused on the trunk and thus is stable as well as very useful as it identifies issues in the daily development commits. This is still relatively true when you look at the stable branch strategy where there may be multiple system version branches under development at the same time, but each is the focus of the majority of the development commits. The agile release model is the least accessible for this approach because of the number of active branches to try and monitor. That doesn’t mean continuous integration can’t be used but just that it is more difficult to implement and maintain.

Unstable Trunk questions:

Can this model handle parallel development if it only happens occasionally?

Any model can be morphed to handle exceptional situations, but this isn’t recommended. It is important to use a strategy consistently so that everyone understands where to find things during development and historically. That said, we’ve already talked about the potential of using multiple strategies on the same project so that’s certainly a possibility where the parallel development need could be addressed like with the stable trunk strategy.

Do I ever recommend merging from the trunk to the branch?

Never say never, but the situation would be pretty rare. I could potentially envision where a nearly complete bug fix or even an enhancement of importance is completed quickly enough on the trunk that there could be a compelling reason to merge it into the unreleased, but branched version.

How would you handle branches for customers that will have ongoing customizations for individual customers in this model?

Branches for this purpose can really be applied to any of the three basic branches we’ve discussed. The concept is that the base product continues to evolve and the branching strategy addresses that evolution. As production releases are made, the new revisions are merged to the customer-specific branches which contain customizations for that customer. There is also the potential of customer customizations being merged into the base product. The customer branches support the unique nature of customer specific changes while allowing for an upgrade path and the potential of contributing back to the base product.

Stable Trunk questions:

Version 1.0.1 didn’t get merged back into the trunk, shouldn’t it have been merged back?

Possibly, but I actually didn’t do so on purpose. With all the models, there is the potential that multiple releases are deployed in production and thus need to be supported. Therefore, there is the potential that bug fix releases are being made for multiple releases and merging all of them back to the trunk could mean intertwined versus serial releases. I therefore usually suggest that the actual production releases may be the only ones merged. Obviously, in my diagram that situation didn’t occur so it is a fair question.

There is a merge to the trunk outside of a release point, doesn’t that violate the stable trunk idea?

Yes, that can violate the stable trunk concept, but stability isn’t necessarily limited to just production releases. In this case, the purpose is to have a more up-to-date starting point for the system version branch. How strict you implement the idea of stability is up to you.

Should the development team develop the first version in the trunk or in a release branch?

Since my base principle is keeping it simple, I tend to say do the development on the trunk since there is no reason for creating a branch. The assumption is that parallel development won’t happen until the first release is made and other work won’t be merged until the release. This isn’t being pure to the strategy, but true to the base principle.

Agile Release questions:

In this strategy, is there any attempt to keep the task branches in sync with each other?

No, there really isn’t any way to define how you would keep isolated tasks in sync since there is no idea what will be released together until we get to the definition of the release branch. There is a need to keep the branches sync’d with production releases, but no way to do more.

Is there any reason that an Internet application should NOT be using the agile release method?

Sure, there are still many such applications that are released in a waterfall manner and are unquestionably successful. For example, release agility may not be required if releases are being made frequently enough. Keep in mind that there is more to keep in sync in this model which has to be balanced against any benefits.

Where is the release package built from?

I think the package would be built from the release branch since that’s logically where the promotion model process is conducted, but it can certainly be argued that the testing can be done on the release branch and then the approved revision merged to be tagged from the trunk. My absolute expectation is that you be consistent where you do build and tag.

How can a CM manager make sure all task branches were merged to the release branch?

Today, I would suggest the use of where merge tracking is recorded in a property for all branch merges. Obviously, this will be easier with 1.5 where the log command can expose this information. Another approach would come from integrating issue management with Subversion where the merges would be reflected in the record for the release.

I’m sure I’ll return to answer some more questions around these branching models and merge tracking before long. Right now, I’m off to help another enterprise successfully implement Subversion.

Happy Holidays!

Bob Jenkins

Bob Jenkins has spent over 17 years focused on application life-cycle tools. At CollabNet, Mr. Jenkins consults with enterprises that are planning to adopt Git or Subversion on how to apply best practices to their SCM processes. He aslo helps define the areas of investment by CollabNet in open source version control tools.

Tagged with: , , , , , ,
Posted in Subversion
19 comments on “Branching Strategy Questioned
  1. Dear Bob,
    first of all thank you for the important branching information!
    I would like to download your second webinar as I asked already in
    The first webinar (branching.pdf) is easily downloadable in the replay and from
    Best regards,

  2. Bob says:

    The link for the second webinar is in both postings and appears to work for me. Nonetheless, the URL is
    Sorry I failed to respond to the earlier request.

  3. Jeff Benson says:

    Hi, thanks for the post. Any idea (even rough) as to when Subversion 1.5 might be released?

  4. Bob says:

    First quarter of 2008 roughly. Until release 1 of 1.5 emerges, everything is particularly speculative about a production version. Release candidates go through 4 week soak periods in which high priority issues are identified and then addressed with a new release candidate. When a release candidate is built that doesn’t have such issues during its 4 week soak period, then we have the production release.

  5. Michal says:

    I remember that ‘rough’ estimate pointing at December ’07 not so long ago 🙂 But I do realize stability is key here and know the team’s working hard on that.
    I was always wondering on the right strategy for Agile branching and this post is the first place ever I see it explained. Thank you for that.

  6. Jeff Benson says:

    Thanks for the estimate, Bob! We’re a 5-person team hoping to migrate from SourceSafe 6.0 soon, but it seems like it might make sense for us to wait if 1.5 is a major release.

  7. I am not sure if I am reading it correctly (and your bullets with arrows are not helping clarify the images at all — do you mean the bullet corresponds with the line the arrow points to?), but if I am then it does not cover typical open source use of SVN.
    In most projects development occurs on trunk and when it is time to cut a release for the first time (say 1.0) a branch is made for the 1.x series. Subsequently after this is created a tag is made for 1.0. Development on trunk continues towards 2.0 and 1.x is used as a branch to apply only security and bug fixes, tagging as necessary for 1.1, 1.2, and so on. When the time comes for 2.0 another stable branch is created for 2.x and a tag for 2.0 is made. Development continues on trunk for 3.0 and the 2.x branch (and 1.x depending on support protocol) will get security and bug fixes. And so on, and so on.
    Like I said, if this is what you intended with the stable trunk strategy then the image really needs more clarification. The way those bullets and arrows point really leave a lot of ambiguous interpretation.

  8. Bob says:

    The Subversion model (or general open source model more accurately) is what is being shown in the unstable trunk model. I guess you’re reading the tags as referring to the point where the merge is done to the trunk, but the intention is that they refer to the source of the arrow and thus the tagging is done on the release branch. The merges are shown to emphasize the need to keep the trunk updated with work on the release branch at least at the points of releases.
    I’m not sure if there is a way to eliminate potential ambiguity without just more text as the approach is consistent through the models so as a group the potential ambiguity is minimized as best it can be. If each is taken in isolation, then you’re right about the ambiguity.
    Thanks for the feedback.

  9. harry wertmuller says:

    Some “just curious” questions from one of the Mindless Masses:
    1. Is it correct to say that .NET competes with Subversion?
    2. Any idea what percent of Java development/maintainance is done on .NET?
    3. Do any web developers use Subversion to maintain web content [HTML; Java; whatever.]
    4. Does Subversion integrate well with Google Widget Toolbox? [or are Google Widgets preemptively non-collaborative therefore needing little version control?]
    Would be interested in any responses, including “have no idea”.

  10. Bob Kerns says:

    I see nobody has answered you… Probably by now, you have a better idea of your questions, but I’ll answer anyway:
    1. No, it’s not correct. .NET is many things, but it is not primarily a source control system. I’m sure there are many people out there using .NET who keep their .NET assets in a Subversion repository.
    2. 0%. Java is not a .NET language. J# is a Java-like language which is part of the .NET family. Java developers may also integrate various .NET libraries into Java, in various ways. They may also use various .NET tools in their work for various purposes. However, I wouldn’t describe any of these activities as “doing development/maintenannce on .NET”.
    3. Yes. Subversion does a good job of tracking the revisions of your web site. Subversion tracks file assets and their revisions; it really doesn’t matter what purposes those assets are being put to.
    4. I don’t know what you mean by “non-collaborative” here, but certainly, GWT widgets are defined in files, and are changed, often by multiple people. Even if by a single person, tracking change history is highly valuable. I don’t recommend that ANYONE attempt serious development (even non-software) of ANYTHING without a serious revision control system to track their changes. Subversion handles GWT widgets fine, as well as the pages or programs that make use of those widgets.

  11. O, I know some of you
    How you steal such domain
    I like what you doing
    From my end
    we suggest this link as interesting
    High Risk Merchants Account Direct Merchant Service –

  12. I like you site –

    Proud to tell you, the URL
    100% freegreat
    web site. Make a note
    Culinary, food cooking recipes for FREE –
    for your needs.
    Will be glad to tell you
    Web marketing specialists, are any here?
    Get more visitors
    When I ordered web site design, I choose
    Appreciated any info you have

    Perfect funny and inexpensive gift for people who loves peppers and hot

  13. Jelffifttax says:

    Interested in How to Pass a Drug Test? We offer various free information and sources to make sure you pass your drug test! No need to spend money and fail a drug test, we can provide you with tips to pass a drug test for free! We recommend that you read our various articles so that you can learn about the history of drug testing, and how to easily pass a drug test. The immediate and most important goals of detoxification is start eliminating toxins such as

  14. Perfect domain name

    If you are looking
    domain. Take a look
    website for pets and pets ffriends –
    for your needs.
    These are very inportant.issues
    Are somebody here expert in SEO?
    To obtain such page ranking as you have – what you know about this company
    I expected your suggestions

    Find dream job with FREE employment service on

    Also we have

  15. I am fairly new to the use of SubVersion having previously used VSS. I am using SVN 1.6 with TortoiseSVN as a front end. I have a general question about the best/most practical way to use branching for 2 different applications that I develop. 1 application is a fairly simple JSP application. The other is a fat client application similar in nature to Visual Basic.
    With my JSP application I have a trunk folder that represents what is currently in production. At the start of a project I create a branch from the trunk copying everything from trunk into the branch. I therefore have a complete copy of all files in my working directory. All the development is done on the branch. When the development is released I then merge everything back into trunk. At the moment, this seems to work well for my JSP application where all the development is carried out on a copy of the entire set of pages.
    My fat-client application has code files which are copied to a working folder and then compiled by a script file. In esscence, my development and subsequent release is only those files that have been changed. In other words I am not taking a complete copy of all my files, like I am doing with my JSP application. Copying the files to my development working folder from the local copy of my trunk folder is not a problem. My problem is how do I add the files that I have changed in my development working folder to SVN in such a way that I can then merge that branch back into the trunk. When I try to merge the branch back into trunk I get an error saying that the path already exists in the trunk. I presume this is because SVN doesn’t know that my copy originally came from trunk and is now being merged back into it – there is a disconnect. The issue is more one of process, which needs to be slick and practical, otherwise it will fall into disuse. Should I be copying each file as I need it from trunk to my branch in the repository, and then update my working copy from the branch, and then make my commits back to the branch from the working folder, and then finally merge the branch back into the trunk? Or is there a more practical way? I accept that individual files need to be copied from somewhere to somewhere on an as-and-when-required basis, but I would prefer to be doing this client-side, and not server-side.
    I am fairly sure that this must be a typical scenario, so I would expect that there will be a simple solution. So your help would be much appreciated.
    Stuart Millington

  16. In your response to the question “How would you handle branches for customers that will have ongoing customizations for individual customers in this model?” you wrote: “The customer branches support the unique nature of customer specific changes while allowing for an upgrade path and the potential of contributing back to the base product.”
    Can you explain how the customer specific changes can be contributed back to the base product? I am struggling with this exact issue. Given SVN’s reflective/cyclic merge behavior, how does a customer branch contribute back while still being usable. According to the docs, once a branch is reintergated, it should really be deleted.
    Here’s my scenario, I have a customer branch contain customer specific changes. Eventually, it is decided that one of several customer specific changes are to be contributed back to the base product. How does this happen?
    Thanks for any advice you may be able to offer.

  17. Bob says:

    The reintegrate merge is designed for a SINGLE use case where a parent has contributed everything to the child along the way (likely the case for customer branches) AND where everything done on the child is to be contributed back to the parent (this is where it doesn’t fit the normal nature of customer branches).
    There is a lot of confusion where people mistakenly believe the reintegrate is the method for any merge back to the parent from the child and that’s just not the case at all. It was designed to basically trivialize (and thus avoid readdressing conflicts) the merge where all parent revisions have already been merged to the child and the child is now to be merged, in full, back to the parent. For this case, the outcome should be the working copy would contain (and likely the resulting commit to the parent) exactly what the latest revision on the child branch contains.
    The purpose of customer branches is to maintain customizations that are unique to a specific customer. That means it is unlikely that a customer branch would be merged in full back into the parent branch. However, it is likely that specific modifications would be desired as part of the generic project/product so those would be cherry picked merged from the customer branch to the parent branch. The merge would select only the revsisions on the child branch that encompass the features/bug fixes/enhancements that one wishes to merge into the general product.
    Let’s also note that one can handle many (though not all) cases of reflective or cyclic (I like to think of it as bidirectional merging) merges if you carefully apply a manual merge to your child branch. If you apply a manual merge (i.e., just a record-only merge) to the child for the revision that resulted on the parent branch from the reintegrate merge, then you can proceed to use the child branch without deleting and recreating it, but with the ability to use the reintegrate operation again.

  18. Thanks for the quick reply. Have a couple of follow up questions.
    Glad to hear about the ability to merge selected revisions from the child branch back to the trunk. What sort of conflict issues should I be prepared for when doing subsequent merges from the trunk back to the child branch. I’m concerned that this may be so horrific that it’s worth avoiding.
    Regarding the “recod-only” merge method that you describe, what advantages does this offer over just doing a reintegrate and creating a new branch off the trunk at the reintegrate revision number?

  19. Marc says:

    I am trying to test the SVN (v1.6) commands required for the Agile method and it’s quite involved (reintegration merges, blocking changes etc) to avoid self-conflicts at different stages in the lifecycle.
    1) Is there more detail somewhere on the precise commands recommended for these operations.
    2) The natural assumption around here was that the release tag would be merged into trunk and then task branches would do a simple update from the trunk (as if the release branch did not exist). Why is this not the case?

1 Pings/Trackbacks for "Branching Strategy Questioned"
  1. […] All of this was answered in the fourth question on the page that you took the diagrams from: […]

Leave a Reply

Your email address will not be published. Required fields are marked *