On Mon, Feb 26, 2018 at 10:49 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Feb 26, 2018 at 12:43:42AM -0800, Alexey Neyman wrote:
>> On 02/26/2018 12:18 AM, Stefan Sperling wrote:
>> > On Sun, Feb 25, 2018 at 11:38:03PM -0800, Alexey Neyman wrote:
>> > > Hi all,
>> > >
>> > > I am trying to dig for some changes in a file that was moved a few times and
>> > > 'svn diff' shows full "remove old location and add new location as if it
>> > > were a new file" diffs, which are not helpful. Is there a way to make the
>> > > diff show the changes as compared against the origin of the copy? I tried
>> > > --notice-ancestry, does not help.
>> > Diff output changes depending on whether you pass a path to the
>> > file itself or to a parent of the file. Try: svn diff -c 2 barfoo
>> > I found this in the diff_renamed_file() test in diff_tests.py,
>> > see there for more examples.
>> > https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/diff_tests.py
>> You don't expect the end-user to read the test cases in the product to get
>> these subtleties, do you? :)
>
> No, I don't. But subtle details such as this are often not documented.
> In documentation there is always a trade-off between what the system
> is actually doing in detail and what the reader really needs to know.
>
> The test cases are an accurate source of reference when it comes to
> details of expected behaviour like this because they encode what's
> actually intended.
>
>> 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.
>
>> > 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.
>
>> 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:
>>
>> # The relevant fragment of a revision
>> $ svn log -c 36 -v file://`pwd`/XXXXXX-svn
>> A /trunk/XXXXXX/src/bin/more (from /vendor/YYYY:29)
>> M /trunk/XXXXXX/src/bin/more/more.c
>> # Passing the path to the directory that was copied: does not work
>> $ svn di -c 36 file://`pwd`/XXXXXX-svn/trunk/XXXXXX/src/bin/more | grep -A 4
>> 'Index: more.c'
>> Index: more.c
>> ===================================================================
>> --- more.c (nonexistent)
>> +++ more.c (revision 36)
>> @@ -0,0 +1,1894 @@
>> # Passing the path to the specific file: does not work
>> $ svn di -c 36 file://`pwd`/XXXXXX-svn/trunk/XXXXXX/src/bin/more/more.c |
>> grep -A 4 'Index: more.c'
>> Index: more.c
>> ===================================================================
>> --- more.c (nonexistent)
>> +++ more.c (revision 36)
>> @@ -0,0 +1,1894 @@
>> # Manual, file-by-file: works, but doesn't scale to revisions with lots of
>> modifications
>> $ svn di file://`pwd`/los178-svn{/vendor/YYYY/more.c_at_29,/trunk/XXXXX/src/bin/more/more.c_at_36}
>> | grep -A 4 'Index: more.c'
>> Index: more.c
>> ===================================================================
>> --- more.c (.../vendor/BSD/more/4.3Tahoe/more.c) (revision 29)
>> +++ more.c (.../trunk/los178/src/bin/more/more.c) (revision 36)
>> @@ -1,3 +1,11 @@
>
> 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 remembered we had a similar discussion (also on the different
behaviour of 'svn diff' vs. 'svnlook diff') on dev@ some years ago.
It's a long thread with lots of info in it. I don't have time to
refocus / summarize this now, so I'm just dropping this link here from
where I think the thread starts to become interesting:
https://svn.haxx.se/dev/archive-2013-06/0621.shtml
It also refers to an older post where I highlighted the difference
between 'svnlook diff' has --diff-copy-from' and 'svn diff
--show-copies-as-adds' (which sounds like the reverse option, so 'svn
diff' sounds like diff-copy-from would be the default ... but then
apparently that isn't quite true):
https://svn.haxx.se/dev/archive-2012-11/0480.shtml
I agree that there are various inconsistencies in the current
behaviour of diff regarding "ancestry handling" and it is certainly
not ideal. Maybe it's time someone refocused on this to untangle it
all ...
--
Johan
Received on 2018-02-26 11:48:39 CET