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
(http://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=337499).
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
subcommand.
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
notifications?
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,
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2401341
Received on 2009-09-28 20:16:55 CEST