Subversion rebase?

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?

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.

I wish I had a clever trick to tell you on how to achieve rebasing in SVN but I've always avoided manual refreshing of a branch with trunk changes in SVN mainly because of the complications requiring manual cherry picking that jdehaan mentions.

What I generally do instead is follow the practice of merging changes from a branch to the trunk, deleting the branch, and then recreating the branch from the trunk. This allows me to refresh/rebase my feature branch but with the sometimes unfortunate side effect that any prior changes from that branch are now part of the trunk. For this reason I only follow this practice when a feature branch is at a stable and usable point yet I still wish to continue work on that feature in order to further complete some bigger objective.

What I would prefer is that refreshing a branch by merging trunk changes back into a branch not cause subsequent reintegration merges from that branch to pull those rebased revisions during the process. It should be possible to do this based on the merge-info properties but according to what jdehaan states and what I have feared is that doing this still requires cherry picking.

Note that proper rebasing implementation should also be able to take into consideration stair casing examples where a branch is made from another branch.

Update: According to the Subversion documentation it appears that when using the --reintegrate option that Subversion should be able to properly reintegrate work done in a branch in a way that minds any possible refresh merges that may have been done to bring base changes into the branch. Of course this is is technically a little different than rebasing but i think it is similar enough in usage that it could be referred to as rebasing.

In my company we use following approach:

1. for each task NK-$X in the issue tracker we have a separate branch branches/NK-$X
2. we start work on a task by svn cp trunk branches/NK-$X
3. we never commit changes directly to the trunk. For each schedulled update UPDNK-$X we have a separate branches/UPDNK-$X. We create it with svn cp trunk branches/UPDNK-$X just before the update.
4. when the task NK-$X is schedulled for an update UPDNK-$Y we merge branches/NK-$X inot UPDNK-$Y. That is cd UPDNK-$Y; svn merge -r start:HEAD branches/NK-$X
5. after UPDNK-$Y is ready, we merge it to trunk. That is cd trunk;svn merge -r start:HEAD branches/UPDNK-$Y

If it happens that task NK-$X lasts longer than one iteration cycle, and therefore needs refreshing, we never, ever, NEVER merge trunk to NK-$X. We have a rule that you commit to your branch only things that you wrote yourself, which makes everything easier. Instead we do:

cd NK-$X
svn log
//let L = the number of the last changeset to this branch changeset
//let F = the number of the first changeset to this branch
svn rm branches/NK-$X 
svn cp trunk branches/NK-$X 
svn up
svn merge -r F:L branches/NK-$X@L 
svn ci -m 'refereshed'

This way, whenever you look at the changelog of branches/NK-$X you see only changes actually performed by the developer.

Update: Since the above workflow can be automated, I've started a project on github: svn rebase.