Branches for Every Little Change?

Question

We have a client (who has a client, who has a client) who is driving us mad with change requests to a code base (in PHP). Our first response was to just work in a main trunk in SVN, but the client often comes back and requests that a certain change needs to get pushed to the live servers ASAP. On the other hand, other changes get reduced in priority suddenly, which originally came grouped with other changes (seemingly).

We are thinking of using a branch for every change request. Is this mad? What other solutions might work?

Thanks!

Edit: This is a really hard question to choose the correct answer for. Thanks to everybody for your great answers.

Edit: I know that the best answer I chose was not particularly popular. I too wanted to find a technical solution to this problem. But now I think that if the client wants software with features that can be deployed in a modular fashion... this problem should not be solved in our use of the version control system. It would have to be designed into the software.

Edit: Now it's almost a month later and my coworker/client has convinced me that multiple branches is the way to go. This is not just due to the client's insanity, but also based on our need to be able to determine if a feature is "ready to go" or "needs more work" or whatever. I don't have the SVN with me, but we merge using the advice from the SVN Cookbook: you merge the branch from the revision it was branched to the head revision.

Also, using this system, we merge all branches at some point and that becomes the new QA and then live build. Then we branch from that.

Last Edit (Perhaps): Months later, this system is still working out for us. We create branches for every ticket and rarely have problems. On the other hand, we do try to keep things separate as far as what people are working on...

Two Years Later: We use GIT now, and now this system is actually quite reasonable.

Answer 1

A branch for every change request sounds like overkill and maybe some trouble later.

try to group the change requests into logical areas so that you can see that a particular set of changes has a logically related effect on the application. Create branches for these.

I think that the real answer to the question though is to fix the client. You need to make it clear via a contract that these arbitrary change request is going to cost them money and it might slow them down. If this keeps up, your svn repository will be the least troubling aspect of the project.

Answer 2

Perhaps Subversion here is not the best tool for the job. Although creating all these branches is cheap in SVN, re-merging them can become time-consuming and painfull.

If you have a look at GIT instead of SVN, you will find a version control system which is more powerfull at merging in general. Added to that, it has the specific feature of "cherry picking". That is, single commits can be easily "picked" from one development tree and added to another (the live branch). Also, it is easy and convenient in GIT to merge several commits into one single one (you can even add to a specific commit from another tree).

So building up single-feature commits and then cherry-picking them could be the solution for you.

Answer 3

What about creating a branch for your client's live version, a branch for your new development and a branch for your ongoing changes.

Work in the new development branch when you're not being inundated with tasks.

Work in the ongoing changes branch when you're fixing all that fun stuff they keep driving you crazy with. When you've got a fix, merge it to the "live" branch and to the "new development" branch.

That way your client's distribution is in its own world, your new development continues on (and can be merged whenever you need it) and your maintenance is also captured.

We work in a new development branch, then each time we decide to make a patch, we branch the trunk and then send that patch off for Q/A. If it goes back and forth a while, we work in that branch to fix those issues merging back to the trunk where necessary to ensure everything is in sync. If something came back long after the fact which needed to be addressed in a previous version, we can always fix it back in that branch, then again, just merge it into the trunk.

Answer 4

The scenario explained by the thread opener is an example of the feature branches pattern: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

They are very usefule when you have to keep the main development line (the trunk) stable and you have to develop lots of features that potentially could break the main line.

The downside is that you have to keep the various branches in sync with the trunk: while a branch for feature A is in development, a branch for feature B can have reached a stable status and get closed and merged in the trunk: in this situation, you have to merge the changes introduced by the B branch from the trunk to the A branch. So, it's a good habit to merge often the branches with the trunk to avoid the problematic situation of a unique big merge at the end of the branch life with lots of conflicts to track down and resolve.

Answer 5

Branch per change request, with the corresponding increase in cost to the client for the additional management, is a fine approach for this problem.

It will cost you more, in terms of time, resources available to be working on other features, etc, but with a lot of unrelated changes, or project features that get stalled or canceled, it is probably one of the better approaches.

This is really SCM system agnostic - but Subversion can certainly do what is needed.

Answer 6

Branch per tested, working change.
Tag per version release.
Develop in trunk.
Repeat.

:)

Answer 7

Have a branch for every RELEASE. Combine as many changes into a single release as make sense - having more branches is generally good, you can combine them easily in most cases, breaking them apart is a little more tricky.

Having a branch for every release means you also have a branch for what's currently on production (or what's just ABOUT to be released when releases are pending after the merge but before the actual deployment).

That's what we do anyway.

Answer 8

At my workplace we have the following system:

• Stable branch: This is where tested and verified stable code goes.
• Maintainance branch: This is where fixing bugs in stable is done. When things are verified to work it is merged down to stable branch.
• Project specific branches: Each sub-project in our product has one branch. At a specified time during the year all the projects to be included in this year's release are merged into the "Release branch". This is so all the merging and stuff isn't done a week before release.
• Release branch: This is where all the messy development of the current release is happening after the sub-projects have been merged. Merged with stable after release is done.

Answer 9

With git, I do make a branch for every little change, and I love it!

Answer 10

When doing lot of rapid changes in the "live" branch of a project, you need to have a solid code review process to reduce the chance of breaking it. The code review must be done before doing the check-in; and keep away the core development from that branch.

Once the change is approved, you can check-in the change (and/or merge from you working branch) and create a new "tag" once it's done.

Answer 11

When estimated hours are more than 8, use a branch.