Greg Hudson wrote:
>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.
>
This would complicate the option parser. Of course, you'll have to
complicate something anyway...
> 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.
>
I like (3). I wouldn't worry about shell escapes too much, but if
they're a concern, you could go the other way: leav -r for rev numbers
only, but allow rev numbers for -D; your example would become -D
2002-10-10::R23, assuming you already implemented (2).
> 4. Disallow date ranges.
>
Oh, no.
> 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.
>
Oh even no'er. AI is not that hot any more, so boasting that SVN has an
AI engine for parsing dates would just make people keep away from us. :-)
>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).
>
Ah, I know a certain Mr. King. He owes us a debugged date parser. :-)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 17 05:27:12 2002