On Wed, May 2, 2012 at 11:24 AM, Johan Corveleyn <jcor...@gmail.com> wrote: > 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).
And that explanation still describes how I feel on that matter, i.e. ambivalent and open to other alternatives. And for some reason the spacing of ASCII diagram I posted in [2] is wrong on svn.haxx.se, it's a lot easier to understand here: http://mail-archives.apache.org/mod_mbox/subversion-users/201011.mbox/%3caanlktin0xjwxg78ru-83qafot-bcfgml_pb2ahwt2...@mail.gmail.com%3E Paul > 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
