Version control "best practice"

Question

I've been reading all the questions here on the subject of version control, but I don't think i found a scenario that looks like my own.

The scenario is:

we've got a medium/large sized web application that has (at least it should have) a core that is deployed to all clients. When we make demos of the application to the clients almost all of them request changes to the layout, or the data in the listings, or fields in the data entry forms, etc... Almost all of this changes require changes in the remaining "layers" of the application.

In our present situation we are using CVS (with tortoiseCVS) and we dont use branches, we use tags to differentiate the code changes to the application (yes I know it's pretty bad). This brings a lot of problems when we want to make a release to a specific client, and check-in changes, etc.... To prepare a release always takes around 1-2 days of work and sometimes it still breaks.

Sometimes, a request from a client also gets included into the core to be distributed to all clients.

So my question is: Are branches the best way to isolate the changes to the customized client versions of the application? Should we branch whenever a new client asks for customization? Or should we treat it as a complete different project, with a different repository?

All the different versions will have to be maintained, and as I've heard that branches are "temporary" I'm having doubts if branching is the best solution.

Thank you for the response.

Antonio Dias

Answer 1

I don't know why you think that branches are temporary - they will exist as long as you want them to.

Your application sounds as if it could benefit from restructuring to implement more modular functionality, but in the meantime you can develop the main functionality as the trunk, with each customer version becoming it's own branch.

Modifications to the core code can then be merged into each branch as required. Customer-specific changes can be made in isolation on that branch, or merged back into the trunk at a later date.

Separate repositories for each customer sounds like completely the wrong thing to do, as it would result in duplication of common code between repositories.