Python patch analog

[Terry Hancock]

Laura Creighton wrote:
> Terry Hancock wrote:
>> 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).
> 
> That is what we ended up having to do.  And when the server hit DST,
> all hell broke loose.  Also, when somebody carefully rebooted the
> server to think that it was now the Unix Epoch (Jan 1 1970 00:00:01).
> Also when somebody made the date 10 years in the future.

Hmm. Sounds like implementing an incremental checkout number is the way to 
go. Then, the object only needs to remember what number it's on, and 
timestamps are just a convenience for the reader.

>> 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.
> 
> I believe, this is known as 'a tricky bit'.  The people who are making
> an Open Source python rewriting of Arch may have some ideas you are
> interested in.

Thanks, I'll take a look at that. There's already a primitive internal 
state representation of this in PVC, but it probably needs a lot of 
refinement.

I guess you mean these?
Arch: http://www.fifthvision.net/open/bin/view/Arch/
EVA:  http://initd.org/pub/software/eva/
and I see an ML for EVA.

Thanks for the ideas,
Terry

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