Kamesh Jayachandran wrote:
> Index: subversion/libsvn_fs_base/notes/structure
> ===================================================================
> --- subversion/libsvn_fs_base/notes/structure (revision 18907)
> +++ subversion/libsvn_fs_base/notes/structure (working copy)
> @@ -274,6 +274,7 @@
> changing what the rep's consumer sees. Switching a representation's
> storage strategy, for example from fulltext to deltified, wouldn't
> count as a change, since that wouldn't affect what the rep produces.
> +The TXN for "delta" kind is 0.
This fact is not a requirement of the schema, but a detail of the way the
code happens to work today. I'm not sure it should be placed into structure
without qualification of that fact.
> Further Notes On Deltifying:
> ----------------------------
>
> -When a representation is deltified, it is changed in place, along with
> -its underlying string. That is, the node revision referring to that
> +When a representation is deltified, it is changed in place.
> +New delta string entries will be added to the 'strings' table,
> +the representation entry will be updated to refer this new string entries
> +and original 'fulltext' string entry will be deleted.
... *these* new string entries, and *the* original 'fulltext'...
> +That is, the node revision referring to that
Also, lose the "That is, " from this line.
> @@ -451,10 +456,10 @@
> where:
>
> * ROOT-ID is the node revision ID of the transaction's root
> - directory.
> + directory. This always happens to be of form 0.0.TXN.
>
> * BASE-ID is the node revision ID of the root of the transaction's
> - base revision.
> + base revision. This always happens to be of form 0.0.LAST_SUCCESSFUL_TXN.
LAST_SUCCESSFUL_TXN is ambiguous without the definition of a "successful
txn", and still wouldn't be quite right with it. Suggest (in addition to
keep two spaces between the end of one sentence and the beginning of another):
This always happens to be of form 0.0.BASE_REV_TXN, where BASE_REV_TXN is
the transaction associated with the revision on which this transaction
is based.
> @@ -516,6 +521,9 @@
>
> * ID is the node revision ID of the node changed (may be a zero
> atom, but only in the "reset" kind case).
> + For 'rm' and 'rename', the ID corresponds to node revision id of node
> + getting removed which won't be the new node revision id as the case with
> + 'add' and 'modify' rather the existing id that is getting deleted.
I think your added sentence creates more confusion than it resolves, likely
stemming from lacking punctuation. Also, there is no 'rm' change kind;
there is no 'rename' change kind -- in general, you are not permitted to
speak about Subversion command-line client operations in a database schema
write-up.
> @@ -531,6 +539,11 @@
> * PROP-MOD is a bit specifying whether or not the properties of
> this node where modified.
>
> + * TEXT-MOD and PROP-MOD are mutually exclusive for a given record.
> + If a node has both text and property changes in a given commit,
> + both would be represented as two different records for the same
> + transaction.
> +
This is not true for the schema. Yes, it happens to be the case that
current code lines won't set both of these flags at the same time, but the
schema does not demand this, and our code *could* start doing that if the
occasion presented itself.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Mar 16 16:48:55 2006