On 16.03.2015 19:02, Pete Harlan wrote: > On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan <pchpubli...@gmail.com> wrote: >> As you pointed out, my original report erroneously focused on >> svn:mergeinfo appearing, when the real issue is that the new >> svn:mergeinfo doesn't disappear (still) when the user marks the >> conflict resolved. (And I haven't found a way to remove it besides >> propdel; "svn merge --record-only ^/trunk" has no effect afaict.) >> >> My expectation as a naive user is: I initiated a merge from the root >> of a branch (or trunk), I told svn to merge the root of another branch >> (or trunk), and I resolved all reported conflicts (however complex). >> Unless I've explicitly told svn otherwise, I expect svn to consider >> this a full merge, and not create separate mergeinfo for any interior >> nodes. >> >> So I think it would be worth updating "svn resolve" to, by default, >> take action to trust the user and mark this as a full resolution. If >> the user needs to take an extra step or add a new parameter to get >> that effect, would that not feel like a regression compared with 1.7? > A colleague argued that creating the mergeinfo for a subtree in this > case (root->root merge) is a simple bug because mergeinfo says what > inputs were considered to come up with the result, not just those that > were used. > > 1. If the resulting mergeinfo is the same as for root then it's > unnecessary, so the bug is that it is explicitly listed at all. > > 2. If the resulting mergeinfo is different than then root one then > it's incorrect, because it's claiming that the subtree working copy > represents the merge of a different set of branches and revisions than > the root working copy it's included within. > > In other words, it would always be wrong for a merge to introduce > explicit mergeinfo for a subtree of the merge point. > > This implies that the fix wouldn't be to change how resolve works, it > would be for "svn merge" to not create the property on the subtree in > the first place. > > What do you think?
In an ideal world, you colleague's argument would be wrong: the merge should record what was actually merged, not what the merge command intended. So, in cases as the one that started this discussion — when part of the tree cannot be merged due to a conflict — the mergeinfo should report that. Removing that not from mergeinfo should be an integral part of the conflict resolution. In other words, mergeinfo should always show what /actually/ happened, not what we wish had happened. -- Brane