[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Tobias Bading <tbading_at_web.de>
Date: Tue, 25 Jun 2013 19:48:24 +0200

On 25.06.2013, at 18:45, Stefan Sperling wrote:
> 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.

I wouldn't call it a bug either, but even less a feature ;-). I'm simply expecting -cN to mean "the changes made in revision N", not the changes between revisions N-1 and N. In most cases there's no difference in both interpretations, but with copies that warp time (so to speak) by copying from source_at_M to target_at_N with M < N-1, 'diff -cN target' is as useful as 'cat </dev/null' :-(.

> 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.

*slowly waves his hand in front of Stefan*
"This is not the editor you're looking for... move along." :-D

Seriously though, what would you have to do if you have the path of a FILE in the working copy and a revision number N and you would like to know what was changed in that file in that revision?
Something like 'svn log --limit 2 -rN:0 FILE' and if that returns two revision, take the second one (let's call it M) and do a 'svn diff -rM:N FILE'?
Where's my Bei▀holz when I need it?!? :-D

> 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

Thanks for the tip. I read it a few years ago, maybe I should read it again :-).

Received on 2013-06-25 19:49:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.