[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] few of my learnings and typo fixes to subversion/libsvn_fs_base/notes

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-03-16 14:08:23 CET

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

This is an archived mail posted to the Subversion Dev mailing list.