On Thu, Apr 19, 2012 at 6:48 AM, Stefan Fuhrmann
<stefanfuhrmann_at_alice-dsl.de> wrote:
> Hi all,
>
> After having a closer look at merge and discussing it
> with Julian on IRC, there seems to be no silver bullet.
> However, we identified a few things that could be changed
> and set of constellations that make merge harder than
> it needs to be.
>
> For the first, there will be another post soon. The second
> boils down to policy. Luckily, SVN has a mechanism to
> enforce policies: server-side hook scripts. My proposal
> is to develop a small set of scripts that a user can
> combine to prevent situations that her life harder than
> necessary.
Hi Stefan,
No objections to developing a set of hook scripts to optionally
enforce different merge policies; that seems completely reasonable
(I'm not expressing an opinion one way or the other regarding the
details of the particular scripts).
Just one thing I'm wondering about:
> This should give us enough time to improve
> the merge logic inside the SVN libs.
Which improvements are these exactly? What is documented in
http://wiki.apache.org/subversion/SymmetricMerge?action=show&redirect=SvnMergeTheory
or something more?
Also curious about your mention of "Enough time", is there a deadline
your group is under?
Paul
> 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.
>
> * No aggregate merges
> There must only be one source branch, i.e. we can't
> merge from branches A and B to C in the same revision.
>
> * No distributive merges
> For each path being merged (i.e. having a merge-info
> delta), the relative paths in source and target must
> correspond (i.e. start as the same and then may get
> renamed etc.). This is basically the same as the
> "sophisticated" part of the check for strict merges.
>
> * No cherry picking
> Check that the source branch does not contain revisions
> that lie before the last to-be-merged revision but
> have neither been merged before nor are being merged
> right now.
>
> * No criss-crossing
> Prevent situations like the criss-cross examples here:
> http://wiki.apache.org/subversion/SymmetricMerge
>
> For a merge A->B, abort if there has been a merge
> B->A after the last revision of A to be merged to B.
> This only valid for non-cherry-picking merges and
> only if the change sets of both merges overlap.
>
> Except for the last one those checks will simply verify
> that the user followed certain policies. They should,
> therefore, rarely reject a commit.
>
> Again, the user shall be free to combine (or not use)
> these policies although not all combinations are meaningful.
>
> Thoughts?
>
> -- Stefan^2.
>
>
> Note 1:
>
> One thing that we might want to support is integration
> branches where a temporary branch is being used as
> an intermediate merge target:
>
> integrate A->B as
> rN: copy B->A_integration
> rN+1: merge A->A_integration
> rN+x: ... various changes on A_integration
> rN+y: merge A_integration->B
> rN+y+1: delete A_integration
>
> These checks become more complicated, requires
> naming conventions for the integration branches etc.
Received on 2012-04-19 16:02:50 CEST