Subversion rebase

rebasesvnsvn-reintegrate

I find this way easier to merge branches and less conflicts:

Copy trunk to a new branch, merge it with feature branch/s. When things done, merge the new branch back to the trunk. This technique is quite like the mercurial and git rebasing.

I used to merge whatever changs from trunk to feature branche/s. But later when I merged the feature branch back to trunk, some of the stuff from trunk would be merged back again to the trunk, which caused a lot of conflicts. There is a choise of reintegrate merge, but it didn't seem to work for me.

Does anyone do similiar subversion rebasing? I just started doing this recently, and haven't seen any side effects. Would this cause any unforseen problems?

Best Answer

Generally speaking, rebasing is the act of incorporating upstream changes into a feature branch, before merging the feature branch back into the upstream branch.

In git, the process is even more sophisticated, because the changes that have been made since the branch was created are first taken off and buffered, the upstream changes are applied, then the buffered changes are applied. The takeaway here is merging trunk into a feature branch is not a rebase in git terms, there's more to it. The git approach has a number of advantages, but can't be implemented very cleanly in svn since all commits must be stored on the server (svn is not distributed), however it can be done in svn.

An 'svn rebase' (the git way) might look something like this

  1. svn cp trunk feature
  2. commits to feature & trunk
  3. svn cp trunk feature-rebase
  4. svn co feature-rebase
  5. cd feature-rebase
  6. svn merge feature
  7. svn commit
  8. svn rm feature
  9. svn mv feature-rebase feature
  10. (back on feature-rebase WC) svn switch feature

Then eventually on a working copy of trunk, svn merge --reintegrate feature

You see the difference from simply merging trunk to the feature branch? You start with the latest from upstream, trunk in this example, then merge the changes from feature onto that.

Imagine some of the commits on trunk could come from a merge of another feature branch into trunk, so I am not at all advocating committing directly to trunk.

Related Topic