Branching Strategy Questioned

About 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.

  19 comments for “Branching Strategy Questioned

  1. November 30, 2007 at 1:55 am

    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
    http://blogs.open.collab.net/svn/2007/11/what-about-bran.html.
    The first webinar (branching.pdf) is easily downloadable in the replay and from
    http://subconf.open.collab.net/
    Best regards,
    René

  2. Bob
    November 30, 2007 at 5:45 am

    The link for the second webinar is in both postings and appears to work for me. Nonetheless, the URL is http://www.collab.net/webinar22/.
    Sorry I failed to respond to the earlier request.
    Regards,
    Bob

  3. Jeff Benson
    December 3, 2007 at 7:19 am

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

  4. Bob
    December 3, 2007 at 9:01 am

    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.
    Regards,
    Bob

  5. December 6, 2007 at 11:39 am

    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
    December 7, 2007 at 11:49 am

    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.
    Thanks,
    Jeff

  7. December 14, 2007 at 2:14 am

    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
    December 14, 2007 at 12:34 pm

    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
    January 19, 2008 at 3:11 pm

    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
    April 6, 2008 at 3:30 pm

    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. March 21, 2009 at 7:29 am

    O, I know some of you
    How you steal such domain blogs.open.collab.net
    I like what you doing
    From my end
    we suggest this link as interesting
    High Risk Merchants Account Direct Merchant Service – http://www.yourmerchant.org

  12. March 21, 2009 at 7:43 am

    I like you site – blogs.open.collab.net

    Proud to tell you, the URL
    100% freegreat
    web site. Make a note
    Culinary, food cooking recipes for FREE – http://www.recipecentral.us
    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 http://www.avazo.com
    Appreciated any info you have

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

  13. April 7, 2009 at 2:08 pm

    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. May 5, 2009 at 7:51 pm

    Perfect domain name blogs.open.collab.net

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

    Find dream job with FREE employment service on http://www.mijob.org

    Also we have

  15. May 13, 2009 at 12:13 pm

    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.
    Regards,
    Stuart Millington

  16. July 15, 2009 at 11:52 am

    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
    July 15, 2009 at 1:33 pm

    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. July 17, 2009 at 7:16 am

    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
    August 3, 2010 at 8:24 am

    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?

Leave a Reply

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

*

CAPTCHA Image

*