For background, read CMike's proposal at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=48573 if
you haven't already.
I have a few Deep Thoughts, which I'll present in increasing order of
complexity. Essentially, I want to adopt CMike's proposal, but with
some simplification (point 1), a slight modification (point 2), and with
a better description relative to the current syntax (point 5).
1. Being able to do "svn diff -rX:Y foo@Z" seems really esoteric. It's
a tough concept for users to understand, and I can't imagine it getting
any use from the command line. So I don't think it's a good idea to
support that. When the question of peg revisions comes into play, we
should always peg paths to the WC, and should always peg URLs to the
HEAD.
(On the other hand, a GUI client may have a much more intuitive way of
identifying nodes. So svn_client_diff() may want to support pegging
targets to any revision, even if the command-line client can't.)
2. BASE is the wrong peg revision for a wc path. Consider "svn rm bar;
svn cp foo bar; svn diff bar".
3. In your proposal, the command "svn diff -r 10:20 URL" could have
surprising results if URL@HEAD is a different object from both URL@10 or
URL@20. Or it could have unsurprising results, depending on why the
user is issuing that command (say, if they just read the output of "svn
log URL"). So I think it's probably reasonable.
4. As discussed on IRC, going forward in time within a node is a little
tricky. Making it work in all the unambiguous cases is probably too
hard, especially without true rename tracking (but it's still hard even
with it, because of lazy directory copies). In the meantime, we should
at least make it work in the case where the node exists with the same
name in the future rev. (This is essentially what CMike just said in
his 29 Oct 2003 14:02:22 -0600 message.)
5. The current abstract model for diffs is broken, because it assumes
that all diff commands can be described as an iteration of paths within
a single comparison. However, in the presence of copies, that model
gets some embarassingly simple cases wrong:
svn cp ../baz foo
svn diff foo bar
There is no single comparison which contains the proper diffs when
restricted to the pathnames "foo" and "bar"; for foo, we want to compare
../baz@BASE with ./foo@WC, and for bar, we want to compare ./bar@BASE
with ./bar@WC. To fix this problem, I think we have to de-unify the
diff syntax. Fortunately, I think we can do so without re-introducing
the two-argument ambiguity of the past. Here is my proposal:
-----
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.
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?".)
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.
-----
>From a libsvn_client perspective, I think we want two separate functions
for the two separate behaviors; if we try to do them both with the same
function, we'll be embedding too much command-line user interface logic
into the client library.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 29 22:36:49 2003