You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2005/08/31 18:26:40 UTC
Re: "svn diff" and "svn log" timestamp weirdness
On Aug 31, 2005, at 12:38 PM, Todd A. Jacobs wrote:
>
> This doesn't appear relevent, since the documentation says that
> Subversion assumes midnight *if no timestamp is specified.*
> Clearly, I've specified a timestamp--one matching the logs, in fact.
I think I see the problem: the actual svn:date property attached to
the revision is a 64-bit apr_time_t value. For example, using
subversion's own repository:
$ svn propget --revprop -r16015 svn:date
2005-08-31T13:44:58.539536Z
On the other hand, 'svn log' prints a number rounded off to the
nearest second:
$ svn log -q -r16015
------------------------------------------------------------------------
r16015 | nori | 2005-08-31 08:44:58 -0500 (Wed, 31 Aug 2005)
So, when you provide the same rounded-off date to a subcommand, I'm
pretty sure that it's *also* being converted into a 64-bit time...
one which is exactly at NN.000000 seconds. When compared to the
revision's timestamp, it's almost always going to be smaller, and
thus the "latest revision at time NN.00000 seconds" is the previous
revision:
$ svn log -q -r{"2005-08-31 08:44:58"}
------------------------------------------------------------------------
r16014 | julianfoad | 2005-08-31 08:30:04 -0500 (Wed, 31 Aug 2005)
So perhaps this is a bug, just insofar as it's not doing what the
user expects. Maybe we should file an issue on this? I suppose we
could either (A) always store the svn:date property rounded off to
the nearest second, or (B) when loading the svn:date property for
comparison purposes, round it off to the nearest second (this would
be in our rev_hunt() binary search algorithm...)
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
>> -1 on changing the way we store timestamps or the search algorithm,
>
>
> Is that a hard veto or a "we haven't discussed this sufficiently yet"
> veto of what Sussman suggested? Would you have less argument with
> something that resolved some subsecond precision but abandoned the
> fiction of the current scheme (I'm thinking precision to 100ths of a
> second)?
It is a veto of this suggestion. See Michael Sinz's comments in another
response, they're relevant, and I agree with them.
This bug isn't so nasty that we have to hurry with a half-assed solution
that will scew us until 2.0. We can change the (i.e., invent an new)
server API that can be told something about the precision of the
timestamp, and we can enhance the date parser on the client to infer
that precision. We can release such API changes in any minor release.
But if we change the way the rimestamps are represented in the
repository, or worse, change the search algorithm, we're stuch with that
until 2.0 -- *and* we don't gain a thing because the results still won't
be correct if you get more than one commit within the timestamp's
precision interval.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
>
> I agree! Can you submit a patch which does both things?
>
I would except I have to fight with Brane first. ;-)
Branko Čibej wrote:
> If you want to be perfectly correct (not perfectly precise), you have
> to return the range of revisions that falls within the precision of
> the timestamp given in the query. So, "svn log -r{yesterday}" should
> give you a log of all commits made yesterday, not just the one
> revision where we happen to decide yesterday started.
And how would you propose that we add precision to the existing call? I
agree with you that being able to match timestamps in an intelligent and
configurable fuzzy way would be vastly superior to the existing hard
cut, but I don't see how to do that.
What about something like this:
svn log -r{2005/08/30}:{2005/08/30}
would return all log commits on that date (regardless of time). And this:
svn log -r{"2005/08/30T1530"}:{"T0001"}
would return all commits in the full minute of 15:30, just like this would:
svn log -r{"2005/08/30T1530"}:{"2005/08/30T1531"}
> -1 on changing the way we store timestamps or the search algorithm,
Is that a hard veto or a "we haven't discussed this sufficiently yet"
veto of what Sussman suggested? Would you have less argument with
something that resolved some subsecond precision but abandoned the
fiction of the current scheme (I'm thinking precision to 100ths of a
second)?
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 31, 2005, at 1:39 PM, John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> I suppose we could either (A) always store the svn:date property
>> rounded off to the nearest second, or (B) when loading the
>> svn:date property for comparison purposes, round it off to the
>> nearest second (this would be in our rev_hunt() binary search
>> algorithm...)
>>
>
> The best solution is to do both now; round to seconds when
> comparing, but stop storing subsecond precision. When 2.0 comes
> out, change the search code to stop rounding and perform a last
> rounding when updating the repository.
>
I agree! Can you submit a patch which does both things?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Aaron Wood wrote:
> If so, then on unix, (If I understand 'nix time engines correctly)
> later is always later, so while the timestamp may contain a fictional
> level of accuracy, it's still precise for what it needs to be (later
> is actually later). On windows, you can actually get some really ugly
> time movements as it doesn't have "time-warping" ability that I
> beleive all 'nix variants use to keep time flowing smoothly.
There are several ways that *nix time can also jump about, too. Most *nix's can
use skew (small adjustments) to move the hardware clock in response to external
syncs, but even with xntp, you can tell it to jump instead.
See also this page:
<http://cr.yp.to/proto/utctai.html>
for how localtime() and [x]ntp break during leap seconds.
The bottom line is that TAI is the only monotonically increasing time value
available and that isn't what apr_time_t is using, so there is always going to
be a certain level of uncertainty.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Aaron Wood <wo...@gmail.com>.
On 8/31/05, John Peacock <jp...@rowman.com> wrote:
> You misunderstand. I'm saying _all_ normal server hardware clocks,
> regardless of whether the machine is synced via NTP or some other
> superior method (like taiclock), lack the accuracy to justify the amount
> of precision allocated. The crystals used in conventional computer
> hardware just aren't all that accurate. And depending on your O/S, your
> clock could use skew or step to adjust time with an external source,
> which adds additional noise to the timestamp.
The timestamps are all set on the server, correct?
If so, then on unix, (If I understand 'nix time engines correctly)
later is always later, so while the timestamp may contain a fictional
level of accuracy, it's still precise for what it needs to be (later
is actually later). On windows, you can actually get some really ugly
time movements as it doesn't have "time-warping" ability that I
beleive all 'nix variants use to keep time flowing smoothly.
So, while the bottom bits of the timestamp are roughly irrevelant
noise, the 64-bit timestamp allows for an easy to manipulate timestamp
for comparison purpose. At least easier than intermediate sizes like
48 bits.
I'm not an expert on how the system works, but from this thread, it
appears that it's using a standard 64-bit time format. Which if so,
makes a lot of sense, even if the low bits appear to be noise. The
higher order bits still ensure that the comparisons make sense.
Simply masking out the lower bits also implies some knowledge of when
the accuracy of the clock is to be suspect, and opens up the problem
that in 5 years, we DO have clocks that are an order magnitude more
accurate, and we end up with resoution problems caused by faster
hardware being able to do multiple commits per ms.
We're not far from that now, where my previous desktop was easily able
to do ~10ms commits on a harddisk. Add in a RAID array that has a
battery-backed cache, and commits become VERY fast for some systems.
The extra precision is unecessary now, but may not be in a relatively
short time, especially considering how long CVS has been in use.
-Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by "Todd A. Jacobs" <no...@codegnome.org>.
On Thu, Sep 01, 2005 at 10:46:59AM -0400, Michael Sinz wrote:
>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.
I've watched the thread develop, and have a few thoughts. Firstly, the
easiest solution is probably to *truncate* log times, rather than the
current rounding. Truncating the log entry to "21:18:07" from
"21:18:07.99998" instead of rounding up to "21:18:08.00000" would at
least avoid situations where there was no matching record *at all* for
the given time period, or erroneously returning results from a future
time period.
However, as another poster mentioned, the fact that subversion *assumes*
that one wants the latest revision for a given time period is at least a
valid point of discussion. If I wanted the revision from "yesterday," I
probably would want the latest revision during that period. But if I ask
for the revision from 14:35 today, I should probably be informed if
there were 7 other commits during that one-second period, since the one
returned (the latest) may not actually be the one I *think* I'm asking
for.
The goal of returning the latest revision is obviously to reduce the
burden on the end-user. It's good goal. But it *may* violate the
principle of least-surprise from time to time.
--
Re-Interpreting Historic Miracles with SED #141: %s/water/wine/g
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Sep 01, 2005 at 02:12:55AM -0400, Greg Hudson wrote:
> On Wed, 2005-08-31 at 19:24 -0700, Justin Erenkrantz wrote:
> > The only case I can come up with is co/up that would fit that scenario
> > where we have to pick a single revision.
>
> blame, cat, copy, export, info, ...
>
> brane is proposing a pretty deep architectural change here.
To do it correctly, yes, it would require changes. But, having the
DATE-based revision usage expecting a one-to-one mapping from a
non-specific date value is a bit wrong.
However, I think a 'simple' approach wouldn't be that hard: you'd tweak
parse_one_rev and svn_parse_date to set the date to the end of the
minute boundary rather than the beginning when microseconds aren't
specified. It'd result in something more intuitive for the user rather
than doing it at the beginning of the minute boundary. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by "Todd A. Jacobs" <no...@codegnome.org>.
On Thu, Sep 01, 2005 at 10:46:59AM -0400, Michael Sinz wrote:
>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.
I've watched the thread develop, and have a few thoughts. Firstly, the
easiest solution is probably to *truncate* log times, rather than the
current rounding. Truncating the log entry to "21:18:07" from
"21:18:07.99998" instead of rounding up to "21:18:08.00000" would at
least avoid situations where there was no matching record *at all* for
the given time period, or erroneously returning results from a future
time period.
However, as another poster mentioned, the fact that subversion *assumes*
that one wants the latest revision for a given time period is at least a
valid point of discussion. If I wanted the revision from "yesterday," I
probably would want the latest revision during that period. But if I ask
for the revision from 14:35 today, I should probably be informed if
there were 7 other commits during that one-second period, since the one
returned (the latest) may not actually be the one I *think* I'm asking
for.
The goal of returning the latest revision is obviously to reduce the
burden on the end-user. It's good goal. But it *may* violate the
principle of least-surprise from time to time.
--
Re-Interpreting Historic Miracles with SED #141: %s/water/wine/g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Julian Foad <ju...@btopenworld.com>.
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.
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.
>>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.
[...]
> 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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Branko Čibej <br...@xbc.nu>.
Ph. Marek wrote:
>On Thursday 01 September 2005 11:36, Julian Foad wrote:
>
>
>>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.
>
>
That's nonsense. You have no data whatsoever by which you could even
determine a confidence curve. It could easily be the other way around --
that the midpoint is the best choice.
But anyway, this is quite academic and beside the point. We can easily
make this a client-side decision, made by the user.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Julian Foad <ju...@btopenworld.com>.
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.
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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
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.
if (X-W < Y-X)
use W;
else
use Y;
That would allow choosing revisions within 1 second, too:
W=sometime.112432
Y=sometime.862131
X=sometime.4 (with 00000 omitted)
Here W would be taken.
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?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Wed, 2005-08-31 at 19:24 -0700, Justin Erenkrantz wrote:
>
>
>>The only case I can come up with is co/up that would fit that scenario
>>where we have to pick a single revision.
>>
>>
>
>blame, cat, copy, export, info, ...
>
>brane is proposing a pretty deep architectural change here.
>
>
It isn't all that deep a change. Where a revision range really doesn't
make sense, you'd just pick either the first or the last revision in the
range. I've no opinion at this time about which choice is better, except
that it would probably be a good thing if the choice were consistent for
all commands. :)
(blame could reasonably be taught to work on a revision range, since
'svn blame -rX' already means 'svn blame -rx:HEAD', but that's a
separate issue.)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-08-31 at 19:24 -0700, Justin Erenkrantz wrote:
> The only case I can come up with is co/up that would fit that scenario
> where we have to pick a single revision.
blame, cat, copy, export, info, ...
brane is proposing a pretty deep architectural change here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Michael Brouwer wrote:
> What might be even better is to always do a less than with the value
> the user specified plus 1. If the date is the end of a range. And a
> greater or equal of the specified value with all unspecified fields set
> to 0 if the date is at the start or a range.
>
> For the end of a range this would mean:
>
> -r{2005} would find the first date < 2006
> -r{2005-05} would find the first date < 2005-06
> -r{2005-05-12} would find the first date < 2005-05-13
> -r{2005-05-12 07} would find the first date < 2005-05-12 08
> -r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
> -r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
> -r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
> 07:13:12.23
As nice as this is (and glossing over whether the change in behavior is
"fixing a bug" or not), it is still not deterministic. If there are
more than one revisions with a timestamp in the implicit range, which
one is most appropriate to return? The date search algorithm performs a
binary search, so you cannot just stop searching at the first revision
that appears to match, you'd need to switch to a linear search and
collect together the possible revisions.
I think your basic suggestion is good, but it needs a firm definition of
which revision would be returned of multiple possible returns. To use
series notation, I would think the first record that falls in the [time,
time+1) range would be most likely what the user would expect. The
binary search could find any revision in that range, then step backwards
exclusively to find the smallest revision that satisfies the range. But
at least as good an argument could be made that the largest revision
that satisfies the condition is just as correct.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Michael Brouwer wrote:
> What might be even better is to always do a less than with the value
> the user specified plus 1. If the date is the end of a range. And a
> greater or equal of the specified value with all unspecified fields set
> to 0 if the date is at the start or a range.
>
> For the end of a range this would mean:
>
> -r{2005} would find the first date < 2006
> -r{2005-05} would find the first date < 2005-06
> -r{2005-05-12} would find the first date < 2005-05-13
> -r{2005-05-12 07} would find the first date < 2005-05-12 08
> -r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
> -r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
> -r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
> 07:13:12.23
As nice as this is (and glossing over whether the change in behavior is
"fixing a bug" or not), it is still not deterministic. If there are
more than one revisions with a timestamp in the implicit range, which
one is most appropriate to return? The date search algorithm performs a
binary search, so you cannot just stop searching at the first revision
that appears to match, you'd need to switch to a linear search and
collect together the possible revisions.
I think your basic suggestion is good, but it needs a firm definition of
which revision would be returned of multiple possible returns. To use
series notation, I would think the first record that falls in the [time,
time+1) range would be most likely what the user would expect. The
binary search could find any revision in that range, then step backwards
exclusively to find the smallest revision that satisfies the range. But
at least as good an argument could be made that the largest revision
that satisfies the condition is just as correct.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
Michael Brouwer wrote:
> What might be even better is to always do a less than with the value
> the user specified plus 1. If the date is the end of a range. And a
> greater or equal of the specified value with all unspecified fields set
> to 0 if the date is at the start or a range.
>
> For the end of a range this would mean:
>
> -r{2005} would find the first date < 2006
> -r{2005-05} would find the first date < 2005-06
> -r{2005-05-12} would find the first date < 2005-05-13
> -r{2005-05-12 07} would find the first date < 2005-05-12 08
> -r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
> -r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
> -r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
> 07:13:12.23
>
> Although this is a slight change in behavior I think it solves the
> problem here are gives the user a more intuitive experience.
Actually, I think that is not the behavior that I would want as it changes
the rules. The goal of what I was saying was to just address the issue of
the user being confused by the fact that SVN LOG does not give the exact
timestamp but just up to the seconds.
In other cases, for example, if I do give you just a date, I don't think I
would want something committed at 23:59 on that date since it is unlikely
that it was in effect during that day. It also drastically breaks the behavior
of the current system - a behavior that has been documented for a long time
and which a number of people depend on.
Sometimes solving a problem does not mean trying to apply the solution
outside of the scope of the problem.
--
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
Michael Brouwer wrote:
> What might be even better is to always do a less than with the value
> the user specified plus 1. If the date is the end of a range. And a
> greater or equal of the specified value with all unspecified fields set
> to 0 if the date is at the start or a range.
>
> For the end of a range this would mean:
>
> -r{2005} would find the first date < 2006
> -r{2005-05} would find the first date < 2005-06
> -r{2005-05-12} would find the first date < 2005-05-13
> -r{2005-05-12 07} would find the first date < 2005-05-12 08
> -r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
> -r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
> -r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
> 07:13:12.23
>
> Although this is a slight change in behavior I think it solves the
> problem here are gives the user a more intuitive experience.
Actually, I think that is not the behavior that I would want as it changes
the rules. The goal of what I was saying was to just address the issue of
the user being confused by the fact that SVN LOG does not give the exact
timestamp but just up to the seconds.
In other cases, for example, if I do give you just a date, I don't think I
would want something committed at 23:59 on that date since it is unlikely
that it was in effect during that day. It also drastically breaks the behavior
of the current system - a behavior that has been documented for a long time
and which a number of people depend on.
Sometimes solving a problem does not mean trying to apply the solution
outside of the scope of the problem.
--
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Brouwer <mi...@tlaloc.net>.
What might be even better is to always do a less than with the value
the user specified plus 1. If the date is the end of a range. And a
greater or equal of the specified value with all unspecified fields
set to 0 if the date is at the start or a range.
For the end of a range this would mean:
-r{2005} would find the first date < 2006
-r{2005-05} would find the first date < 2005-06
-r{2005-05-12} would find the first date < 2005-05-13
-r{2005-05-12 07} would find the first date < 2005-05-12 08
-r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
-r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
-r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
07:13:12.23
Although this is a slight change in behavior I think it solves the
problem here are gives the user a more intuitive experience.
svn log -r{2004}:{2004} would then show all changes that happened in
2004.
Michael
On Sep 1, 2005, at 8:06 AM, Ben Collins-Sussman wrote:
>
> On Sep 1, 2005, at 9:46 AM, Michael Sinz wrote:
>
>>
>> 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.
>>
>
> Gee, this is an awfully simple solution, and solves the exact
> problem reported, without designing a whole new slew of behaviors...
>
>
> --
> www.collab.net <> CollabNet | Distributed Development On Demand
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Brouwer <mi...@tlaloc.net>.
What might be even better is to always do a less than with the value
the user specified plus 1. If the date is the end of a range. And a
greater or equal of the specified value with all unspecified fields
set to 0 if the date is at the start or a range.
For the end of a range this would mean:
-r{2005} would find the first date < 2006
-r{2005-05} would find the first date < 2005-06
-r{2005-05-12} would find the first date < 2005-05-13
-r{2005-05-12 07} would find the first date < 2005-05-12 08
-r{2005-05-12 07:13} would find the first date < 2005-05-12 07:14
-r{2005-05-12 07:13:12} would find the first date < 2005-05-12 07:13:13
-r{2005-05-12 07:13:12.22} would find the first date < 2005-05-12
07:13:12.23
Although this is a slight change in behavior I think it solves the
problem here are gives the user a more intuitive experience.
svn log -r{2004}:{2004} would then show all changes that happened in
2004.
Michael
On Sep 1, 2005, at 8:06 AM, Ben Collins-Sussman wrote:
>
> On Sep 1, 2005, at 9:46 AM, Michael Sinz wrote:
>
>>
>> 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.
>>
>
> Gee, this is an awfully simple solution, and solves the exact
> problem reported, without designing a whole new slew of behaviors...
>
>
> --
> www.collab.net <> CollabNet | Distributed Development On Demand
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 1, 2005, at 9:46 AM, Michael Sinz wrote:
>
> 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.
Gee, this is an awfully simple solution, and solves the exact problem
reported, without designing a whole new slew of behaviors...
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 1, 2005, at 9:46 AM, Michael Sinz wrote:
>
> 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.
Gee, this is an awfully simple solution, and solves the exact problem
reported, without designing a whole new slew of behaviors...
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
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?
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
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?
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
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).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
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).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 31, 2005 4:31:32 PM -0400 John Peacock <jp...@rowman.com>
wrote:
> I don't have any problem setting the resolution at something less than a
> second; going to 1/100ths or 1/1000ths is probably good. Milliseconds
> are reasonable; microseconds gets into the range of context swaps in the
> kernel (i.e. noise) and nanoseconds (or god forbid attoseconds) are just
> fictional for conventional PC's.
I agree 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 31, 2005 4:31:32 PM -0400 John Peacock <jp...@rowman.com>
wrote:
> I don't have any problem setting the resolution at something less than a
> second; going to 1/100ths or 1/1000ths is probably good. Milliseconds
> are reasonable; microseconds gets into the range of context swaps in the
> kernel (i.e. noise) and nanoseconds (or god forbid attoseconds) are just
> fictional for conventional PC's.
I agree 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Michael Sinz wrote:
> I would very strongly be against anything that reduces the precision of
> the data on the server. If the server's clock is not accurate, then that
> is not Subversion's fault. Let the server admin fix it (or buy a better
> server or...) Chopping off precision just because some user interface
> issues due to too much precision is wrong. Just make the UI smarter about
> how to deal with that. You can always change, enhance, etc. that behavior
> if the data is there. If you don't have the data, you now have lost
> the ability to ever expand into, say 1/10 second or 1/100 second or
> whatever
> resolution you might think is reasonable.
>
You misunderstand. I'm saying _all_ normal server hardware clocks,
regardless of whether the machine is synced via NTP or some other
superior method (like taiclock), lack the accuracy to justify the amount
of precision allocated. The crystals used in conventional computer
hardware just aren't all that accurate. And depending on your O/S, your
clock could use skew or step to adjust time with an external source,
which adds additional noise to the timestamp.
I don't have any problem setting the resolution at something less than a
second; going to 1/100ths or 1/1000ths is probably good. Milliseconds
are reasonable; microseconds gets into the range of context swaps in the
kernel (i.e. noise) and nanoseconds (or god forbid attoseconds) are just
fictional for conventional PC's.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Michael Sinz wrote:
> I would very strongly be against anything that reduces the precision of
> the data on the server. If the server's clock is not accurate, then that
> is not Subversion's fault. Let the server admin fix it (or buy a better
> server or...) Chopping off precision just because some user interface
> issues due to too much precision is wrong. Just make the UI smarter about
> how to deal with that. You can always change, enhance, etc. that behavior
> if the data is there. If you don't have the data, you now have lost
> the ability to ever expand into, say 1/10 second or 1/100 second or
> whatever
> resolution you might think is reasonable.
>
You misunderstand. I'm saying _all_ normal server hardware clocks,
regardless of whether the machine is synced via NTP or some other
superior method (like taiclock), lack the accuracy to justify the amount
of precision allocated. The crystals used in conventional computer
hardware just aren't all that accurate. And depending on your O/S, your
clock could use skew or step to adjust time with an external source,
which adds additional noise to the timestamp.
I don't have any problem setting the resolution at something less than a
second; going to 1/100ths or 1/1000ths is probably good. Milliseconds
are reasonable; microseconds gets into the range of context swaps in the
kernel (i.e. noise) and nanoseconds (or god forbid attoseconds) are just
fictional for conventional PC's.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> I suppose we could either (A) always store the svn:date property
>> rounded off to the nearest second, or (B) when loading the svn:date
>> property for comparison purposes, round it off to the nearest second
>> (this would be in our rev_hunt() binary search algorithm...)
>
> My 2 cents:
>
> A) is better in the long run, because it doesn't perpetuate the illusion
> that computer clocks are that accurate unless you are regularly syncing
> with a reference clock; I've seen drift rates of seconds to minutes per
> month. Just because someone decided to provide nanosecond precision
> doesn't mean that your computer can provide meaningful data at that
> level. Precision != accuracy.
No - I would *not* want to have the times on the server cut off to a
low precision just because some servers may not have good clocks.
But if you run a server and are not running ntpd then you are asking for
problems. (especially when trying to track down networking
related issues - you want your clock as accurate as possible)
With many developers hitting the same server, it is possible to have more
than one commit per second. Don't throw away data.
> B) is better for compatibility purposes, since it ignores existing
> subsecond precision.
This is much better - have the UI (or whatever you what to call it)
be the place where such rounding and "fuzzy" comparisons happen.
> The best solution is to do both now; round to seconds when comparing,
> but stop storing subsecond precision. When 2.0 comes out, change the
> search code to stop rounding and perform a last rounding when updating
> the repository.
I would very strongly be against anything that reduces the precision of
the data on the server. If the server's clock is not accurate, then that
is not Subversion's fault. Let the server admin fix it (or buy a better
server or...) Chopping off precision just because some user interface
issues due to too much precision is wrong. Just make the UI smarter about
how to deal with that. You can always change, enhance, etc. that behavior
if the data is there. If you don't have the data, you now have lost
the ability to ever expand into, say 1/10 second or 1/100 second or whatever
resolution you might think is reasonable.
--
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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 31, 2005, at 1:39 PM, John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> I suppose we could either (A) always store the svn:date property
>> rounded off to the nearest second, or (B) when loading the
>> svn:date property for comparison purposes, round it off to the
>> nearest second (this would be in our rev_hunt() binary search
>> algorithm...)
>>
>
> The best solution is to do both now; round to seconds when
> comparing, but stop storing subsecond precision. When 2.0 comes
> out, change the search code to stop rounding and perform a last
> rounding when updating the repository.
>
I agree! Can you submit a patch which does both things?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Michael Sinz <Mi...@sinz.org>.
John Peacock wrote:
> Ben Collins-Sussman wrote:
>
>> I suppose we could either (A) always store the svn:date property
>> rounded off to the nearest second, or (B) when loading the svn:date
>> property for comparison purposes, round it off to the nearest second
>> (this would be in our rev_hunt() binary search algorithm...)
>
> My 2 cents:
>
> A) is better in the long run, because it doesn't perpetuate the illusion
> that computer clocks are that accurate unless you are regularly syncing
> with a reference clock; I've seen drift rates of seconds to minutes per
> month. Just because someone decided to provide nanosecond precision
> doesn't mean that your computer can provide meaningful data at that
> level. Precision != accuracy.
No - I would *not* want to have the times on the server cut off to a
low precision just because some servers may not have good clocks.
But if you run a server and are not running ntpd then you are asking for
problems. (especially when trying to track down networking
related issues - you want your clock as accurate as possible)
With many developers hitting the same server, it is possible to have more
than one commit per second. Don't throw away data.
> B) is better for compatibility purposes, since it ignores existing
> subsecond precision.
This is much better - have the UI (or whatever you what to call it)
be the place where such rounding and "fuzzy" comparisons happen.
> The best solution is to do both now; round to seconds when comparing,
> but stop storing subsecond precision. When 2.0 comes out, change the
> search code to stop rounding and perform a last rounding when updating
> the repository.
I would very strongly be against anything that reduces the precision of
the data on the server. If the server's clock is not accurate, then that
is not Subversion's fault. Let the server admin fix it (or buy a better
server or...) Chopping off precision just because some user interface
issues due to too much precision is wrong. Just make the UI smarter about
how to deal with that. You can always change, enhance, etc. that behavior
if the data is there. If you don't have the data, you now have lost
the ability to ever expand into, say 1/10 second or 1/100 second or whatever
resolution you might think is reasonable.
--
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
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> I suppose we could
> either (A) always store the svn:date property rounded off to the
> nearest second, or (B) when loading the svn:date property for
> comparison purposes, round it off to the nearest second (this would be
> in our rev_hunt() binary search algorithm...)
My 2 cents:
A) is better in the long run, because it doesn't perpetuate the illusion
that computer clocks are that accurate unless you are regularly syncing
with a reference clock; I've seen drift rates of seconds to minutes per
month. Just because someone decided to provide nanosecond precision
doesn't mean that your computer can provide meaningful data at that
level. Precision != accuracy.
B) is better for compatibility purposes, since it ignores existing
subsecond precision.
The best solution is to do both now; round to seconds when comparing,
but stop storing subsecond precision. When 2.0 comes out, change the
search code to stop rounding and perform a last rounding when updating
the repository.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by John Peacock <jp...@rowman.com>.
Ben Collins-Sussman wrote:
> I suppose we could
> either (A) always store the svn:date property rounded off to the
> nearest second, or (B) when loading the svn:date property for
> comparison purposes, round it off to the nearest second (this would be
> in our rev_hunt() binary search algorithm...)
My 2 cents:
A) is better in the long run, because it doesn't perpetuate the illusion
that computer clocks are that accurate unless you are regularly syncing
with a reference clock; I've seen drift rates of seconds to minutes per
month. Just because someone decided to provide nanosecond precision
doesn't mean that your computer can provide meaningful data at that
level. Precision != accuracy.
B) is better for compatibility purposes, since it ignores existing
subsecond precision.
The best solution is to do both now; round to seconds when comparing,
but stop storing subsecond precision. When 2.0 comes out, change the
search code to stop rounding and perform a last rounding when updating
the repository.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> So perhaps this is a bug, just insofar as it's not doing what the
> user expects. Maybe we should file an issue on this? I suppose we
> could either (A) always store the svn:date property rounded off to
> the nearest second, or (B) when loading the svn:date property for
> comparison purposes, round it off to the nearest second (this would
> be in our rev_hunt() binary search algorithm...)
Actually, the bug lies in the fact that we try to select one revision
for any particular time. Even if we round off the timestamp for the
search, or even store the rounded value in the repository, it's quite
probable that several revisions will fall within the one-second interval
in busy repositories (it probably happens in the ASF repo, for example).
If you want to be perfectly correct (not perfectly precise), you have to
return the range og revisions that falls within the precision of the
timestamp given in the query. So, "svn log -r{yesterday}" should give
you a log of all commits made yesterday, not just the one revision where
we happen to decide yesterday started.
-1 on changing the way we store timestamps or the search algorithm,
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: "svn diff" and "svn log" timestamp weirdness
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> So perhaps this is a bug, just insofar as it's not doing what the
> user expects. Maybe we should file an issue on this? I suppose we
> could either (A) always store the svn:date property rounded off to
> the nearest second, or (B) when loading the svn:date property for
> comparison purposes, round it off to the nearest second (this would
> be in our rev_hunt() binary search algorithm...)
Actually, the bug lies in the fact that we try to select one revision
for any particular time. Even if we round off the timestamp for the
search, or even store the rounded value in the repository, it's quite
probable that several revisions will fall within the one-second interval
in busy repositories (it probably happens in the ASF repo, for example).
If you want to be perfectly correct (not perfectly precise), you have to
return the range og revisions that falls within the precision of the
timestamp given in the query. So, "svn log -r{yesterday}" should give
you a log of all commits made yesterday, not just the one revision where
we happen to decide yesterday started.
-1 on changing the way we store timestamps or the search algorithm,
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org