I was not aware that the algorithm is 'Directory Merging Algorithm'.
Just changed the section header from 'Merging Algorithm' to 'Directory
Merging Algorithm' along with other changes.
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'
Changed the header from 'Merging Algorithm' to 'Directory Merging
Algorithm'.
* subversion/libsvn_fs_base/notes/fs-history
Typo fix 'heirarchical' to 'hierarchical'.
]]]
C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>
>> Hi All,
>> In subversion/libsvn_fs_base/notes/structure : Merging Algorithm section
>> I could see the following line
>> "If any of the three entries is of type file, declare a conflict." . I
>> think it does not make sense.
>> I think the next statement should be enough.
>>
>
> The merging algorithm is a *directory* merging algorithm. If asked to
> perform a directory merging algorithm on inputs that are not all
> directories, something is wrong, and yes, the code will declare a conflict.
> The text as written is correct, and should not be removed.
>
>
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.
@@ -643,7 +652,7 @@
The general principle: a series of changes can be merged iff the
final outcome is independent of the order you apply them in.
-Merging algorithm:
+Directory Merging algorithm:
For each entry NAME in the directory ANCESTOR:
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 Wed Mar 22 06:21:12 2006