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

Re: Date processing should be more flexible

From: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-07-04 11:52:26 CEST

Scott Palmer wrote:
>
> On Jul 2, 2005, at 10:24 AM, Alex Barba wrote:
>
>> CVS has a very flexible date parser. I'd like svn to get some of that
>> flexibility as well.
>> For example, the following works ok:
>>
>> svn update -r "{2005-07-05}" make/Common_Makefile
>> At revision 39.
>> However, the following does not:
>>
>> svn update -r "{2005-7-5}" make/Common_Makefile
>> svn: Syntax error in revision argument '{2005-7-5}'
>
>
> +1 for handling a date where the leading zeros are omitted.

+1

>> Other formats work equally poorly:
>>
>> svn update -r "{07/03/05}" make/Common_Makefile
>> svn: Syntax error in revision argument '{07/03/05}'
>
>
> Huge -1 for handling any format other than the ISO standard. Having
> dates written in different ways that are numerically illogical is just
> inviting problems.

Yes, -1! Better stick with ISO YYYY-MM-DD and avoid format with slashes
(that could be misinterpreted by americans) or with dots (that could be
misinterpreted by germans ;P)

> Some relative forms might be nice though.. e.g. {-14d} to get the change
> from two weeks ago.

That would be nice, but what is "now"? The actual date or the date of
the last commit? If it is the actual date, what if you to this 1s before
midnight and the server gives you the data of one day later than you
want? Relative dates and time are very convenient, but can create
problems. Then again, nobody would be forced to use them. :-)

> Scott

Dirk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 4 11:58:23 2005

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