One (US) thanksgiving day about 10 years ago most of the eastern seaboard
lost telephone service because some clever developer figured a millisecond
resolution timestamp would always provide a unique key... and he or she was
wrong about that. (As an aside, the bug caused the telephone switch to fail
and to send out a series of messages in short order... which caused nearby
switches to receive multiple messages with the same timestamp, which caused
that switch to fail, which...)
So you always need to sort revisions by date and some other number, like a
monotonically increasing integer. Combine those and you only fail if you
have 2**32 commits in whatever interval your system measures a tick. As
someone else said, man would I like to get my hands on a processor where
that could be a problem!
In the SQL case, the primary key is likely to be some sort of database
GUID, which tends to be a long ugly string when it's presented in "user
readable" form. Some sort of more user friendly identifier will be
required. In any event the current approach is more than adequate.
At 2002/05/03 12:16 -0500, Ben Collins-Sussman wrote:
>Well, that's kind of the point. Once we have a real SQL table or
>somesuch in our filesystem back end, then the revision "names" don't
>become so important. All revisions have datestamp properties attached
>to them. As long as we are always able to sort our revisions table by
>date, we'll have a well-ordered time machine. The revision names
>become irrelevant.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 3 19:47:27 2002