tags:

views:

55

answers:

2

Here is the scenario:

We have a source tree that has multiple developers working on multiple branches at any given time.

We also have a 'custom' copy of this source tree with differences that will (almost) never make their way back to the main source. The development on this is continuous, but with a lot fewer changes than what's on the main branch.

The custom version needs to stay up to date with the changes in the main source, while keeping it's customizations.

Currently the way we're handling this is something like:

Main Release (call it 1.2b) is branched from main source tree. Custom release (call it 1.2b.custom) is branched from 1.2b. Changes from the previous custom release (1.2a.custom) are merged into 1.2b.custom. Changes from 1.2b are merged into 1.2b.custom as required.

Rinse, repeat, currently running through the 10th? iteration of this since I've been here.

This works 'ok' - but it leads to a lot of merge conflicts, every, single, time that we create a new custom release. It also has the effect that history is 'lost' - looking at the history for a file on the 1.2b.custom branch shows the history from the 1.2b.custom changes, the 1.2a.custom merge, but not the actual commits on the 1.2a.custom branch. Additionally, it restricts the ability of making changes to the custom branch, as there is nowhere to do parallel development on the custom stuff (ie: working on trunk for next release while maintaining/fixing bugs on the current release)

I'm looking for suggestions on how we can handle this better. One thought I've had is to pick a point and 'fork' the custom into it's own trunk, there would still be issues merging changes from main (branches or trunk) -> custom trunk, but I think this 'fixes' the history, as well as allowing parallel development on the custom. Other ideas or resources I can look through?

Thanks.

+1  A: 

It sounds like you should treat the main tree as if it is a vendor supplying source code. The subversion project has a good discussion of how to manage that.

PanCrit
A: 
Michael Hackner
Not quite. The releases are separate, they're deployed as different applications. Both live on, but as different products.
shelfoo