On 25.06.2013, at 23:23, Ben Reser wrote:
> On Tue, Jun 25, 2013 at 11:17 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> Not by default perhaps, but we could do it by adding the same option
>> to 'svn diff' that you need for 'svnlook diff' for this to work:
>>
>> C:\>svnlook help diff
>> ...
>> --diff-copy-from : print differences against the copy source
>
> Why the heck not, if our commands aren't even consistent between
> svnlook and svn then we have a bug somewhere. We should fix the bug
> not add another option to change the behavior.
>
> Sure it might cause problems for some people, so we probably shouldn't
> change the behavior till 1.9, when we can point it out to people in
> release notes and it's part of their major upgrade.
+0.01 for the "We should fix the bug not add another option to change the behavior."
After all I've learned so far, my summary is this:
The output of 'svn diff -cN FILE' is unpredictable, if you know that FILE was the target of a copy or move operation in revision N, but know nothing about the source of that copy or move.
Use case example:
1. 'svn cp http://.../FILE .', where the URL refers to a file in a repository and the current working directory is a working copy of that repository.
2. Modify FILE.
3. Go to lunch.
4. Commit FILE, thus creating revision N.
5. 'svn diff -cN FILE'
Result:
The output of step 5 depends on the eating habits of your co-workers.
There are at least three possible outcomes of step 5:
a) If all your co-workers went to lunch as well, i.e. nobody committed anything to the repository between steps 1 and 4, step 5 will show what you did in step 2. This works fine with Subversion 1.6.23 and 1.8.0, and it's the behavior I'd say is what most users would expect. Well, at least I do :-).
b) If at least one of your co-workers doesn't like the cantina, i.e. comits at least one revision to the repository between steps 1 and 4, the result of step 5 depends on your Subversion version. Subversion 1.6.23 barks "svn: Unable to find repository location for 'FILE' in revision N-1". Subversion 1.8.0 prints the entire contents of FILE.
I'd say 'svn diff -cN FILE' is useless in this (maybe edge) case. Even if you're using 1.8.0 and prefer to see the whole file printed, you can't count on this to work, because the output depends on whether the source of the copy or move was some file from revision N-1 or from a revision older than N-1.
So, what would happen if you'd change the output of 'svn diff -cN FILE' in this case, so that it always shows the delta to the copy/move source? Would that really break anything? If --show-copies-as-adds and --patch-compatible work as advertised, thus presenting proper options for people who want/need to see copies as new files, maybe this change wouldn't hurt anyone?
Tobias
Received on 2013-06-26 07:01:37 CEST