Stefan,
What I understand you're saying is:
Here are some bits of merging policy, which users quite commonly may wish to enforce for some of their branches. And in particular these are bits of policy that could perhaps be enforced by means of hook scripts. If we help to create a bunch of such hooks, then users (and their admins) could more easily set up some merge policy enforcement which would help them to avoid accidents such as a user merging onto a different branch than he thought it was.
Is that right? Sounds useful to me. (Haven't studied the details yet.)
- Julian
Branko Čibej wrote:
> On 19.04.2012 12:48, Stefan Fuhrmann wrote:
>> 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.
>
> Ignoring aggregate mergeinfo strikes me as an over-simplification. I
> can't point my finger at why right now, but the idea makes me
> uncomfortable ...
>
>> * Strict merge hierarchy
>> A merge from A->B is only allowed, if the copy-from
>> of A is B or vice versa and the copy source has not
>> been replaced since the copy). This prevents circular
>> merges and others (note 1).
>
> This would prevent merges between sibling branches (e.g., branch A->B
> and A->C then merge B->C). This situation is rather common, for example,
> it happens in our release branch maintenance workflow every time we have
> to create a backport branch for some non-trivial change. You cover that
> in (note 1) but also mention naming conventions, which makes me want to
> light fuses on some very big firecrackers. ...
>
>> * No sub-tree merges
>> Like the above but without the check for parents.
>
> The "like the above" had me scratching my head for a while there. I
> always have to remember that Subversion doesn't really have branches ...
> never mind. :)
>
> Other than that, I think this is a reasonable restriction, as long as it
> doesn't prevent people from merging branches that already have subtree
> mergeinfo.
>
>> * No aggregate merges
>> There must only be one source branch, i.e. we can't
>> merge from branches A and B to C in the same revision.
>
> I can't think of a case where splitting such a merge into two commits
> would change the semantics of the operation, so +1.
>
>> * 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.
>
> I don't understand this case. Can you elaborate with a more detailed
> example, please?
>
>> * No cherry picking
>> Check that the source branch does not contain revisions
>> that lie before the last to-be-merged revision but
>> have neither been merged before nor are being merged
>> right now.
>
> I'm not sure this is a good restriction to have. Cherry-picking is an
> almost indispensable merging tool. We use it all the time when
> backporting changes to maintenance branches. Since the merge algorithm
> will have to account for cherry-picks in any case, what benefit would
> the user get from enabling such a restriction?
>
> -- Brane
>
Received on 2012-04-19 13:55:01 CEST