Re: 1.6 vs. 1.8: strange behavior of 'svn diff -cN WC-FILE' if the file was created in rev N by copying

On 26.06.2013 00:07, Ben Reser wrote:
> On Tue, Jun 25, 2013 at 11:54 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> In that post I thought that --show-copies-as-adds (svn) was the
>> reverse from --diff-copy-from (svnlook), but I observed that it didn't
>> really work:
>>
>> "However, I just
>> quickly tested an 'svn diff -c XXX' of some revision which has a move,
>> and it always shows the moved file in full as a delete and an add, no
>> matter if I use --show-copies-as-adds or not. So it seems that
>> detecting copies with their sources is broken in 'svn diff'. "
>>
>> Funny to read that back now :-).
> I even vaguely remember that thread. It is indeed funny how things
> come back around.

I would not be averse to seeing diff show actual differences between
current and last-changed revision in the -cN or -rN-1:N case, with or
without --git. Both parameters mean, "what changed in revision N".

The point where this breaks is when you want to create a diff that can
be applied by plain-vanilla patch and will remove one file and add
another one. That case requires different output, and maybe
--show-copies-as-adds is the right option to use in that case (but I'd
prefer to call it "--patch" or something more semantically close to the
intended result).

Note that IIRC patch will parse the index header, so that you can have:

Index b
=================
a (then)
b (now)

and show just the differences between the old and new locations of the
renamed file, and afterwards issue a "delete" diff for 'a'; but that's
just an optimization (and not all versions of patch may actually get
that right).

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com