tags:

views:

61

answers:

1
+1  Q: 

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?

A: 

I am using this approach:

With rebasing you have to take care not to take the rebased revisions over when you merge again. When it comes to merging, do a cherry picking: select only the revisions on the feature branch that implement something new, not the rebasing changesets. Then it should work fine. COMMENT: I cannot ever remember having used the reintegrate branch for something. I think it is intended for very simple use-cases only.

In your new approach, it is not clear from the description how you handle the rebase from trunk to your feature branches if you need to. Do you want to completely disallow rebasing? As branching in svn is a cheap operation this could be an option too.

jdehaan
below is my procedure:1. trunk->f1,f2(feature branches)2. when f1,f2 done, trunk->version branch(for integration)3. merge f1,f2 to version branch (VB)4. test VB; merge fixs from f1,f2 to VB; keep this step short, otherwise repeat 2 to 35. when VB done, merge it back to the trunk, release it.
bo