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
Received on 2013-06-25 18:45:51 CEST