[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge policies

From: Paul Burba <ptburba_at_gmail.com>
Date: Wed, 2 May 2012 11:42:18 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.