[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "witty subject line about logging feature"

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-07-25 15:58:59 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.