Hi Mike,
Thanks for the review.
Find the attached patch.
With regards
Kamesh Jayachandran
[[[
Incorporated few other learnings and typo fixes.
Patch by: Kamesh Jayachandran <kamesh@collab.net>
* subversion/libsvn_fs_base/notes/structure
'fulltext' representation has 1 to 1 relationship with strings.
'delta' representation has 1 to many relationship with strings.
Few learnings on 'deltification'.
Few learnings on format of 'ROOT-ID' and 'BASE-ID'
Few learnings on ID field of changes skeleton.
Typo fix 'epheremal' to 'ephemeral'
* subversion/libsvn_fs_base/notes/fs-history
Typo fix 'heirarchical' to 'hierarchical'.
]]]
C. Michael Pilato wrote:
> 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.
>
>
>
Index: subversion/libsvn_fs_base/notes/structure
===================================================================
--- subversion/libsvn_fs_base/notes/structure (revision 18907)
+++ subversion/libsvn_fs_base/notes/structure (working copy)
@@ -373,22 +373,25 @@
etc.
Representations never share strings. Every string is represented by
-exactly one representation; every representation represents exactly
+exactly one representation; every 'fulltext' representation refers exactly
one string. This is so we can replace a string with deltified version
of itself, change the representation referring to it, and know that
-we're not messing up any other reps by doing so.
+we're not messing up any other reps by doing so. The 'delta' representation
+can refer more than one string depending on the size of the delta.
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
-representation will not be changed; instead, the same rep key will now
-be associated with different value. That way, we get reader locking
-for free: if someone is reading a file while Subversion is deltifying
-that file, one of the two sides will get a DB_DEADLOCK and
-svn_fs__retry_txn() will retry.
+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 these new string entries
+and the original 'fulltext' string entry will be deleted.
+The node revision referring to that representation will not be changed;
+instead, the same rep key will now be associated with different value.
+That way, we get reader locking for free: if someone is reading a file
+while Subversion is deltifying that file, one of the two sides will get
+a DB_DEADLOCK and svn_fs__retry_txn() will retry.
### todo: add a note about cycle-checking here, too.
@@ -451,10 +454,12 @@
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.BASE_REV_TXN,
+ where BASE_REV_TXN is the transaction associated with the revision
+ on which this transaction is based.
* PROPLIST is a skel giving the revision properties for the
transaction.
@@ -516,6 +521,10 @@
* ID is the node revision ID of the node changed (may be a zero
atom, but only in the "reset" kind case).
+ The "delete" operation won't lead to a new node revision unlike
+ "add" and "modify" operations. So "delete" kind will have a ID as the
+ node revision id of the node getting deleted which had been
+ created in the past transaction.
* CHANGE-KIND is one of the following:
@@ -617,7 +626,7 @@
then at least one of the directory's children is locked, and thus the
directory cannot be deleted without further investigation.
-Locks are epheremal things, not historied in any way. They are
+Locks are ephemeral things, not historied in any way. They are
potentially created and deleted quite often. When a lock is
destroyed, the appropriate row is removed from the `locks' table.
Additionally, the locked-path is removed from the `lock-tokens' table.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 17 11:22:37 2006