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.
Find my updated 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'
Removed redundant line on Merge Algorithm.
* 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)
@@ -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.
@@ -668,8 +677,6 @@
If SOURCE-ENTRY and TARGET-ENTRY are both null, that's a
double delete; flag a conflict.
- If any of the three entries is of type file, declare a conflict.
-
If either SOURCE-ENTRY or TARGET-ENTRY is not a direct
modification of ANCESTOR-ENTRY (determine by comparing the
node-id fields), declare a conflict. A replacement is
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 20 13:33:59 2006