On 16.03.2015 22:15, Pete Harlan wrote:
> 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.
"Conflict" is a transient property of the working copy. "Mergeinfo" is
an attribute of the repository and is a permanent record. In most
conflict cases there are at least two ways to resolve the conflict, each
of which could produce a different answer to the question "what was merged?"
> 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.
See above re ideal world ... currently it's far from ideal. One could
argue that it's better to improve some cases, rather than hope to get
them all covered in one go.
In the case we're debating: if a normal conflict resolution leaves
unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If
it doesn't, then it's working correctly, even if not as expected, IMO.
-- Brane
Received on 2015-03-17 02:10:15 CET