Some projects I work on have a main line of features, but are customizable per customer. Up until now those customizations have been implemented as preferences, but now there are 2 problems with the system...

  1. The settings page is getting out of control with features. There are probably some improvements that could be made to the settings UI, but regardless, it is quite cumbersome setting up new instances for new customers.
  2. Customers have started asking for customizations which would be more easily maintained as separate threads instead of having tons of customizations code.

Optimally I am envisioning some kind of source control in which features are either in the main project line and customizations per customer are maintained in a repo per customer set up. The customizations per project would need to remain separate but if a bug is found and fixed in a particular project, I would need to percolate the fix back to the main line and into all of the other customer repos.

The problem is I have never seen this done before, and before spending time trying to find source control that can accommodate this scenario and implement it, I figure it best to ask if anyone has something less complicated or knows of a source control product which can handle this with very little hair pulling.


Since you are already talking about making separate builds for each customer why not implement each feature under its own compile switch. Then when you build have a separate makefile for each customer with the appropriate #defines included. This would allow you the following:

  • There is only one place to fix bugs, this alone is worth a lot since having multiple places to check a fix is a ticking time bomb. No matter how hard you try there will be some change that doesn't make it into all branches, if only by accident.
  • If another customer requires a feature that is already implemented you can just add the define to the makefile.
  • This is essentially what is happen now, only instead of being a compile switch, its just a setting that is checked at load time. I'm not sure this will make the project more manageable... but I'm not sure what I have in mind would either. – Nick Larsen Feb 1 '11 at 13:55

This is definitely possible with branching. Imagine your main productline as a river. You would make branches for the individual customers these would be tributaries off the river. Primary product development would continue on the main product line and when features are ready for the other branches, you would merge them up (essentially the river flows back into the tributaries again). Sometimes, a problem is identified and fixed on a branch, if the fix is useful for the main product line it's merged back down to main and from there can be merged to the other branches.

If you're using Visual Studio and TFS there is a document that discusses various branching strategies including the one I just mentioned.

If you have a choice of version control (i.e. you haven't committed to one yet) I would go with one of the DVCS's (Distributed Version Control Systems) like Git, Mercurial, or Bazaar. Branching and merging is so much simpler with them.

  • Also, I believe AccuRev caters for this kind of scenario (and their streams are closer to your analogy of a 'river' :) – Benjol Feb 1 '11 at 6:18

We have a couple of products with something similar.

One system is set up by having libraries with the base code and other support and then relatively small (code-wise) customer specific apps are built using those libraries. That's for code based changes.

Another product has a single codebase and generates configuration packages for each system to be installed. The code is installed, then the configuration package for that system is installed. The configuration packages are built from files within the same codebase as the executable deliverable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.