gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/storm article.rst


From: Benja Fallenstein
Subject: [Gzz-commits] manuscripts/storm article.rst
Date: Sat, 15 Feb 2003 11:35:11 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 11:35:10

Modified files:
        storm          : article.rst 

Log message:
        twid

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.169&tr2=1.170&r1=text&r2=text

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.169 manuscripts/storm/article.rst:1.170
--- manuscripts/storm/article.rst:1.169 Sat Feb 15 11:06:53 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 11:35:10 2003
@@ -980,15 +980,15 @@
 
 
 The diff system is more complicated than simple block storage,
-and therefore more liable to bugs. Yet, as long as we do not
-do backward diffing, saving is purely additive: New diffs
+and therefore more liable to bugs. Yet, saving is purely additive: New diffs
 are added, but old diffs aren't changed. Therefore, when a save
 goes wrong, again only the changes after the previous save are lost.
-With backward diffing, we remove the cached full version,
-but we can reconstruct it using the diffs. We believe that
-diff-based Storm storage is still more reliable than file storage,
-where a simple application bug can lose all previous work
-on a document.
+
+.. With backward diffing, we remove the cached full version,
+   but we can reconstruct it using the diffs. We believe that
+   diff-based Storm storage is still more reliable than file storage,
+   where a simple application bug can lose all previous work
+   on a document.
 
 To protect against buggy ``Diff`` or ``VersionFormat``
 implementations, before storing a diff, we always check
@@ -1063,10 +1063,10 @@
    
    Comments may be new entities(?) linking to it
 
-[At the end of this section ? -Hermanni]
-When Xanalogical storage is not applied, using Storm as a
-replacement/equivalent of a conventional file and versioning system is
-trivial?
+   [At the end of this section ? -Hermanni]
+   When Xanalogical storage is not applied, using Storm as a
+   replacement/equivalent of a conventional file and versioning system is
+   trivial?
 
 Besides the selected issues discussed above, a few remarks about further
 evaluation of Storm follow. From a security point of view, the fact that all




reply via email to

[Prev in Thread] Current Thread [Next in Thread]