subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <>
Subject Re: Merge policies
Date Fri, 20 Apr 2012 22:07:29 GMT
Am 19.04.2012 16:02, schrieb Julian Foad:
> Stefan Fuhrmann wrote:
>> The following pre-commit scripts / policies would be useful.
>> * Common parts [not a policy]
>>    We first check whether the commit contains a changed
>>    svn:merge-info property. This limits the performance
>>    impact on non-merge commits and we need to identify
>>    all changed svn:merge-info anyway.
>>    Also, the merges that happened on the source branch
>>    from a different location than the target branch are
>>    of no interest for the policy checkers. E.g.:
>>    r20: merge r19 from ^/sub-branch to ^/branch
>>    txn: merge r10-20 from ^/branch to ^/trunk
>>    Both merges will show up in the merge-info delta but
>>    we only need to evaluate the second one.
> It took me a few minutes to realize that you mean
Sorry for that! I often work out details of my ideas
while I'm writing them down. So, the presentation
isn't as refined as it could be ...

> the hook is analyzing a commit to ^/trunk and is seeing mergeinfo additions that indicate
both a merge from ^/sub-branch and a merge from ^/branch.  And in this example the merge from
^/sub-branch was in fact a merge to ^/branch, which was committed in r20, and which is now
propagating to ^/trunk.
> In order for the hook to figure that out, starting from just looking at the mergeinfo
change (which doesn't say what the target of each merge was), it has to examine revisions
10-20 of ^branch and notice that one of those revisions (r20, in fact) was the other merge
that it's considering.
> That's OK, it can do that; I'm just clarifying how it can figure out which merges "happened
on the source branch".

And it might get costly. But that remains to be seen.
> I'll assume the admin can configure each of these policies to apply differently on different
branches.  That's mostly just a matter of inventing a suitable configuration scheme, presumably
with branch name pattern matching or similar, and that would be totally necessary in a large

Agreed. There could also be user-based exceptions,
i.e. experts might get full freedom as a fallback option.
>> * No distributive merges
>>    For each path being merged (i.e. having a merge-info
>>    delta), the relative paths in source and target must
>>    correspond (i.e. start as the same and then may get
>>    renamed etc.). This is basically the same as the
>>    "sophisticated" part of the check for strict merges.
> In other words: in any subtree merge (that is, when a subtree of the branch root is being
merged separately or differently from its parent or the branch root), the 'source-left' subtree
and the 'target' subtree must be traceable back to a common ancestor.  In the absence of any
renames or replacements inside either branch, this would mean that the two subtrees have the
same relpath within each respective branch.
> What we're rejecting here is any attempt such as:
>    mkdir trunk/subtree1 trunk/subtree2
>    copy  trunk branch
>    merge "trunk/subtree1" into "branch/subtree2"

Correct. And some users might do that accidentally
depending on the size / complexity of the source tree.
> Agreed, that policy is both almost universally useful, and is required from a functional
point of view when we're doing "automatic" merges because the merge code needs to be able
to trace them toward a common ancestor.
> So I think such a merge would be rejected by the current (1.7) automatic-merge code already.
 (Haven't tried.)
> Note: We also support a non-automatic merge, called a "2-URL" merge, where merge tracking
is not attempted, and that (as I understand it) may allow such a merge.

Basically a merge between unrelated paths.
>> * No criss-crossing
>>    Prevent situations like the criss-cross examples here:
>>    For a merge A->B, abort if there has been a merge
>>    B->A after the last revision of A to be merged to B.
> Agreed.  I believe getting into a criss-cross situation would very rarely be intentional
and would in general make the next merge more difficult than it would otherwise be.
>>    This only valid for non-cherry-picking merges and
>>    only if the change sets of both merges overlap.
> Yes; I haven't fully grokked the detail, but I agree there's no need to stop cherry-picks
crossing over.
>> Except for the last one those checks will simply verify
>> that the user followed certain policies. They should,
>> therefore, rarely reject a commit.
> Why do you suggest "no criss-crossing" is an exception?  It seems also to be just verifying
that the user followed certain policies.

Criss-crossing is hard to prevent by pure policy.
As soon as more than one user can do merges
(e.g. one pulling in from the branch while another
updates that branch), those processes may overlap
in time. That causes a criss-crossing merge graph.

-- Stefan^2.

View raw message