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

Question

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

Answer 1

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.

Answer 2

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.