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

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.