Our windows deliverable has different sets of config files and binary assets for different customers. Right now the configuring is done by hand before packaging and its error prone. What do you think of using branches for each customer, and having the package build/script automerge the customer’s branch with trunk?
I’m less concerned with scalability than I am of getting this automated ASAP.
The entire packag contents is in SVN, but SVN branching and merging is so delicate that I don’t trust it to work consistently when its automated. If you guys like the idea I might try to use git-svn for this, because it will hopefully make merging less delicate. We don’t necessarily have to merge the assets, because they are organized so the installer can just skip inappropriate directory trees, but configuration is not so simple.
I suppose it depends on how many things have to change. For config files, I like to keep a single file under source control and use a build script to set the environment-specific (or in your case client-specific) items.
http://automaticchainsaw.blogspot.com/2008/02/automate-config-changes-for-different.html
For binaries, it probably has more to do with how many of them you have and where they come from. If they are part of a code compile, then the compilation process ideally would create what you need. If they are other resources, such as graphics, perhaps you have a customer-specific set of folders under one directory. The build script would pull in the correct client folder based on a parameter passed to the script. This is basically the branch and merge idea you mentioned in your question.
Regarding your later comment about multi-line config changes – assuming it is xml, you might look at the XmlMassUpdate class in the MSBuild Community Tasks. I’ve not used it myself, but it looks like it might be what you need.