On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
> The following pre-commit scripts / policies would be useful.
> * Common parts [not a policy]
> We first check whether the commit contains a changed
> svn:merge-info property. This limits the performance
> impact on non-merge commits and we need to identify
> all changed svn:merge-info anyway.
> 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.
> * 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).
> In a more sophisticated implementation, we could identify /
> allow for renamed branches as well as A and B having
> the same relative path to some parents that form a
> direct branch (i.e. allow sub-tree merges).
> * No sub-tree merges
> Like the above but without the check for parents.
I just remembered a users@ discussion from way back: "URL-only renames
adds svn:mergeinfo property" . Paul gave a very interesting
explanation in that thread as to why URL-[WC|URL] copies/moves
currently generate explicit mergeinfo  (has something to do with
the fact that merge tracking doesn't "follow" copies/moves).
Just thought I'd mention this here, because that's one of the ways
people can currently (inadvertently) generate subtree mergeinfo. This
can happen when simply performing a server-side rename of a file (for
instance to perform a case-only rename --- prior to 1.7 this couldn't
be done client-side on a case-insensitive platform, so this was one of
the workarounds mentioned in the FAQ).
Don't know if this is relevant to this discussion, so just ignore this
if it isn't :-).
Received on 2012-05-02 17:25:42 CEST