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_at_1 ^/barfoo_at_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.
Received on 2018-02-27 01:52:58 CET