Hi Sadie,
Sorry I didn't pipe in sooner.
I would say your first concern would be having a permanent branch per customer. Unless you are going to have only a handful of customers forever, this is a dangerous precedent. Let me first mention that there is never a need for a branch per customer. You should have a common "superset" branch for all customers, with specific subsets, potentially, for individual customers. For the most part, and this is a design issue as much as a CM issue, developers should have a rule that says there is a single codeline for all customers. You may have a few files that have customer-specific variants (emphasize few); you may have some feature files that are specific to one or more customers; but customer-specific variants/files must be isolated and kept reasonably small in number. Ideally, all such variants are run-time configurations rather than code/CM variants (in which case they might be in a separate run-time configuration data file for each customer).
I can't stress enough the importance of this. As your customer base grows, it will become unmanageable. Already you're compromising by not fixing all problems for all customers. It's only a matter of time before you start having separate development streams for each customer and that will multiply your development, testing and deployment costs dramatically.
Secondly, I agree with Bob in terms of not creating feature branches with late integration. Ideally, after reaching a single common code stream (and this is NOT difficult to achieve), you should have one branch per release that was, is or will be supported. Unfortunately many tools will not support this philosophy because they do not have the mechanisms necessary to support full CM, and so they overload branching to implement other CM capabilities.
If you ask why this branching is done, the answer is because it's the only way to group the changed files without putting them in the build. But there are other tools that will do that. For example, CM+ allows change packages. These group the files, but they also have a status associated with them and the CM manager can create builds based on the status of changes: give me all of the changes that have been marked "ready to integrate" by the developer (i.e. not the ones that have been checked in but not so marked). With that sort of capability, there's no need to have a separate branch to keep the changes out of the build. In fact you could do a second build that says: Give me everything that's checked in so I can do a sanity test on it while the real development build is going on in parallel. Similarly, CM+ has Build records so that you don't have to add labels to identify a build, or create a separate build branch that records the build forever. The build record does that. In other words, if the CM tool has the right capabiities, you don't need to overload branching to support what you're lacking. Instead of branches per customer, CM+ uses variant tags so that a file can belong to specific variants when build time comes. I don't want to create an ad for Neuma (ok, maybe I do), but you need to look at your tools as well.
