Ben Collins-Sussman wrote:
>
> On Aug 31, 2005, at 8:50 PM, John Peacock wrote:
>
>> Justin Erenkrantz wrote:
>>
>>> I agree [with] Brane and Michael: fix the UI to return it over the
>>> implicit period in question. Removing any level of precision in the
>>> repository from what APR produces (64-bit microseconds) gets a -1
>>> from me too.
>>> (There were lots of heated debates over 'time' in APR. Ugh.) --
>>> justin
>>>
>>
>> I'm resigned to lose this argument. Correct handling of time values
>> arouses passion in the few people who understand how thoroughly
>> broken default implementations are currently. I've fought this
>> before (and probably will again).
>
>
> Trying to get back on track here...
>
> So the original "bug" was that from the user's point of view, it looks
> like there ought to be a 1 to 1 mapping between the dates 'svn log'
> displays and the dates one can specify with -r{DATE}. But in fact,
> there isn't a direct mapping, due to rounding to the nearest second.
> If 'svn log' says that rN happened at time "2005-08-23 00:14:17", when
> the user types -r{"2005-08-23 00:14:17"}, he gets r (N-1) back, because
> it turns out that the commit-time is actually recorded as 00:14:17.23983.
>
> Are you guys suggesting, therefore, that
>
> -r{"2005-08-23 00:14:17"}
>
> ...actually be interpreted as if the user had typed
>
> -r{"2005-08-23 00:14:17.00"}:{"2005-08-23 00:14:18.00"}
>
> ?
>
> The result might be a range of revisions. This is all fine and good
> for 'svn log', but a lot of commands don't take revision ranges. What
> do we do then?
I think I tried to answer this in another reply.
The book is rather clear on how this works and I think people are missing
the real reason dates are used in actual situations: You want the state
of the repository at that given date/time.
This should always be the latest revision that does not come after the given
date/time.
But, real confusion happens due to the lack of sub-second display in svn log
and yet sub-second storage in the repository. Thus, if you pick an exact time
you may actually get one previous to that since it is unlikely that the
sub-second value is 0.
So, maybe the client could always take the time and if use specified to the
second it would add in 0.9999 seconds such that any missing sub-second
value would be handled in the way the user expects.
Anyway, it is important not to take the fact that missing information is
causing some confusion and changing that into a date/time revision selection
that does a nearest match or some other major and significant difference.
PS - There is yet another major issue with all of this and that is that the
revision date property is actually changeable and thus using date selection
on a repository is a potentially unreliable operation anyway. (See the end of
http://svnbook.red-bean.com/en/1.1/ch03s03.html#svn-ch-3-sect-3.3
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 1 16:48:24 2005