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.