Question

Before I explain the core issue, let me say that I’m actually quite interested in migrating our source control from Subversion to Git/Mercurial if it really is a better solution for our issues, but I’m really looking for the best solution without causing a lot of unnecessary stress on the team. (In other words, I’m not looking for the “dump Subversion altogether and move to Git” answer, since that involves a lot of thrashing and a steep learning curve.)

Now that’s out of the way, here’s our core issue:

My development team is working with a relatively large Subversion repository, where all development used to be done directly on the Trunk. A request from above for a faster release cycle led us to split our work into separate branches, with each branch containing a mirror of Trunk at the time the branch was created and sub-teams working in parallel on each branch. The new cycle is to release a specific branch to production, then merge the new changes into trunk, and merge trunk changes into each of the other branches.

Unfortunately, this has become a very painful and error-prone process, and we need to find a better way to perform our merges that also takes into account simple changes between branches such as code reformatting (some of us use “cleanup code” on our source files, some don’t).

To summarize, we need help figuring out a better way to merge that doesn’t require one or more of our developers to spend an entire day manually resolving conflicts.

(Sorry if that’s a little vague or rambling; I’ll be happy to clarify or provide more details upon request.)

Answer 1

Take a look at the Subversion documentation here: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html

My suggestion is to merge the branches into trunk using the feature branch merging pattern. One at a time, starting from the one performing less changes/harm.

The new cycle is to release a specific branch to production, then
merge the new changes into trunk, and merge trunk changes into each of
the other branches.

The feature branch merging pattern, basically reverses order for these operations.

As a side note: “cleanup code” is a good idea as far as everybody in the team uses it before commits. It’s impossible for Subversion (or any other VCS) to know which changes are for code behaviour and which are for beautification.