On Tue, Jun 25, 2013 at 05:59:27PM +0200, Tobias Bading wrote: > Hmm, but why is diff -cM:N working if the file was copied from > revision M? Sure, the target of the copy operation did not exist in > revision N-1 if M < N-1, but it didn't exist in revision M either.
The file did exist at the copyfrom location in revision M, correct? In which case Subversion can detect that the files at their respective paths in revision M and N are related, so it displays a diff between them. The revision N-1 doesn't matter in this case. It is not "operative" on the file, and is ignored. But if you restrict the operative revision range of your diff such that the copy source is not within that range, why would you expect Subversion to still look for changes in that revision, and show a diff against the copy source? I believe that 'svn diff' is giving you the right answer based on parameters you've given it to work with. I realise that I'm not helping you much. I'm just explaining the current intended behaviour. I don't think you've found a bug. The emacs vc-svn.el (sorry I didn't know that "plugin" is not the proper term to use here) would indeed need to pass something more clever than a hardcoded -rN-1:N to yield a useful result in your use case. The location of a file across revision history is not a very simple issue in Subversion, and can sometimes be counterintuitive. If you haven't done so I recommend reading this page for more information about how Subversion resolves paths in history: http://svnbook.red-bean.com/en/1.7/svn.advanced.pegrevs.html
