[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] -r { DATE } with words

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 22 May 2011 11:38:02 +0200

On Sun, May 22, 2011 at 04:51:10AM +0200, Neels J Hofmeyr wrote:
> On 05/21/2011 02:02 PM, Stefan Sperling wrote:
> >But I'd rather use "in 3 months" or something like that than +3m.
> wait, now you're also reaching to the future :)
> No I was thinking, if I want to have a range, then I could pinpoint
> the start with a revision, date, whatever, and the end of the range
> could be given by -r {+3d} (three days from that point on, and
> similar).

To do that you'll have to reorganise the code that calls svn_parse_date()
and bump the API.

> >It's simply less cryptic.
> ...to the English speaking, yes. Next, people will want to have
> German, French, Zulu words as well...
> What I like about my format idea is that it is considerably less
> language dependent (can be documented in any language without
> imposing English spelling on the user) and has considerably less
> characters to type. It also avoids the whole discussion around "day"
> vs. "days" or whether "yestrday" should also be understood, etc.

I agree with the above points. I just don't think they are a good
replacement for the existing english expressions.

> Remember our hackathon discussions -- even to a native English
> speaker, -r {yesterday} isn't self-documenting at all. "Yesterday"
> is a fuzzy concept... IMHO {-1d} is more clearly == -24h. ......
That's why we removed "yesterday" before commit.

> >But since we support a lot of "absolute" time formats there's no
> >reason why we couldn't have more than one "relative" format.
> >This is probably the best answer to the problem of different people
> >having different taste :)
> sure, let's have libsvn_dateparsing.
> Oh well, I thought you might have liked my proposal :)

Received on 2011-05-22 11:38:48 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.