Subversion rebase?

Question

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 n

Answer 1

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.