subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefanfuhrm...@alice-dsl.de>
Subject Merge policies
Date Thu, 19 Apr 2012 10:48:44 GMT
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. This should give us enough time to improve
the merge logic inside the SVN libs.

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.

Mime
View raw message