On 27.06.2013 09:38, Bert Huijben wrote:
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)
Granted, this is a toughy.
My 0.02 cents (after a first glance, I hereby reserve the right to
totally reverse my opinion later on in this thread ;-):
I'd expect 'diff -r11:12 (aka -c12) FILE' to show... umm... err...
Mom!!!! I don't want to play with Bert anymore, he's a party pooper! ;-)
Seriously, 'diff -c12 FILE' (without --notice-ancestry) should probably
ignore the fact that an other FILE@11 existed and show the differences
between OTHER-FILE@6 and FILE@12, that is work just like 'diff -r6:12
FILE' in this case.
'diff --notice-ancestry -c12 FILE' or 'diff -c12 DIR' (with DIR being
the directory containing FILE) should show the replacement, that is
FILE@12 as a new file.
Merge should probably work the other way around as usual, i.e. 'merge
-c12 FILE-IN-REPO' should replace an existing FILE and 'merge
--ignore-ancestry -c12 FILE-IN-REPO' should merge the changes between
OTHER-FILE@6 and FILE@12 into the local FILE.
or after:
$ svn rm FILE
$ echo "QQQ"> FILE
$ svn add FILE
$ svn ci -m "r12"
(add new file)
See above I'd say. Just a bit simpler here, because of the missing hole
in the time-space continuum created by copying OTHER-FILE@6 to FILE@12.
$ echo new line>> FILE
$ svn ci -m "r12"
(text change)
I don't get this one. Just a simple line added in r12?
[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
I agree, you should be able to foresee the result of a merge after
taking a look at the diff. Proper use of --ignore-ancestry or
--notice-ancestry provided of course.
(And then of course there is that problem of backwards compatibility)
The reason for me to start this thread was the very specific problem of
the 'hole in the time-space continuum' that every copy of from-file@M to
to-file@N with M < N-1 creates. If you're looking at an annotated
version of to-file and found an interesting line, whose revision number
is -- ta-da! -- N, 'svn diff -rN-1:N to-file' fails in Subversion 1.6.23
and simply prints to-file@N as a new file in Subversion 1.8.0. This is a
very specific case, but a common use case IMHO.
I don't know if the changed behavior in this case in 1.8.0 was on
purpose, or if it's just an unintended side effect of some code change.
At the moment, neither Subversion 1.6.23 nor 1.8.0 are able to deal with
this case properly, so you shouldn't break anything if it was possible
to change the behavior for just this specific case, right?
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.
*BOOM!*
Redefining any of this requires taking into account all these other ugly
corner cases... and our backwards compatibility guarantees...
(Small steps forward...)
Precision surgery, if possible? ;-)
Tobias
