> -----Original Message-----
> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: woensdag 26 juni 2013 23:53
> To: Johan Corveleyn; Ben Reser; Tobias Bading; Peter Samuelson; Subversion
> Development
> Subject: Re: 1.6 vs. 1.8: strange behavior of 'svn diff -cN WC-FILE' if
the file
> was created in rev N by copying
>
> On Wed, Jun 26, 2013 at 3:01 PM, Stefan Sperling <s...@elego.de> wrote:
> > On Wed, Jun 26, 2013 at 01:39:59PM +0200, Johan Corveleyn wrote:
> >> As Tobias pointed out, 'svn diff' does indeed do the diff against the
> >> copy source, but *only if you're lucky*. I would consider this erratic
> >> behavior definitely a bug, because it makes the output unpredictable,
> >> and thus unusable in general.
> >
> > OK, you've both convinced me now. I agree that diff -c could trace
> > copyfrom even if the copfrom rev is outside the operative revision
> > range, and display an 'added' file only with --show-copies-as-adds.
> >
> > Now, the problem is that the repos->repos diff case doesn't support
> > --show-copies-as-adds yet (see do_diff() in libsvn_client/diff.c).
> > So it's not a trivial fix and might require some work to get done.
>
> Perhaps we should regard that as a separate problem. Isn't the fact
> that --show-copies-as-adds doesn't work for repos->repos diff,
> orthogonal to fixing the default behavior (non-show-copies-as-adds)
> regarding moved files?
>
> Or do you feel that the change in behavior ("fix") of diff -c is
> dependent on a good working --show-copies-as-adds?
We can't just redefine the behavior of '-c'
The 'svn' commandline client explicitly implements '-c' as '-r N-1:N' (or -r
N:N-1 when passing -c -N)
This behavior is tied to more commands than diff and the internal APIs just
see the revision numbers.
Besides
$ svn diff -c 12 FILE
has many use cases
what would you expect after:
$ svn rm FILE
$ svn cp OTHER-FILE@6 FILE
$ svn ci -m "r12"
(copy file with some history)
or after:
$ svn rm FILE
echo "QQQ" > FILE
$ svn add FILE
$ svn ci -m "r12"
(add new file)
$ echo new line >> FILE
$ svn ci -m "r12"
(text change)
[There are even more variants possible if you replace an ancestor instead of
just the node itself]
We can't handle all these use cases with a simple -r N-1:N. We really need
more flags to capture all these cases.
'svn diff' is already implemented as layer over layer over layer of use
cases.
E.g. by default diff doesn't describe the ancestry of nodes: A file replaced
by a file or a directory by a directory is described as a simple content
change unless you pass --notice-ancestry (or --git). Which is nice if you
want to use 'svn diff' as input for GNU patch, but not if you want it to
describe the local changes.
Another interesting case is that our merge is also build on top of diff, so
users would expect that
svn diff ^/trunk -c 1234
Would be the same as what you merge with
svn merge ^/trunk -c 1234
(And then of course there is that problem of backwards compatibility)
If you really want to make your head explode we can also bring in the
problems around the definition or -r BASE in the context of diff or other
commands.
-r BASE is mostly used to describe the PRISTINE version of a node, but in
some cases also as the clean checked out version... Which can be different
in the case of a direct and/or ancestor replacement.
Redefining any of this requires taking into account all these other ugly
corner cases... and our backwards compatibility guarantees...
(Small steps forward...)
Bert
