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
