On Wed, May 2, 2012 at 11:24 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
> <stefanfuhrmann_at_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_pB2AHWt2z1s@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
Received on 2012-05-02 17:42:50 CEST