Ross Golder wrote:
> On ศ., 2006-05-05 at 09:35 +0200, Michael Haggerty
wrote:
>> Ross Golder wrote:
>> I haven't looked at the code yet, but from your
description it sounds
>> like your algorithm would be susceptible to the
opposite problem--that
>> if the clock was temporarily set to 2038, then all
subsequent commits
>> would be pushed far into the future. Do I
understand this correctly?
>>
>
> Erm, that's quite probably the case. I only designed it
in light of the
> GNOME migration, where our clockskew problem was
(apparently) related to
> a dodgy BIOS battery in one of the original GNOME CVS
servers that
> resulted in the clock being repeatedly reset to 1997
after power
> failures and was often left like that for quite a while
before people
> noticed. I don't think there are any cases of forward
clockskew in the
> GNOME CVS history, so I didn't consider it in the
patch.
> [...]
>
>> It occurred to me that many of the worst
"future" problems could be
>> avoided with the rule that any date that is later
than the present
>> (i.e., the time of the conversion) is ipso facto
bogus, and should not
>> trigger past->future adjustments. This could
perhaps be implemented by
>> ruthlessly changing all "future" dates to
763 BCE and then using your
>> algorithm to repair the damage.
The commit-dependency code that has been integrated into
trunk adjusts
timestamps forwards, as Ross suggested. It also implements
my idea to
treat any timestamps that are more than one day in the
future as bogus,
and adjusts them backwards to prevent them from pulling lots
more
revisions into the future. (They'll still screw up the
commit order and
cause other mayhem, but not as terrible as the old code.)
It would be possible to do a better job if bogus
"future" timestamps
could be detected earlier and marked as bogus. Then, after
the
changesets are known, the bogus timestamps could be tweaked
to ensure
that they precede all of their non-bogus successors in the
dependency graph.
Michael
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe cvs2svn.tigris.org
For additional commands, e-mail: dev-helpcvs2svn.tigris.org
|