we have multiple clients with different needs. Although our software is modularized to a degree, it's almost certain that we need to adjust every module's business logic here and there a little for each customer. The changes are probably too tiny to justify splitting the module into a distinct (physical) module for each client, I fear problems with the build, a linking chaos. Yet, those changes are too large and too many to configure them by switches in some configuration file, as this would lead to problems during deployment and probably a lot of support troubles, especially with tinker-type admins.I'd like to have the build system create multiple builds, one for each client, where changes are contained in a specialized version of the single physical module in question. So I have some questions:Would you advise letting the build system create multiple builds?How should I store the different customizations in source control, svn in particular?
How to maintain different, customized versions of the same software for multiple clients
versioning;continuous integration
What you need is feature branching-like code organisation. In your specific scenario this should be called Client-specific trunk branching because you'll likely use feature branching as well while you develop new stuff (or resolve bugs).http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.htmlThe idea is to have a code trunk with new features' branches merged into. I mean all non-client-specific features.Then you also have your client-specific branches where you also merge same features' branches as required (cherry-picking if you will).These client branches do look similar to feature branches although they're not temporary or short-lived. They are maintained over a longer period of time and they're mainly only merged into. There should be as little client-specific feature branch development as possible.Client-specific branches are parallel branches to trunk and are being active as long as trunk itself and don't even get merged as whole anywhere.            feature1            .                        \trunk                    \==================================================         \ client1            \       `==========================================           \ client2            \         `========================================                 \ client2-specific feature   /               `