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

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.