Philip Martin <philip@codematters.co.uk> writes:
> What about dates? I don't use dates on the command line very often,
> but I do use them occasionally. I can't imagine using a date for a
> merge command, but I can imagine wanting to use it for a diff
> command. Will
>
> $ svn diff -RDATE1:path1 -RDATE2:path2
>
> be expected to work?
You know, that's a good point... I think there's a nice simplification
we can make here, though.
Q: Do we even need separate -r/-R versus -D options, considering that
a date always translates to a revision, as far as Subversion is
concerned?
A: I don't think so. We can just use -r or -R for revisions and
dates, and use the syntax of the argument to tell us which it is.
This would imply:
1. Dates must contain some non-numeric character. A date of
20020128 is both a valid date and a valid revision number, so
we'll interpret it as a revision, and insist on 2002-01-28 or
something similar for dates. Good error reporting should make
this easy for users to figure out.
2. Both -r and -R shouldn't use colons to separate range delimiters
anymore, because dates can contain colons. Instead, we just
pass the flag twice. I believe apr_getopt() preserves the order
of options, and allows duplicate options, precisely for
situations like this.
So these three commands would all have the same effect:
$ svn diff -r 13 -r 14 foo.c bar.c baz.c
$ svn diff -r 13 foo.c -r 14 bar.c baz.c
$ svn diff -r 13 foo.c bar.c -r 14 baz.c
$ svn diff foo.c bar.c baz.c -r 13 -r 14 baz.c
...show the difference between revisions 13 and 14. Of course, a sane
user will only invoke it the first way!
Whereas these commands would have another (also consistent) effect:
$ svn diff -R 13 foo.c -R 14 bar.c
$ svn diff -R 13 -R 14 foo.c bar.c
$ svn diff foo.c bar.c -R 13 -R 14
that of showing the difference between foo.c-at-rev-13 and
bar.c-at-rev-14. Of course, again, sane users will choose the first
invocation syntax.
You can substitute a date for 13 or 14 in these examples, and a URL
for any of the filenames, and it all still means the same thing.
Abstract summary: -r means apply the given revision/date range to all
the targets. -R means apply revisions/dates to corresponding
targets. When only one -r or -R is used, Subversion chooses some
"reasonable" default for the missing value, possibly based on working
copy context.
Hmmm. It's not all that intuitive -- I think a lot of users will
still be confused. But I'm guessing that's because the semantic
choices here are inherently complex, not because we're choosing an
overly complex way to express a simple idea. Even if we went with the
separate command idea, the problems would be the same. Is there a
better way to express this stuff in invocation syntax?
I'm not bottlenecked on this yet; I will be able to continue coding
for a while without knowing what syntax is going to invoke the new
code paths. But soon we'll have to decide.
Thoughts?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006