On Fri, Jun 14, 2002 at 10:59:41AM -0500, firstname.lastname@example.org wrote:
> Here's what I'm proposing:
> - a "revision" header
> - a transaction id (key into the `transactions' table)
> UNFINISHED TRANSACTION:
> - a "transaction" header
> - the root note revision id for the tree in that transaction
> - the root node revision id for the tree in the revision on which its based
> - a transaction property list
> - paths that were changed in this transaction
> - a list of copy ids for copies made during the transaction
> COMMITTED TRANSACTION:
> - a "committed" header
> - the root node revision id for the tree that was committed
> - a revision property list
> - paths that were changed in this revision
> - the revision that was created by committing the transaction
Are the prop list and set of paths stored in the strings tables? (maybe the
prop list would actually be a rep-key?) Since those can be arbitrary length,
it would seem we don't want them right in the skel. Taking a paragraph from
Some parts of a node revision are essentially constant-length: for
example, the KIND field and the REV. Other parts can have
arbitrarily varying length: property lists, file contents, and
directory entry lists. This variable-length data is often similar
from one revision to the next, so Subversion stores just the deltas
between them, instead of successive fulltexts.
and makes the code more efficient, because Subversion can retrieve
just the parts of a node it needs for a given operation.
While we probably won't deltify the proplist and certainly not the paths,
storing them outside the skel could be Goodness(tm).
> Why? Well, at commit time, we currently copy all the txn properties
> into the new revision-to-be, and if we do the paths-changed stuff,
> we'll be copying those as well. It just makes more sense (and wastes
> fewer fields in the svn_fs__transaction_t structure) to keep this kind
> of information in the transactions table, and make Revisions have the
> really small key-map.
> Thots? I'm betting that Bill Tutt and Brane are +1, yes?
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 14 21:32:35 2002