You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2002/10/17 00:26:50 UTC

svn -D syntax

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

Re: svn -D syntax

Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Hudson <gh...@MIT.EDU> writes:

> foo*bar or ? will also get left alone if they don't match anything.  csh

Not in ksh and zsh (and presumably any other ksh-like shells, if
there are any other than zsh).

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-10-17 at 12:28, Karl Fogel wrote:
> However, +0 on a bracket- or brace-based solution too.

Three people seemed to support this idea, so I implemented it and
checked it in.  I couldn't figure out how to document it, though; as far
as I can tell, -D was totally undocumented except for the help output,
and now even that is gone.  Maybe one of the nice handbook authors can
document the new -r {date} syntax, since end-user documentation is not
my strong point.

I used braces, but converting to brackets would be a two-line change if
people prefer that.

> (Do any shells require "{" and "}" to be
> escaped?  They seem to work fine for me.  Actually, "[" seems fine too
> when not in the command position, so perhaps it's not a problem...)

We should still recommend that people quote braces.  csh will convert
{foo} to foo.  bash will convert {foo,bar} to the words "foo" and "bar",
although just {foo} is left alone.  A real bourne shell will leave
braces entirely alone.

[foo] gets left alone by sh-based shells if it doesn't match anything. 
foo*bar or ? will also get left alone if they don't match anything.  csh
will barf on such things.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Philip Martin <ph...@codematters.co.uk>.
Karl Fogel <kf...@newton.ch.collab.net> writes:

> Do any shells require "{" and "}" to be escaped?

csh (shudder!) requires these to be escaped.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@mit.edu> writes:
>   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.

A huge +1 on using `-r' for both dates and revisions.  That's a great
idea.

I think just doing "::" as the one-and-only separator would be fine,
and certainly preferable to any sort of bracket that would need shell
escaping.  We could keep ":" as a valid separator for revisions for a
while, for compatibility... But nah, let's not bother.  Better to
break a few scripts now than risk having to break more later.

However, +0 on a bracket- or brace-based solution too.  Anything's
better than the status quo.  (Do any shells require "{" and "}" to be
escaped?  They seem to work fine for me.  Actually, "[" seems fine too
when not in the command position, so perhaps it's not a problem...)

Whatever.  I trust your judgement.  +1 on Greg Hudson implementing
whatever he thinks is appropriate at this point :-).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Gustavo Niemeyer <ni...@conectiva.com>.
>   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.

+1

That's the only option, besides allowing two -r/-D, that allows mixing
revisions and dates. Also, having just one option to specify the same
thing seems nice.

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Branko Čibej <br...@xbc.nu>.
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   <br...@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

Re: svn -D syntax

Posted by Noel Yap <ya...@yahoo.com>.
--- Noel Yap <ya...@yahoo.com> wrote:
> > That's assuming a revision number can never look
> > like a date. But it 
> > can, 1622 can be a revision number, or it can be
> 22
> > minutes past 4 p.m. 
> > So you still need a way to disambiguate between
> date
> > and revisions.
> 
> This is a good point.  In fact, IIRC, strict ISO
> 8601
> says that 2002 can either be a time or a date (I'm
> assuming Subversion will assume it's a date or is an
> invalid date-time).

Oops, it's obviously a time.

Noel

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Noel Yap <ya...@yahoo.com>.
--- Branko Čibej <br...@xbc.nu> wrote:
> Noel Yap wrote:
> 
> >I like this in combination with the above.  For
> >example, "-r '[2002-10-10 16:00:00,23)'".
> >
> That's assuming a revision number can never look
> like a date. But it 
> can, 1622 can be a revision number, or it can be 22
> minutes past 4 p.m. 
> So you still need a way to disambiguate between date
> and revisions.

This is a good point.  In fact, IIRC, strict ISO 8601
says that 2002 can either be a time or a date (I'm
assuming Subversion will assume it's a date or is an
invalid date-time).

I suppose something like the "find" and "test" syntax
would be out of the question?  For example:
  \( -r '[3,5]' -o -D '[2002-10-10,2002-10-11]' \)

or:
  \( -r '[3,5]' -a -D '[2002-10-10,2002-10-11]' \)

> Oh, and while "inclusive" and "exclusive" have an
> obvious meaning for 
> revision numbers, what do they mean for dates?
> Especially if the date 
> isn't specified to the last second?

I think eventually, dates will have to have an
implicit value for the time or else it would be
confusing to use pure dates at all.  For example, does
2002-10-10 mean the beginning of day or the end of
day.  Maybe it means mid-day.  It's got to mean
something consistently (and it can't be consistently
random :-).

Noel

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Branko Čibej <br...@xbc.nu>.
Noel Yap wrote:

>I like this in combination with the above.  For
>example, "-r '[2002-10-10 16:00:00,23)'".
>
That's assuming a revision number can never look like a date. But it 
can, 1622 can be a revision number, or it can be 22 minutes past 4 p.m. 
So you still need a way to disambiguate between date and revisions.

Oh, and while "inclusive" and "exclusive" have an obvious meaning for 
revision numbers, what do they mean for dates? Especially if the date 
isn't specified to the last second?


-- 
Brane Čibej   <br...@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

Re: svn -D syntax

Posted by Noel Yap <ya...@yahoo.com>.
--- Greg Hudson <gh...@MIT.EDU> wrote:
> > What's wrong with ','?
> 
>   November 12, 1973
>   Tuesday, 12 November 1973
> 
> Not that I am wedded to understanding these formats,
> but we understand
> them now.

Blech!  IMO, it would be best not to have human-biased
date-times.  For one reason, you wind up with i18n
issues.  I think these have been dealt with already. 
OTOH, just dealing with them introduces complexity
that may otherwise be lessened.

I know I really have no say in this, but I'd be
ecstatic if this were removed.

> > I like this in combination with the above.  For
> example, "-r
> > '[2002-10-10 16:00:00,23)'".
> 
> Either the brackets denote a date instead of a
> revision, or they
> denote the inclusivity/exclusivity of a range.  They
> can't do double
> duty.

I meant the latter.

It doesn't matter really since, as Branko had pointed
out, 1600 can either be a time or a revision.

Noel

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Greg Hudson <gh...@MIT.EDU>.
>>   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 "::".

> What's wrong with ','?

  November 12, 1973
  Tuesday, 12 November 1973

Not that I am wedded to understanding these formats, but we understand
them now.

>>   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 this in combination with the above.  For example, "-r
> '[2002-10-10 16:00:00,23)'".

Either the brackets denote a date instead of a revision, or they
denote the inclusivity/exclusivity of a range.  They can't do double
duty.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn -D syntax

Posted by Noel Yap <ya...@yahoo.com>.
--- Greg Hudson <gh...@MIT.EDU> wrote:
>   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 "::".

What's wrong with ','?  In fact, I think it may be
possible to support the math notation for ranges (ie
using parentheses for exclusive and brackets for
inclusive; both with escaping or quotes, of course).

I don't have a copy in front of me.  What does ISO
8601 say about range syntax?

>   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 this in combination with the above.  For
example, "-r '[2002-10-10 16:00:00,23)'".

>   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.

Ugly or not, my experience with intuiting is that it's
really bad when the computer intuits something the
human doesn't.

> Which should I implement?

I vote (not that it counts for much :-) for a
combination of 2 and 3.

Noel

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org