subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Harlan <pchpubli...@gmail.com>
Subject Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in subdirs
Date Tue, 24 Mar 2015 18:24:03 GMT
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@gmail.com> wrote:
> On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej <brane@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

Mime
View raw message