On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> 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
Doesn't the conflicted state of a path already indicate what actually
happened? There can be no mistake about those portions of the merge
being incomplete.
If the svn developers do decide that introducing mergeinfo for [some?
why not all?] conflicted paths is the correct scenario, I would think
that that shouldn't be done until resolve knows how to clean it up.
Pete
Received on 2015-03-16 22:16:33 CET