Greg Hudson <ghudson@MIT.EDU> writes:
> (Rev-prop changes are not intrinsically logged right now, and must be
> logged using hook scripts. But they should have history! Here's an
> outline proposal of how to do it:
>
> Instead of modelling rev-props as a name -> value mapping, model
> them as a name -> list of (value, author, date) tuples. Figure
> out how to store the new model in a manner compatible with the
> old model. Provide access functions which access the entire
> list for a rev-prop; the existing access function will of course
> just return the value of the most recent tuple.
>
> With that in place, it becomes much essentially unimportant to log write
> operations, although once you have an access log it's natural to throw
> them in.)
I've been thinking about something similar for some time now. Here's
a straw-man BDB implementation proposal:
Today, an transaction property list is stored like so:
(NAME VALUE ...)
Note that both NAME and VALUE are skel atoms.
We could tweak the code to recognize a new definition as well:
(NAME () ...)
We could tweak the code to recognize that if, in fact, a VALUE is a
list instead of an atom, something special
Today, an empty transaction property list is stored as just that,
an empty list skel. We could tweak the code to recognize that if
instead of a list there is a 0-length atom, this special value
means, "go read the txnprops table." That txnprops table would be
a BDB dupkeys implementation, where the rows are in one of the
following formats:
TXN_ID "/" NAME -> ("propset" VALUE AUTHOR DATE)
TXN_ID "/" NAME -> ("propdel" AUTHOR DATE)
Adding, changing, or deleting a property is as simple as tossing a
new row into the table.
Finding a property by name is a read of the last row in the set of
rows matched by TXN_ID "/" NAME.
Finding all properties for a transaction is a partial key lookup of
TXN_ID "/", keeping only the last value per property name. That
might not scale so well, though, but workarounds exist (add a new
PROPNAMES list to the end of any transaction skels whose PROPS
value is this new special 0-length atom value; get set of props by
doing per-name lookups while iterating over property names.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 16:03:08 2005