SVN: Partial reintegration of a branch?

I'm using SVN for version control (with Eclipse / Subversive).

We have a branch and a trunk. The branch is for a specialized version of our project. Often, we experiment some changes in the branch, and then decide that those changes are useful in the main-project (trunk) too. But not ALL changes of the branch are needed in the trunk. Some really need to stay only in the branch, since they're only suited for the special functions of that branch.

I would like to be able to choose the files that are reintegrated. Ideally I'd like a Synchronize-view from the branch to the trunk BEFORE doing the merge/reintegration, but this isn't possible.

How would you deal with this situation?

I can describe how you do this from Subclipse, and also how you would do it using the command line.

First off, you would not use merge --reintegrate. Ideally, the changes you want to merge were all committed in one or more specific revisions on the branch. You would then simply merge those revisions from the branch back to trunk. Subclipse provides a simple UI for selecting the revisions you want to merge from the branch back to trunk it is the "Merge range of revisions" option on the merge wizard. If the revisions contained some other changes you do not want you would have to revert those before committing the merge to trunk. You can do this easily from the Merge Results view.

Let's pretend that when you committed the merge to trunk it created r100

You now want to update your branch so that r100 is not merged back to it the next time you synch it with trunk. So to do this you use merge -c 100 --record-only on your branch. In Subclipse UI, this is the "Block revisions" option on the merge wizard. This updates the mergeinfo on the branch and you just need to commit it to the branch. Once you have done this, future synch up merges with trunk will not try to merge that revision back to the branch.

Once the branch is done, a normal merge --reintegrate should still work fine and you will not have any problems due to the changes you have already merged from the branch.

I would advise against trying to manage two independent dimensions of variance (release and feature) with a single version control system mechanism. That is just going to give you an initially small, but endlessly growing, headache. The branches will diverge over time, and you will be stuck doing selective merging forever.

http://martinfowler.com/bliki/FeatureBranch.html

Feature Branching is a poor man's modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging.

Best bet is to bite the bullet and restructure the code so that unique code for different variants mostly go in different files. Then just have a few files that use a dependency injection mechanism, or just #if, that mention both variants and set up configuration of the right set of Strategies and Factories and so on.

Alternatively, have two teams. When changes are needed to be made to both variants, do them twice. That's at least scalable and predictable.