Karl Fogel wrote:
> Karl Fogel <kfogel_at_red-bean.com> writes:
>> At http://pastebin.ca/931468, you can see some merge behavior that
>> surprised me. I merged one revision from trunk to branch, affecting
>> two files. But afterwards, my formerly pristine branch working copy
>> showed *10* files changed: two of them were the ones I expected, and
>> the others had property changes to -- you guessed it -- svn:mergeinfo.
>> Am I merely revisiting an old discussion here? Has this been hashed
>> out already? Was it already proposed that 'svn status' and 'svn diff'
>> not show changes to svn:mergeinfo by default (and take a -g flag to
>> mean "do count svn:mergeinfo property changes")?
> epg expressed interest in seeing the diff output too, so here it is:
This appears to be repeatable.
$ cd projects/subversion-1.5.x
$ svn up -q -r 29765 ## rev just prior to karl's commit
$ svn merge -c 29188 http://svn.collab.net/repos/svn/trunk .
--- Merging r29188 into '.':
Conflict discovered in 'subversion/svn/conflict-callbacks.c'.
Select: (p) postpone, (df) diff-full, (e) edit,
(h) help for more options: e
Waiting for Emacs...Done
Select: (p) postpone, (df) diff-full, (e) edit, (r) resolved,
(h) help for more options: r
$ svn st
But on closer inspection, it's not quite the same:
$ svn diff -N
Property changes on: .
Property changes on: CHANGES
Those mergeinfo props do at least actually refer to the revision I merged
instead of ... something else.
NOTE: I'm using a trunk build from sometime yesterday.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-03-07 15:27:00 CET