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.
