On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>>> 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?"
The user decides "what was merged" by passing arguments to the "svn
merge" command. Conflict resolution determines what files constitute
the correct result of that merge.
The user decides what "svn merge X Y" looks like, and only they can be
the authority on that. It may involve fixing semantic conflicts, it
may involve throwing away half the tree: that's up to the user. But
it has no bearing on whether the result is to be considered a merge
from X to Y. That is the meaning of "svn merge X Y".
Conflicts are Subversion saying "I need help merging these two paths;
here's how I'm confused". Solving that confusion does not change the
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.
We seem to disagree on what mergeinfo is for. Here's a case where I
want subtree mergeinfo:
1. Branch X merges from trunk. All mergeinfo was at root of X prior
to the merge, and it is so after the merge.
2. A subtree of X merges from a subtree of branch Y. Now there's a
mergeinfo at the root of X and at the root of the subtree.
3. Branch X merges from trunk again. We still need mergeinfo at X and
at the subtree, because the subtree contains revisions (from Y) that X
does not.
4. Branch X merges from branch Y. Subversion uses its extra info at
the root of the subtree to help with the merge.
At the conclusion of #4, Subversion will probably still have mergeinfo
at the root of X and at the root of X's subtree; the subtree mergeinfo
property is redundant now because both X and the subtree include all
the same revisions of the trunk and of branch Y.
In an ideal world, Subversion could remove the now-redundant subtree
mergeinfo after #4; I'm not asking for that. But it would be a *bug*
for it to have separate subtree info after #1. That it does, is what
I'm reporting.
In case this helps, here's what's motivating my report. We have a
policy against subtree merges: users are only allowed to commit merges
performed between branch/trunk roots. We enforce that policy by
rejecting commits that add svn:mergeinfo properties to interior nodes.
In my understanding, this is a correct way to enforce the policy,
because subtree merges are what interior svn:mergeinfo properties are
for.
--Pete
Received on 2015-03-17 16:58:44 CET