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:32:46 CEST