On Sat, Mar 14, 2015 at 4:05 PM, Pete Harlan <pchpublic88_at_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?
Thanks,
Pete
Received on 2015-03-16 19:03:01 CET