views:

144

answers:

4

I'm currently using subversion to manage my source code and I've come to a point where I need to brand the software I'm working on for a client. All the branding is handled in the project resources so changing the look for a client is very simple. What I'm running into a problem with is maintaining the branded version of the software in the source repository. Right now it's a separate branch, but when trying to merge the changes from trunk to the branded branch, it happily overwrites the branded resource file.

What would be a good way to maintain those differences but still be able to easily checkout everything you'd need to build a release for either the trunk build, or the build with the custom resource file?

A: 

The branding should be the top-level project with the core part of the project as a child (or dependency depending on your project inheritance model). In subversion, you can use externals to include the core product source code in the top level product, or you can build the core product and use the top level project to create the final "assembly".

Steve Moyer
actually, he does: "currently using subversion"
warren
yeah ... I totally missed it, submitted and immediately had to edit;)
Steve Moyer
+1  A: 

You could make the branded relaease a seperate repo that uses the vanilla branch as an external.

The alternative would be to keep everything in a single branch and have the build-process do the work of selecting which branding-specific files to use.

+1  A: 

You need to keep the branding as a wrapper around the core technology, that's how every other project I've known does it.

However if you didn't think about the project like that from the beginning you may need a week or two to refactor everything.

Ideally you shouldn't need the branch, but having it is a good idea anyways, just for sound engineering principles and to protect your client's code stability. As mentioned the branding should be something that can be done either at compile time or runtime using some sort of packaging.

Robert Gould
A: 

Well, you can either use merge sets, where you just merge a range of commits, or you can keep keep the branded resource file(s) in a separate directory on the root of the branch(es)? Then when merging, just choose the directories in the root excluding the branding one.

I like merging just a range of commits, as that avoids blowing away new work on the branches. But if you need to merge everything, you could move your project to a subdirectory (e.g.: "Source") and the branding to a second subdirectory. Then in Eclipse or whatever you can just choose to merge from trunk/source into branch/source.

e.g.:

this:
/svn/proj/trunk/a
/svn/proj/trunk/b
/svn/proj/trunk/c
/svn/proj/trunk/d/e/f/branding

becomes this:
/svn/proj/trunk/source/a
/svn/proj/trunk/source/b
/svn/proj/trunk/source/c

/svn/proj/branch/branding
/svn/proj/branch/source/a
/svn/proj/branch/source/b
/svn/proj/branch/source/c

Rick