Julian Foad wrote:
> 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
This is exactly correct. The post was motivated by
people now and then proposing that "if we limited
SVN merge this way or the other, things will be
much simpler". Limiting SVN's capabilities does not
appeal to me but I'd like to offer some guidelines
that people may adopt at their own choosing.
> 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 ...
I'm not ignoring it. This is rather an implementation
note. The merge from ^/sub-branch into ^/branch will
show up in the merge-info delta of the current merge
attempt from ^/branch to ^/trunk. Since the sub-branch
merge already took place, there is nothing left to be
checked for validity.
>>> * 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. ...
Yes, this is a weak point. A strict branch (and merge)
hierarchy is very useful, in my experience. But there
must be some formalized exception to the rule such that
the rule may still be enforced. One way to do that may
be a user-defined path regex or a limitation to specific
users etc.
>>> * 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. :)
I (partly) disagree. Subversion's semantics of branches
being a sub-set of copies is correct. The only problem
I see is that other sub-sets like moves and splits are
not recognized as such.
>> 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.
The scripts may need to handle / ignore deleted mergeinfos
on sub-tree nodes in that case.
>>> * 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?
This covers a case where the user probably accidentally
merged files or sub-trees that don't correspond to each
other. E.g. merge from ^/branch/path/foo into unrelated
file ^/trunk/foo.
Maybe, this should be called "unrelated merges".
>>> * 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?
It may simplify future merges, i.e. reduce the risk of
conflicts.
But I agree that this is a very restrictive policy.
Again, I'm not proposing to limit the SVN library
implementation in any way. If the user wants to apply
restrictions, server-side hooks seem to be the way
to go.
-- Stefan^2.
Received on 2012-04-20 22:40:20 CEST