On Wed, Aug 31, 2005 at 08:58:33PM -0500, Ben Collins-Sussman wrote:
> 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.
For 'svn up -r{DATE}'?
> 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"}
>
> ?
Yes. (Assuming that it treats 14:18.00 as < not <=.)
> 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?
The only case I can come up with is co/up that would fit that scenario
where we have to pick a single revision.
Now, it's always possible for there to be multiple commits in the same
second (which is why chopping off at the second in the repos is
harmful). For the co/up case we'd have to make a decision whether it
implies the first revision at that second or the last revision.
I'm not yet sure which makes the most sense though. There's always the
possibility of just erroring out and say that the date isn't precise
enough to make a decision. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 1 04:27:00 2005