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
--properly-diff-related-nodes'.
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:
---8<---
#!/bin/bash
r=`pwd`/foo-svn
url=file://$r
wc=`pwd`/foo-wc
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"
fi
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
---8<---
And here is the output from the script:
---8<---
$ ./test.sh
...
Index: foo
===================================================================
--- foo (.../foo) (revision 1)
+++ foo (.../bar) (revision 2)
@@ -1 +1,2 @@
Initial content
+Added line
$ INSERT_EXTRA_REVISION=yes ./test.sh
...
Index: bar
===================================================================
--- bar (nonexistent)
+++ bar (revision 3)
@@ -0,0 +1,2 @@
+Initial content
+Added line
---8<---
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?
Regards,
Alexey.
