On Thu, Apr 19, 2012 at 6:48 AM, Stefan Fuhrmann <stefanfuhrm...@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.
