attached mail follows:
hey guys.
I've been a sleep at the wheel of some other chit.
Where is the thread that discusses the "paths that changed thingy". What is the
issue there?
gat
cmpilato@collab.net wrote:
> While talking about the whole "changed paths being stored as a
> revision property" thing with Ben and Karl, a thought occured to me
> that I think is utter goodness.
>
> Currently, our revisions table stores:
>
> - a "revision" header
> - the root node revision id for the tree in that revision
> - a property list
> - a transaction id (key into the `transactions' table)
>
> Our transaction table stores two different types of records. An
> uncommitted transaction has:
>
> - 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 property list
> - a list of copy ids for copies made during the transaction
>
> Committed trasactions have:
>
> - a "committed" header
> - the revision that was created by committing the transaction
>
> Committed transactions are basically just key maps from the
> transactions table to the revisions table. But note the amount of
> overlap in uncommitted transactions and revisions.
>
> --
>
> Here's what I'm proposing:
>
> REVISION:
>
> - 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
>
> --
>
> 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?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 14 18:15:38 2002