On Thursday 01 September 2005 12:21, Julian Foad wrote:
> Ph. Marek wrote:
> > On Thursday 01 September 2005 11:36, Julian Foad wrote:
> >>Ph. Marek wrote:
> >>>Why not take the nearest? Ie.
> >>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?
>
> Ah, you evidently have a different idea of what the command means. The
> present meaning of "-r{2005-05-05}" is "the repository state that existed
> at the beginning of 2005-05-05". Thus, the state that came into existence
> four months earlier is definitely the correct one.
Ok, I understand that.
> It is only when we are comparing two times within the resolution interval
> to which one of them was specified (typically one second) that we might
> want to behave a bit differently.
Ok. So if I specify only a day I should get a warning if there were two
commits at that day, no? Otherwise I may get the wrong one, because I didn't
realize (eg because the screen scrolled off to fast) that more than one
matched.
> > But it's only in the exact _middle_ where we _cannot_ make anything other
> > than a guess.
>
> No, that's false. Wherever you are in the interval, saying that "the
> nearest time is the one the user wants" is still only a guess.
But an educated 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?
>
> I didn't say that. That is one possible set of approaches, but I think we
> can find a solution that doesn't require any warning message at all.
>
> [...]
>
> > I see no problem in choosing the most likely.
>
> The "most likely" is not necessarily the nearest.
Julian, I appreciate your understanding. After all, I say "compare with the
version that existed at {date, time}", and it's very well to assume 00:00:00
if no time specified, 00:00 if only an hour, and so on.
But that still collides with my needs for the user-interface, where I'd like
to specify *a revision* with as little keystrokes as possible.
For revision A at 01:00:00 and revision B at 02:00:00 a specification with a
day before is not the same.
Further thinking about that we could believe it may be necessary to take the
*last* revision that matches - this would be the one on 23:59:59 that day, as
that's possibly the one I saw as the screen scrolled by. But that's wrong, as
the listing order differs for "svn log -rA:B" and "svn log -rB:A".
So I still propose that the client sends the center of the given period
(12o'clock for date entered, the 14.0th to 15.5th day if a month was given,
and so on) and the nearest matching is taken.
Otherwise I believe that a warning must be given, as we cannot say *with
certainty* what the user wants.
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 14:00:39 2005