[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 2 May 2012 17:24:50 +0200

On Thu, Apr 19, 2012 at 12:48 PM, Stefan Fuhrmann
<stefanfuhrmann_at_alice-dsl.de> wrote:


> 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 :-).

[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:25:42 CEST

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