On Tue, Jun 25, 2013 at 04:24:36PM +0200, Tobias Bading wrote: > Dear Devs, > > GNU Emacs 24.3 was behaving a little odd today while trying to > display a svn diff from Annotate mode. It simply barked "svn: Unable > to find repository location for '...' in revision ..." at me :-(. > Since this wasn't the first time Emacs left me in the rain like > this, I thought it was time to take a closer look. > > This much I was able to figure out: > > If you copy a file from revision N-1, modify the copy and then > commit it as revision N, 'svn diff -cN FILE' works as expected > afterwards. It works no matter whether you use Subversion 1.6 or > 1.8, no matter whether you specify FILE as a working copy path or a > repository URL. "Works as expected" meaning that it shows the > modifications you made, not the entire file as an add. > > However, if you copy a file from a revision M that is smaller than > N-1, modify the copy and then commit it as revision N, 'svn diff -cN > FILE' won't play along. Subversion 1.6 simply barks "svn: Unable to > find repository location for 'FILE' in revision N-1", whereas > Subversion 1.8 shows the whole file as an add, i.e. does a diff > -r0:N :-(. An 'svn diff -rM:N FILE' on the other hand works fine.
There is a related issue that was fixed in 1.7.2: http://subversion.tigris.org/issues/show_bug.cgi?id=2873 > Emacs executes 'svn --non-interactive diff -r N-1:N FILE' for > revision N at the current line when you press d in Annotate mode, > which of course barfs just as much as 'diff -cN' does in the > described case with M < N-1. > > Would it be possible to spice up the semantics of -cN a bit? The meaning of -c is and always has been '-r N-1:N'. I don't think we'd want to change this, even if only for compatibility purposes. > I don't know enough about the innards of Subversion to understand > why -rM:N works but -rN-1:N doesn't, but I think trying to figure > out the correct value of M for the current line in Emacs' Annotate > mode might get painfull. I cannot comment on the emacs plugin you're using. Note that however if the file does not exist at revision N-1 and does exist at rN, and you're asking 'svn diff' to show how this file differs between revision N-1 and N, you'll always see a full copy of the file. I don't see anything wrong with that. I would say the emacs plugin needs to be made smarter about the revision ranges it is diffing when showing changes. Perhaps try to contact the plugin's maintainer for help.
