[vos-d] s5 version control and persistence

[Lalo Martins]

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...

best,
                                               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.
                           -----
personal:                    http://lalo.hystericalraisins.net/
technical:                    http://www.hystericalraisins.net/
GNU: never give up freedom                 http://www.gnu.org/