Re: Erroneous "diff --summarize" output?

On Wed, Aug 8, 2018 at 9:27 AM Chris <devnullaccount_at_yahoo.se> wrote:
>
> I just noticed some strange output from diff --summarize that to me looks like a bug, but I'm not sure.
> What I'm doing is that I'm changing a file in a subdirectory, committing it and then reverse-merging that change so I'm back to the same content of my working copy as before. Running svn diff against the previous revision shows no diffs as expected, but when I do the exact same command but add --summarize, it says the file that I changed is modified and the directory it is in has property changes.
> The attached reproduction script illustrates the difference. Is this a bug or am I misunderstanding how summarize is supposed to work?

Hi Chris,

Thanks for reporting this. I think this is indeed a bug ... somehow
the 'diff --summarize' seems to do something wrong when determining
the working-copy revision (but regular 'diff' does it right). That's
if I'm correctly interpreting the second usage of 'diff'.

From 'svn help diff':
[[[
  2. diff [-c M | -r N[:M]] [TARGET[@REV]...]
  ...
  2. Display the changes made to TARGETs as they are seen in REV between
     two revisions. TARGETs may be all working copy paths or all URLs.
     If TARGETs are working copy paths, N defaults to BASE and M to the
     working copy; if URLs, N must be specified and M defaults to HEAD.
     The '-c M' option is equivalent to '-r N:M' where N = M-1.
     Using '-c -M' does the reverse: '-r M:N' where N = M-1.
]]]

So, "If TARGETs are working copy paths, N defaults to BASE and M to
the working copy".
But, if I'm following your test script, at the end the working copy is
at revision 3. And if not, it certainly is after I execute another
'svn update' at the working copy root.

If I do:
    svn diff -r 1 A
indeed, it shows nothing.

If I do:
    svn diff -r 1 --summarize A
it shows:
    M A\mu
     M A

But if I do:
    svn diff -r 1:3 --summarize A
it shows nothing.

So it seems, with the --summarize option, 'diff' doesn't seem to
determine correctly the "M" revision of the range (should be "3" in
this case, the working revision of the working copy).

This issue seems a bit similar:
    https://issues.apache.org/jira/browse/SVN-4631 (svn --xml
--summarize -rBASE:nnnnn reports incorrect output)

But I'm not sure whether it's the same.

I think you should file a new issue, and attach your reproduction script to it.

-- 
Johan