Hi All,
This patch is a superset of my yet to be commited patch on '1 to many
relationship of representation to strings'. It has few other learnings I
had while reading this subversion/libsvn_fs_base/notes/structure doc and
2 typo fixes.
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.
Typo fix 'epheremal' to 'ephemeral'
Incorporated few other learnings.
* subversion/libsvn_fs_base/notes/fs-history
Typo fix 'heirarchical' to 'hierarchical'.
]]]
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.
KIND-SPECIFIC varies considerably depending on the kind of
representation. Here are the two forms currently recognized:
@@ -373,17 +374,21 @@
etc.
Representations never share strings. Every string is represented by
-exactly one representation; every representation represents exactly
+exactly one representation; every 'fulltext' representation represents 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 represent 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
+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.
+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
@@ -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.
* PROPLIST is a skel giving the revision properties for the
transaction.
@@ -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.
* CHANGE-KIND is one of the following:
@@ -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.
+
In order to fully describe the changes made to any given path as part
of a single transaction, one must read all the change items associated
with the transaction's ID, and "collapse" multiple entries that refer
@@ -617,7 +630,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.
Index: subversion/libsvn_fs_base/notes/fs-history
===================================================================
--- subversion/libsvn_fs_base/notes/fs-history (revision 18907)
+++ subversion/libsvn_fs_base/notes/fs-history (working copy)
@@ -29,7 +29,7 @@
their versioned resources in terms of the paths of those resources,
and the global revisions (or revisions-to-be) in which those paths
are located. But inside the filesystem, paths are broken down and
-stored as a heirarchical linked-list of path components. Each of
+stored as a hierarchical linked-list of path components. Each of
these path components has its own historical lineage (because
Subversion versions directories, too!), and each revision of that
lineage is referred to as a "node-revision". It is these
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 16 14:09:12 2006