The svn merge subcommand can create local svn:mergeinfo modifications
in two basic ways:
1) The application of a diff -- If the merge sources have differences
in the svn:mergeinfo property, then they are applied just like any
other versioned property.
2) Describing the merge performed -- A merge tracking aware merge
records mergeinfo describing the merged source(s) and revision(s).
E.g. 'svn merge ^/trunk branch-wc -r500:588' sets the mergeinfo
'/trunk:501-588' on branch-wc*
Changes of the first type result in notifications, as they always
have, even prior to merge tracking.
Changes of the second type produce no notifications. As Philip and I
discussed here,
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2425507,
this includes --record-only merges. In that thread Philip suggested
that --record-only merges should produce notifications for the "type
2" changes, since --record-only merges typically produce no output at
all. I've come around to agree with this position, but I think it
should be expanded to "regular" (non --record-only) merges too.
There has been no shortage of confusion regarding type 2 mergeinfo
changes, especially when it comes to subtrees of the merge target.
The changes in 1.7 limiting the recording of subtree mergeinfo
(http://svn.haxx.se/dev/archive-2009-08/0045.shtml) should alleviate
much of this confusion, but I think producing notifications for type 2
changes in all cases will help more.
Here is an example to demonstrate what I have in mind:
# We have a working copy with no mergeinfo on the
# root, but some subtree mergeinfo from earlier
# subtree merges:
>svn pg svn:mergeinfo -vR
Properties on 'build':
svn:mergeinfo
/trunk/build:35021
Properties on 'subversion':
svn:mergeinfo
/trunk/subversion:35000-35020
Properties on 'subversion\tests':
svn:mergeinfo
/trunk/subversion/tests:35000-35020,35022
# We merge a single revision which affects a
# single file:
>svn log -qv -r35049 ^^/
------------------------------------------------------------------------
r35049 | pburba | 2009-01-06 12:11:11 -0500 (Tue, 06 Jan 2009)
Changed paths:
M /trunk/subversion/tests/cmdline/svntest/main.py
------------------------------------------------------------------------
# Currently all we see is the "type 1" notification
# from the application of the diff:
>svn merge ^^/trunk . -c35049
--- Merging r35049 into 'subversion\tests':
U subversion\tests\cmdline\svntest\main.py
# But status and diff show that the subtrees affected
# by the merge had their mergeinfo updated and the
# merge target itself got mergeinfo added, all of which
# describe the merge that was just done. Note that the
# mergeinfo on 'build' did not change because that
# subtree was not affected by the merge (new in 1.7):
>svn st
M .
M subversion
M subversion\tests
M subversion\tests\cmdline\svntest\main.py
>svn diff . subversion subversion\tests --depth empty
Property changes on: .
___________________________________________________________________
Added: svn:mergeinfo
Merged /trunk:r35049
Property changes on: subversion
___________________________________________________________________
Modified: svn:mergeinfo
Merged /trunk/subversion:r35049
Property changes on: subversion\tests
___________________________________________________________________
Modified: svn:mergeinfo
Merged /trunk/subversion/tests:r35049
# Instead of silence on the type 2 mergeinfo changes,
# what I am proposing is something like this:
>svn merge ^^/trunk . -c35049
--- Merging r35049 into 'subversion\tests':
U subversion\tests\cmdline\svntest\main.py
--- Recording mergeinfo for merge of r35049 into '.':
A .
G subversion
G subversion\tests
Specifically, the special header (for a single rev)
--- Recording mergeinfo for merge of rX into 'path':
or (for multiple revisions)
--- Recording mergeinfo for merge of rM through rN into 'path':
would be printed after all type 1 notifications. Then all the type 2
notifications would be grouped together.
Obviously I'm open to what language to use for the header, but do
folks like the concept? Do we think it would make clearer what is
happening during a merge or does it just add noise?
Thoughts appreciated,
Paul
* Yes, it might add/merge that mergeinfo to existing mergeinfo, there
might be subtree mergeinfo too, it might even be a foreign repos, etc.
Let's just assume this is the simple (obvious) case where branch-wc
is a copy of ^/trunk that has never been merged to and has no explicit
mergeinfo prior to the merge.
Received on 2009-12-09 22:41:06 CET