Is it accurate then to say that Subversion may generate explicit
mergeinfo whenever it decides that there is something useful to record
about the set of revisions that contributed to a given node, and that
svn:mergeinfo properties may appear in subnodes as part of normal
Subversion merging bookkeeping, and this doesn't imply lack of a full
root->root merge or other user shenanigans?
I appreciate your time on this.
Thanks,
--Pete
On Tue, Mar 17, 2015 at 8:58 AM, Pete Harlan <pchpublic88_at_gmail.com> wrote:
> 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-24 19:25:42 CET