On Wed, Sep 19, 2012 at 05:55:27PM +0200, Michael T wrote: > Stefan, thanks for your reply. Would a clean-up like I described (gathering > changesets from all mergeinfo from all subtrees within a branch and setting it > all on the branch root) be even theoretically correct then, or am I being > misled by my incomplete understanding of mergeinfo?
This depends on whether the resulting consolidated mergeinfo really describes all changes that were merged. You could end up marking revisions that were merged only into a subtree as having been merged into the entire branch. If this doesn't reflect what really happened, then the mergeinfo is wrong. The unmerged changes would be blocked from ever being merged into the parts of the branch that have not yet received them. However, sometimes this blocking of changes is exactly what is desired, see http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges So it all depends on what you really want the mergeinfo to say. If you don't know what you want it to say and how to get there, I'd recommend to rely on Subversion to figure it out. After all, it knows how to interpret subtree mergeinfo, and if you use 1.7 clients you'll only ever see mergeinfo changes happen on nodes that were actually affected by the merge (unlike with 1.6). > And would the 71874-75960 > range I mentioned pose a problem for automatic elision, or is it clever > enough > to deal with that? Depends. I suspect I didn't explain Subversion's behaviour clearly enough. Mergeinfo will only be elided from child A/B to parent A if the only difference between the svn:mergeinfo property is a path-wise adjustment. The revision ranges must be exactly the same. For example, this will elide: A - svn:mergeinfo = (/branches/foo/A:50-60) A/C - svn:mergeinfo = (/branches/foo/A/C:50-60) Because the mergeinfo on A/C, path-adjusted to A, matches that of A. And this won't elide: A - svn:mergeinfo = (/branches/foo/A:50-60) A/C - svn:mergeinfo = (/branches/foo/A/C:50-66) The difference being that revisions 61 to 66 have only been merged into A/C but not into A. So elision is not "clever" in any way. All that Subversion does is checking the two mergeinfo properties for equality after path-wise adjustment. Does this clear up your understanding of what you can expect?
