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.
