Issue 893 is a two-part issue; despite having implemented ra_dav
dates, I can't close it until I deal with an awful bikeshed problem.
Right now, you can't really pass a date and time to the -D option.
You can pass a date, and you can shoehorn in a time (without seconds)
using constructs like "1600" or "4pm", but you can't use any of the
common time formats because they all use colons, and, from
libsvn_subr/opt.c:svn_opt_parse_date():
/* ### todo: some standard date formats contain colons.
Eventually, we should probably allow those, and use some
other syntax for expressing ranges. But for now, I'm just
going to bail if see a non-separator colon, to get this up
and running. -kff */
Here are the options I can see:
1. Allow repeated -r/-D options; that is, "-r r1 -r r2" instead of
"-r r1:r2". (As a variation, we could also desupport -r r1:r2,
so as not to gratuitously have two ways of doing the same thing.)
This allows mixing of -r and -D as well as solving the
colons-in-dates problem.
2. Pick a different separator for ranges, which isn't used in dates.
Looking at the punctuation symbols on my keyboard, there isn't a
good choice other than maybe "--" or "::".
3. Nuke the -D option, and consider dates to be a special syntax of
revision names; perhaps they would need to be enclosed in
brackets. So we'd have "-r '[2002-10-10]:23'" for the range {rev
as of 2002-10-10} to {rev 23}. Of course, then all dates have to
be shell-quoted, since shells are rather proprietary about the
various kinds of brackets.
4. Disallow date ranges.
5. Try to intuit whether a colon is a date-range separator or part
of a date. '2002-10-10 16:23:12:2002-10-11 12:10:06' is pretty
ugly, though.
Which should I implement?
Incidentally, getdate.y sucks. I still think we should never have
used it, and that we should get rid of it before 1.0 so that we aren't
bound to it forever. But that wouldn't solve this problem (although
it would make option 5 more feasible, since strings like "6" would no
longer be valid dates).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 17 02:27:33 2002