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

[RFC/PATCH] Allow merge to apply only svn:mergeinfo diffs

From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 28 Sep 2009 14:16:40 -0400

Currently --record-only merges record only the explicit source of the
requested merge in mergeinfo. E.g., if we do the following:

  svn merge ^^/trunk branches/featureX -c5432 --record-only

Then the mergeinfo '/trunk:6532' is added the existing mergeinfo (if
any) on 'branches/featureX'. No actual diff is performed.

This is simple to understand, compared to a "real" merge is usually
quite fast, and for projects like our own it is sufficient given the
way we use branches (we typically merge from trunk to a branch and
possibly back, but not among branches copied directly from the same
source). For some users this is not sufficient
 If merging among branches, the fact that --record-only does not
actually perform a diff means that any mergeinfo changes that are part
of the requested merge are ignored.

A simple example of what I mean can be seen in our own repository. In
a working copy for the 1.6.x branch do a --record-only merge of r38693
from trunk:

  C:\SVN\src-branch-1.6.x.wcng>svn log ^^/trunk -r38693
  r38693 | pburba | 2009-08-12 01:16:48 -0400 (Wed, 12 Aug 2009) | 2 lines

  Reintegrate the subtree-mergeinfo branch back to trunk.


  C:\SVN\src-branch-1.6.x.wcng>svn merge ^^/trunk . -c38693 --record-only

  C:\SVN\src-branch-1.6.x.wcng>svn st
   M .

The --record-only merge does exactly what we ask, adding only
mergeinfo for /trunk:38693.

  C:\SVN\src-branch-1.6.x.wcng>svn diff

  Property changes on: .
  Modified: svn:mergeinfo
     Merged /trunk:r38693

But there is a lot more to r38693, namely all the work done on the
feature branch:

  C:\SVN\src-branch-1.6.x.wcng>svn diff --depth empty -r38692:38963 ^^/trunk

  Property changes on: .
  Modified: svn:mergeinfo
     Merged /branches/subtree-mergeinfo:r36660-38692

So despite effectively having marked these changes as merged to the
1.6.x branch, if we attempt to merge a revision from the
'subtree-mergeinfo' branch, the mergeinfo on 1.6.x makes it look like
the changes on that branch are eligible, and a merge is attempted:

  C:\SVN\src-branch-1.6.x.wcng>svn merge
^^/branches/subtree-mergeinfo_at_38693 . -c36781
  --- Merging r36781 into '.':
  U subversion\libsvn_client\merge.c

This rather defeats one of the basic use cases of --record-only, i.e.
using it to block a changeset from being merged.

Again, with our repository, this example is rather pointless, we don't
have reason to merge from a pruned feature branch to a release branch.
 But in environments where almost all work is done on feature
branches, which themselves may be branched and merges done among the
branches, then this limitation of --record-only is more of a problem.

The attached patch attempts to solve this by allowing a limited editor
drive that permits only svn:mergeinfo property changes through. It
implements this via the new '--mergeinfo-diff' switch to the svn merge

In the above example this would record mergeinfo as the --record-only
merge does, but also allow the mergeinfo diff in r38693 to be applied,
resulting in more complete mergeinfo:

  C:\SVN\src-branch-1.6.x.wcng>svn st

  C:\SVN\src-branch-1.6.x.wcng>svn merge ^^/trunk . -c 38693 --mergeinfo-diff
  --- Merging r38693 into '.':
   G .

  C:\SVN\src-branch-1.6.x.wcng>svn diff

  Property changes on: .
  Modified: svn:mergeinfo
     Merged /trunk:r38693
     Merged /branches/subtree-mergeinfo:r36660-38692

This change allows only mergeinfo changes to existing paths in the
target. If the requested merge adds a path with explicit mergeinfo
this diff is not applied. If a path with explicit mergeinfo would be
deleted by the merge this is not done either.


A few questions:

1) Any problem with implementing something like this?

2) If the general idea is ok:

2a) Should any notifications be shown? The existing patch shows
notifications for paths with mergeinfo changes, but I'm not sure how
useful these are. Perhaps, like --record-only, there should be no

2b) Should this be a new option to svn merge as in the patch? Or
should it be the default behavior of --record-only? If the latter
then we need to consider that this will slow --record-only merges down
compared with today's simple-no-editor-drive approach. Though I don't
think the performance hit will be too severe, since a lot of the
performance problems related to merge (Issue #3443, implicit mergeinfo
lookups (r36509), etc.) are fixed on trunk or don't apply here (e.g.
multiple editor drives during a singe merge). Or maybe there is some
other solution, --record-only = ARG, where ARG is two choices, one
representing the old simple way, one the new restricted editor drive.

Any thoughts are appreciated, thanks,



Received on 2009-09-28 20:16:55 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.