I've got a patch in progress for solving Issue #1093. I want to
inform folks of the changes I'm making so nothing comes as a surprise,
and to gives you a chance to comment.
As a reminder, the problem I'm out to solve is really straightforward.
Because Subversion has 'copy' and 'move' functionality, and in fact
encourages the use of those concepts to pull off the whole "multiple
lines of development" model, the paths at which a given resource
exists over time can be many.
Today's 'svn diff -r X:Y PATH' is really dumb -- it literally looks
for PATH in revision X and PATH in revision Y, and diffs them. That's
not what people want. For one think, PATH may not exist in one or the
other of those revisions due to some rename that occurred between the
two revisions. Secondly, PATH might exist in both revisions, but not
as the same resource, which renders diff output possibly quite
insane, but definitely wrong.
Of course, a user *could* get the diff they wanted today using the
'svn diff URL@X URL@Y' syntax, but that means they have to do alot of
work (typically involving reading the output of 'svn log -v') to
figure out the two URLs they need to pass to the operation. Ideally,
though (as I think we've all agreed by now), 'svn diff' would just
follow a resource's history back through revision time, finding the
appropriate locations in the repository to diff between.
A while ago I proposed a syntax and set of rules to give users control
better control over this expanded functionaly. Greg Hudson and others
made comments and corrections, some of which I agree with, and some I
don't -- but most of which I just don't remember. :-)
So allow me to just list the steps I plan to take to solve this
problem, or to at least position us to solve it later.
Part 1: A new interface, svn_client_repos_locations(), which accepts
a path (or URL), a "peg" revision, and two revisions in
which we want to know the locations of that path/URL. This
will use RA->get_logs() under the hood -- just like 'svn
blame' does -- to trace path changes in history.
## Finished, but current restricted to PEG >= X and PEG >= Y ##
Part 2: Teach the command-line client to use this function in the
'svn diff -rX:Y' cases.
## Almost Finished ##
Part 3: Teach 'svn merge' to do the right thing, too.
## Not Started ##
At the very least, I'd like to get Change 1 in before 1.0. Changes 2
and 3 would be great, too, but shouldn't (fingers crossed) need API
changes, so I don't care so much about those.
Folks may recall some debate about what do in the 'svn diff [-r X:Y]
PATH-OR-URL[@Z]' situation when Z is < either X or Y. Since we can't
trace history forward in time (and even if we could, there could be
multiple choices of lineage to follow), I wanted to punt outright.
And I got fussed at for that. Well, now I realize that we can at
least assume that PATH-OR-URL hasn't been renamed between Z and the
greater of X and Y. And we can reliable determine if our guess was a
safe one by verifying that the path of the resource in Z is the same
as the resource's path in the greater of the X and Y.
So let's talk about syntax changes. On Oct. 29, 2003, Greg Hudson
proposed the following:
1. diff [-r M[:N]] [TARGET...]
Each target may be a path or URL, but it is invalid to specify a
URL with no -r option. Perform a pegged diff for each
target. For paths, the default starting rev is BASE, the default
ending rev is WC, and the peg rev is always WC. For URLs, there
is no default starting rev (-r option must be present), the
default ending rev is HEAD, and the peg rev is always HEAD.
2. diff --old=OLD-TGT[@OLDREV] --new=NEW-TGT[@NEWREV] [PATH...]
Compare OLD-TGT and NEW-TGT, restricted to the paths PATH... if
given. Can be used to answers questions like "what changes were
made to libsvn_ra_dav between the 0.32 branch and the trunk?"
(Limitation: if libsvn_ra_dav was renamed between the 0.32
branch and the trunk, the user will have to go find out how; we
can't answer complex questions like "what was the name of
/trunk/subversion/libsvn_ra_dav under /branches/0.32?".)
3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
Syntactic sugar for 'diff --old=OLD-URL@OLDREV --new=NEW-URL@NEWREV'.
Easily distinguishable from the first usage because you can't
use URLs without a -r option. Note "svn diff URL@R1
URL@R2" is rather different from "svn diff -rR1:R2 URL",
because the latter performs a pegged diff of URL@HEAD between
R1 and R2, while the former looks up URL's pathname
independently in R1 and R2 and diffs the results.
None of these forms mix the -rX:Y and the @-syntax because Greg deems
that stuff esoteric. For now, I'm willing to lay down and concede
that. In my mind, though, the best benefit of that fact is that the
command-line parsing code doesn't have a change a lick in order to
handle these use cases (though, I think there is one de-unification
I'd like to see, not directly related to this topic).
Wow. (Breathe).
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 10 22:10:53 2003