Also spracht Reed Hedges (Tue, 16 Oct 2007 10:24:27 -0400):
>> - type list
>> - child list
>> - payload, if any (eg properties)
>> - security capabilities
> - parent list?

That would be problematic.  Since the PCRs are already represented on the 
"parent" side, having them repeated on the child would open a potential 
spot for corruption.  Also, it kind of breaks the idea that an object 
only "commits" itself; if it adds a new child, then the child would have 
to update its parent list.  Most of all, I don't think it's necessary.

>> Version control: how it's stored
> Hmm, it seems the only thing that you need to "reason" about merging is
> textual property data.

I don't think so.  I think the most common type of "merging" we'll have 
is on child lists.

> I think we should really never have any
> situation in which there's a "conflict", unless you as a user
> specifically command it to merge two divergent branches, then of course
> you are there to resolve conflicts.

Right.  In all other cases, I suppose the newer revision overrides the 
older one, when there is conflict.

> What would the downsides be to treating payload (e.g. property data) as
> atomic?   We can do diffs in a "version history" UI to present it in a
> nicer way.

We could.

>> Revisions and transactions
> Sounds pretty good, not sure I understand all the issues with local
> objects doing commits.  Any particular call chain would be building up a
> list of commits, that would be executed by the initial vobject that got
> the message before it returns from handling the message and sends any
> reply?

The commits are executed immediately.

> Regarding transactions, is this something that could be saved for later,
> after the basic revision control is implemented,or does it have to be
> integrated now?

No, I think we could leave them for later.  Let's need them first :-)

>> Horizons
>> ========
>> Off the top of my head, I think we'd like to be able to set a horizon
>> per host, per type, and per vobject, in that order of precedence
>> (vobject overrides type).  What if a vobject has two different types
>> that specify a horizon?  Respect the first?  The last?
> What is a horizon??

A preference of how many historical revisions to keep.  You may set your 
host globally to a horizon of, say, 10, to save space; or set some less 
important object to a small number, because you don't care...

                                               Lalo Martins
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
GNU: never give up freedom       

vos-d mailing list

Reply via email to