How do others handle product branding in source files?

I've already done most of that.

For instance, we have a strings file. Developers are adding to this strings file for each release. They use techie speak in their version.

I have a copy of this strings file for each customer. They rewrite these strings as they see fit. Then as part of my build process, I overlay the original version of this file with the customer's version and run a build. pretty simple.

But now we're on the next release and there are new strings to be customized. How do I get the new strings into the customers' file so they can rework them?

I could merge the changes made to the base file into the customized file. That would be messy unless I had fenceposts of static text that the merge process could lock onto to figure out which strings had changed. I think I solved this by splitting the strings across two lines. The first line holds the label and the second line is the string and since the labels never change, this seems to work okay.

So, should I create a branch for each customer and keep their customizations in a branch? That would allow me to use the standard build tools, but I would have to merge their changes from a branch based on release 1 to a branch based on release 2. Then patches could be done by simply merging from base rel 2 branch to the customized rel 2 branches.

Or should I stick with my copy methodology?

to put this another way, should base product changes merge to customization branches or should the customizations be applied to the base branches. I suppose the answer may depend on whether or not I could ever conceive of releasing a customized build without the latest changes. That would be most easily done using the merge from base to custom method.

I was kind of hoping someone had some tools to help with this.

jlm --

If the strings file is the only thing that changes between customers, I wouldn't recommend separate customer branches. As I've thought through the problem, I think the following might be useful to you:

As you move forward on your mainline, branch off for each release, letting that branch become a maintenance branch. These are customer-agnostic.

Keep your strings files together in a place in the repository, but in their own folder. Of course, whenever a branch is made, this folder is branched with the rest of the codebase, so you have strings files that stay pertinent for that release. However, as the developers continue on to new releases, the strings files in the mainline will morph and evolve as you and the developers add/delete strings and customers.

Whenever you do a release, whether it be from the Head or from some branch, your release process can include whichever strings file corresponds to whichever customer you're releasing for, copying the file from the container folder.

One of the keys is that whatever strings files are on Head of the mainline are the very freshest and only reflect your latest version.

If you are using Subversion as your repository, for example, the developers can easily check out the customer strings folder and edit it.