> Brian Huddleston writes:
> >
> > Compare the above to a timestamp which can fail if:
> >
> > 1) The edits are within the granularity of the time stamp.
>
> CVS has code to ensure that that can't happen (it sleeps until the time
> is later than the last timestamp).
Heh...that's sort of cool, actually...I'm not sure I understand completely,
though. Please
see my comments at the bottom.
> > 2) The sys-admin (or any bozo with sudo shell access) diddles the system
> > clock.
>
> Anyone who sets the clock backwards is inviting disaster.
I don't necessarily disagree. We're just arguing about the propriety of
trusting the
system clock for change detection.
> > 3) Daylight savings switchover (in most parts of the US).
>
> Timestamps are in UTC on any sane system and thus unaffected by DST.
Which isn't the same as "All systems use UTC."
> > 4) Automatic NTP correction of the system time (pretty common in the
Unix
> > server world).
> > (Under Windows 2000 it is possible for all the machines in a given
> > domain to periodically
> > sync their clocks with the PDC).
>
> NTP never sets the clock backwards (see 2, above).
That doesn't seem to be true. (Was just playing with it on my workstation
to make sure
I wasn't going insane). I was able to set my clock ahead and then ntpdate
it back.
> > 5) touch -r (although that's a bit of a pathological case)
>
> See 2, above.
>
> > 6) Getting completely scrambled by a misbehaving samba servers.
(Heh...no
> > flames
> > please. Just something I've seen happen.)
>
> No comment.
*chuckle*
> > How often do these happen? I'd be willing to bet $50 that it is less
often
> > than a 128bit or 160bit
> > digest routine duplicates. ;-)
>
> I think you meant *more* often. And I agree, but they almost always
> cause CVS to think that the file might have been changed when it wasn't,
> which isn't a serious problem in most cases.
Yes, but at probabilities that small, you also have to consider the risk of
some random Near-Earth
Object smacking into your machine and wiping out your changes anyway.
The chances of collision are so infintessimally small, that even if one
managed to happen to anyone within the lifetime of CVS (which is a good
product, so let's say 500 or 600 years), that even if the commit never
happened and even if a later commit didn't make the whole thing moot, and
even if it was an important change and even if it really screwed something
up and you got fired from your place of Employment you could still make the
same money by going on the lecture circuit as "the guy who managed to find a
real life MD5 collision". :-)
(Heh...and at that probability level it isn't that much more unlikely that
another meteor wouldn't bean your boss before he finishes firing you
anyway.)
The argument that timestamp screwups are safer seems to rely on the
assertion that time always moves forward.
While that may generally be true, it can't always be relied upon, certainly.
Ignoring for a moment your answer to 1), it could result in data loss.
So do I understand correctly:
1) Developer A checks in some code at Jan 1 14:45
2) Developer B (who has a clock that is five minutes behind) immediately
checks out the result.
3) Developer B makes some changes and then commits them.
So Developer B's cvs commit will hang for five minutes while it catches up?
Brian Huddleston
Huddleston Consulting
