On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de> wrote:
[snip] > 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" [1]. Paul gave a very interesting explanation in that thread as to why URL-[WC|URL] copies/moves currently generate explicit mergeinfo [2] (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 :-). -- Johan [1] http://svn.haxx.se/users/archive-2010-11/0357.shtml [2] http://svn.haxx.se/users/archive-2010-11/0466.shtml
