Merging from branch to trunk with 'Merge range of revisions'

7
votes

I have merged in Subversion/TortoiseSVN like this a few times:

Method A:

  • 1) I change the trunk and commit.

  • 2) I make other changes in a branch and commit.

  • 3) In a working copy from trunk: I merge from the branch using TortoiseSVN's 'Merge a range of revisions'.

  • 4) Then I commit the trunk and delete the branch.

However, the TortoiseSVN-manual recommends the following instead of 3) and 4):

Method B:

  • 3*) In a working copy from the branch: Merge changes from trunk using TortoiseSVN's 'Merge a range of revisions'.

  • 4*) Commit the branch including trunk changes.

  • 5*) In a working copy from the trunk: Merge changes from the branch using TortoiseSVN's 'Reintegrate a branch'.

  • 6*) Commit the trunk and delete the branch.

I find A much easier and have not found a reason why I shouldn't do it like that.

What are the arguments for method B, or A, when merging from a branch back to the trunk?

2
svnmergebranchtrunk
Just updated my answer to respond to your comment. – VonC

2 Answers

11
votes

It is call "rebasing" before merging back: you "rebase" (or update) your local branch with trunk evolutions before merging back that local branch to trunk.

It allows for slow resolution of the merge within your "a branch", with possible intermediate commits.
Then, when all is done, you can do a trivial merge back to trunk.
That way, you do not have to delay commits only because you are merging on trunk (since only stable commits should be allowed on trunk).

Would you consider it harmful to use approach 'A'?

No, if the merge is a trivial one, with a predictible result. In that case, approach B would be a waste of time, an extra merge which is not needed (and you should always seek to make as few merges as possible: each of those operations can be error-prone)

But if the result is not well defined in advance, then approach 'B' is definitively recommended, and allows you to explore the result of the merge in your own branch, before impacting 'trunk'.

Both approaches are useful, one should not seek to apply only one or only the other, but the one most adapted to the situation at hand.

0
votes

Regarding Merge range of revisions versus Reintegrate a branch:

Following Method B results in having two kinds of commits in branch:

  1. Changes unique to branch
  2. Trunk changes picked from trunk by doing successive Merge range of revisions

When merging back to trunk, you must pick only changes unique to branch. This is done by Reintegrate a branch.

Using Merge range of revisions at the end would bring to trunk a mix of both duplicated trunk changes and private branch changes.