Python patch analog

[Terry Hancock]

Laura Creighton wrote:
> What happens when somebody's computer has a completely wrong idea what
> time
> 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 
checked out.

Cheers,
Terry

-- 
Anansi Spaceworks
http://www.anansispaceworks.com