On 16.03.2015 19:02, Pete Harlan wrote:
> 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?
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
Received on 2015-03-16 20:32:56 CET