Python patch analog
hancock at anansispaceworks.com
Thu Jan 9 10:14:17 CET 2003
Laura Creighton wrote:
> What happens when somebody's computer has a completely wrong idea what
> it is? What happens when daylight savings time happens? What happens
> when you share data between users in different time zones? different
> time zones with different rules for what day we start daylight savings?
Yeah, I thought of that, but -- the repository object keeps its own time.
You just keep track of checkouts and user ids on the server. I can just
encode the checkout time as part of the checkout protocol, so that it stays
with the "local copy" that the user receives (as with CVS, we'll need to
store some metadata along with the client's "local copy" -- we just keep
the checkout identity with this metadata).
Of course, the way I want to use it, the local copy is not necessarily
persistent -- the client does check-out and check-in instead of loading and
saving the data locally (i.e. the user experience is of working directly on
the web-accessable object). Even so, concurrency will happen if two
people are working on the object at once.
But one could implement CVS-type functionality using it, by having a simple
client that just saved data and metadata to disk.
It is, of course, true, that I'm shipping the whole data back and forth --
not doing the diffing in the client. So it may not be as bandwidth-
efficient as CVS. I'm not sure how important that would be in practice.
If you want to get really fancy, you can even do a hash on the checkout
data so you can verify the identity of the sender as the one who did the
checkout in the first place (the signature is just an additional piece of
metadata to track with the file).
Also, of course, it isn't really *time* that's important -- just the
correct checkout sequence -- as long as they're in the right order,
everything is peachy.
Hmm. The server's time could glitch, of course, or be set backwards before
the last checkout, and that might create a problem. We could actually use
an auto-incrementing transaction number, and not use time at all, to avoid
that problem. I see time as being more convenient for the people using it,
though -- of course, we could just keep both data on the transaction, with
the timestamp being used for readability.
There's another class of events that has to be tracked, which is moderation
actions. There's actually more than one kind of checkout that can happen at
a given time (sort of like "branches" in CVS?), in that the changes can be
made with some pre-existing patches ignored. In that case, the type of
checkout made needs to be in the metadata. In short -- we need enough
information for the repository to reconstruct what the user would've
More information about the Python-list