[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge policies

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sat, 21 Apr 2012 00:07:29 +0200

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 project.

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:
>> http://wiki.apache.org/subversion/SymmetricMerge
>>
>> 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.
Received on 2012-04-21 00:08:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.