s\Software branching model

sadie's picture
sadie asked on October 27, 2015 - 12:47pm | Replies (2).

Hi guys,

I need some expert guidance on svn's branch management.

Currently, in my company where I recently joined is to create a new branch for every bugfix. Developers create branch, fix the code, test it and port the changes into the main branch. We've several main branches per customer which never merges, only certain fixes are ported in the other customer branches if required and I do not think it is a good way of branching. The fix branches are going to increase over time and will become unmanagiable and untrackable. Do you guys have any better ideas on how to plan/manage these branches?


2 Answers

Bob Aiello's picture
Bob Aiello replied on November 20, 2015 - 4:22pm.

Hi Sadie,

you are absolutely correct the use of feature branches is a very dangerous practice, because it typically causes late binding itegration which is the source of many defects and problems (e.g. merge collisions). The best practice today is early or even continious integration. I have worked in organizations where it was absolutely necessary due to specific business constraints. For example, in a trading environment you might need to cherry pick which formulus designed by the quants are going to be implemented. In this case we used temporary integration branches to mitigate this risk.

Tell them to attend one of my classes and I will school em up :-)

Bob Aiello, Technical Editor CM Crossroads

BTW - we have an online class next week!

Joe Farah's picture
Joe Farah replied on December 7, 2015 - 4:22pm.

Hi Sadie,

  Sorry I didn't pipe in sooner.

  I would say your first concern would be having a permanent branch per customer.  Unless you are going to have only a handful of customers forever, this is a dangerous precedent.  Let me first mention that there is never a need for a branch per customer.  You should have a common "superset" branch for all customers, with specific subsets, potentially, for individual customers.  For the most part, and this is a design issue as much as a CM issue, developers should have a rule that says there is a single codeline for all customers.   You may have a few files that have customer-specific variants (emphasize few); you may have some feature files that are specific to one or more customers; but customer-specific variants/files must be isolated and kept reasonably small in number.  Ideally, all such variants are run-time configurations rather than code/CM variants (in which case they might be in a separate run-time configuration data file for each customer).

   I can't stress enough the importance of this.  As your customer base grows, it will become unmanageable.  Already you're compromising by not fixing all problems for all customers.  It's only a matter of time before you start having separate development streams for each customer and that will multiply your development, testing and deployment costs dramatically.
    Secondly, I agree with Bob in terms of not creating feature branches with late integration.  Ideally, after reaching a single common code stream (and this is NOT difficult to achieve), you should have one branch per release that was, is or will be supported.  Unfortunately many tools will not support this philosophy because they do not have the mechanisms necessary to support full CM, and so they overload branching to implement other CM capabilities.
If you ask why this branching is done, the answer is because it's the only way to group the changed files without putting them in the build.  But there are other tools that will do that.  For example, CM+ allows change packages.  These group the files, but they also have a status associated with them and the CM manager can create builds based on the status of changes:  give me all of the changes that have been marked "ready to integrate" by the developer (i.e. not the ones that have been checked in but not so marked).  With that sort of capability, there's no need to have a separate branch to keep the changes out of the build.  In fact you could do a second build that says: Give me everything that's checked in so I can do a sanity test on it while the real development build is going on in parallel.  Similarly, CM+ has Build records so that you don't have to add labels to identify a build, or create a separate build branch that records the build forever.  The build record does that.  In other words, if the CM tool has the right capabiities, you don't need to overload branching to support what you're lacking.  Instead of branches per customer, CM+ uses variant tags so that a file can belong to specific variants when build time comes.  I don't want to create an ad for Neuma (ok, maybe I do), but you need to look at your tools as well.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.