Ph. Marek wrote:
> 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.
In fact, many times it is not. Use of date revision handles is usually to
get the state of the repository at that date/time. Returning anything that
is "in the future" of that given date/time would actually be very invalid.
No matter how "near" that may be.
> 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.
Use the revision number - that will be the shortest for all but the most
busy repositories - a date string will almost always be longer than a revision
number...)
> 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.
I am so confused here - if you really want a specific revision (from svn log)
then why not use the revision number. That will most likely be the least amount
of typing and correctly represent a specific revision.
Time stamp selection of revisions is, by its very nature, somewhat fuzzy.
Even if you fully specify the date to the seconds, there could be more than
one at that specific second. (Ok, so this is a bit contrived since it was
done with a script, but, it did happen on a not-so-fast workstation)
------------------------------------------------------------------------
r4 | mks | 2005-09-01 10:17:15 -0400 (Thu, 01 Sep 2005) | 1 line
Changed paths:
M /file.txt
checkin 3
------------------------------------------------------------------------
r3 | mks | 2005-09-01 10:17:15 -0400 (Thu, 01 Sep 2005) | 1 line
Changed paths:
M /file.txt
checkin 2
------------------------------------------------------------------------
r2 | mks | 2005-09-01 10:17:15 -0400 (Thu, 01 Sep 2005) | 1 line
Changed paths:
M /file.txt
checkin 1
------------------------------------------------------------------------
r1 | mks | 2005-09-01 10:16:19 -0400 (Thu, 01 Sep 2005) | 1 line
Changed paths:
A /file.txt
initial checkin
------------------------------------------------------------------------
> Otherwise I believe that a warning must be given, as we cannot say *with
> certainty* what the user wants.
Depends on what is being done. The book clearly states the behavior of
the date selection of the revisions. If you check out
http://svnbook.red-bean.com/en/1.1/ch03s03.html#svn-ch-3-sect-3.3
you will see that this has been covered.
Now, I don't know how else to better describe the situation. If you need
a specific revision, I would want not the "closest" revision but the
revision that was valid at that time.
For example, if a R10 is on December 15, 2004 and R11 is on July 20, 2005,
if I ask for a dated revision of July 10, 2005, I would fully expect that R10
be returned. In fact, I would require that, since if I wanted to recreate
the build/source tree as seen on July 10, 2005 (for example from some other
project/repository/etc) then I would not want to suddently get R11 just because
it is "closer" to the date specified.
Now, I used days/months of difference but the same could be said for minutes
or even seconds. If I want to get the state of things at 14:23:41 then I
really don't want the stuff from 14:23:41.722 since that is in the future.
Now, the user interface may be an issue with the svn log not giving enough
information, but if you really want a specific revision, svn log gives you
something much better than a timestamp could ever be: the actual revision.
--
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:31:59 2005