subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Neyman <>
Subject Re: Show textual diff in a moved/copied file - how?
Date Tue, 27 Feb 2018 00:52:41 GMT
On 02/26/2018 01:49 AM, Stefan Sperling wrote:
>> And, I find it quite counter-intuitive. I would expect --notice-ancestry at
>> least to take ancestral relationship between these files into account;
> (I don't have time to look at the code right now, so I'm speculating a bit.)
> You're diffing *directories*, not files. There are separate client-side
> handlers for directory and file diffs which might not always have the same
> information available. E.g. it may not be feasible to trace the back the
> copy history of every child when diffing two directories.
I am not that familiar to say why 'svn diff' behaves in the way it does, 
but it does look like it's contradicting the description in 'svn help diff':

   --notice-ancestry        : diff unrelated nodes as delete and add

Since 'svn diff' does not take the opposite option, '--ignore-ancestry', 
I'd say one would assume that 'svn diff' should diff *related* nodes 
textually, not *as delete and add*. Tracing each child may take some 
additional time, right, but between "fast and wrong" and "slow and 
correct" behaviors, I'd choose the latter :)
>>> Since you know all paths and revisions involved, you could also run:
>>>     svn diff ^/foobar@1 ^/barfoo@2
>> Well, either of these approaches is not very convenient when there is a
>> dozen moves & modifications in a single revision.
> Agreed. At least the file diffs allows you to 'zoom in', but it would
> be much better if there was a way to get the diff you want to see
> with just one command.
If backwards compatibility of 'svn diff' behavior, or the performance 
impact of tracing every child, is a concern - is it possible to have 
'svn diff' do such history tracing if enabled by some new option?

Although, I cannot come up with a better name than 'svn diff 
>> Besides, the former (just passing the path) does not seem to work in all
>> cases. In the real repository, I have two revisions that did the same thing:
>> moved a directory and modified some files in the moved directory. The trick
>> with passing the path to the file works for one of them, but not for the
>> other - and I am at a loss why SVN treats these two differently. Here's
>> where diff does not display the proper diff even when supplied with the path
>> to the file:
[... snip ...]
> I can't explain this one. It might be worth filing an issue about
> this problem in case you can come up with a standalone recipe to
> reproduce it.
I found what triggers this behavior. This happens when the source of the 
copy is not the revision immediately preceding the revision being diffed.

Here's the script for reproduction:


rm -rf $r $wc
svnadmin create $r
svn co $url $wc
cd $wc
echo "Initial content" > foo
svn add foo
svn ci -m "Initial import"

# Source revision to be used in copy later
srev=`svnlook youngest $r`

if [ "$INSERT_EXTRA_REVISION" = "yes" ]; then
     svn mkdir somedir
     svn ci -m "Extra revision"

svn cp $url/foo@$srev bar
echo "Added line" >> bar
svn ci -m "Copy + modify"

cmrev=`svnlook youngest $r`
svn diff -c $cmrev $url/bar@$cmrev

And here is the output from the script:

$ ./
Index: foo
--- foo    (.../foo)    (revision 1)
+++ foo    (.../bar)    (revision 2)
@@ -1 +1,2 @@
  Initial content
+Added line
Index: bar
--- bar    (nonexistent)
+++ bar    (revision 3)
@@ -0,0 +1,2 @@
+Initial content
+Added line

Why is the behavior different in these cases? Isn't that 
counter-intuitive as well that the diff's output depends on the source 
revision of the copy?


View raw message