On Thursday 01 September 2005 11:36, Julian Foad wrote:
> Ph. Marek wrote:
> > Another idea:
> >
> > If I understand the issue correctly, we end with a timestamp X given by
> > the user, and find in the repository the timestamps W and Y, where W <= X
> > <=Y and W < Y, and have to choose between W and Y.
> >
> > Why not take the nearest? Ie.
>
> [...]
>
> > And for the case that both differences are equal (unlikly, as
> > microseconds are stored), we could throw a warning - "given timestamp is
> > equally likely to W and Y, take one".
> >
> > How's that?
>
> That's absolutely horrible. Imagine the last two changes were in
> 2005-01-01 and 2005-06-06. Then if I asked for 2005-05-05 it would give me
> the 2005-06-06 version, wrong by over a month.
And the other is wrong by 4 months. Which should we take?
> Having a warning just for the exact midway point is equally horrible: the
> choice being made does not suddenly become "unsafe" at the exact midpoint,
> it smoothly becomes less safe the further you are from either end.
You're right in that's not suddenly unsafe.
Confidence
100% ^ ^
|\_ _/|
| \_ _/ |
| ~\__ __/~ |
| ~----__ __---~ |
0% +---------------====0====--------------+
Rev. W Rev. Y
But it's only in the exact _middle_ where we _cannot_ make anything other than
a guess.
So you say there should be a threshold - 1 day? 1 month? 1 minute? Perhaps 10%
of the difference between the two revisions, like this?
Confidence
100% ^----+ +-----^
| | | |
| | | |
| | | |
| | | |
0% +----+000000000000000000000000000+-----+
Rev. W Rev. Y
I agree that it's not nice to choose a revision 1 month away from the given
date - but if the other is 4 months away, it seems the best bet.
- I wouldn't want a user to enter the *exact* date to the stored precision,
ie. microseconds.
- So we have to choose between two revisions, where normally one will be very
"near" and another "in the distance".
I see no problem in choosing the most likely.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 1 12:01:49 2005