On 26.06.2013 00:07, Ben Reser wrote: > On Tue, Jun 25, 2013 at 11:54 PM, Johan Corveleyn <jcor...@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. br...@wandisco.com
