[svnbook commit] r1333 - in trunk/src/en: . book

[sussman]

Author: sussman
Date: Tue May 24 22:59:23 2005
New Revision: 1333

Modified:
   trunk/src/en/TODO
   trunk/src/en/book/ch05.xml
Log:
Tweak chapter 5 txn-cleanup stuff.

* src/en/book/ch05.xml (Repository cleanup):
     Don't say that zombie txns 'consume resources'; be less alarmist.
     Don't mention that dead-txns can result from failed updates; they can't.

* src/en/TODO:  remove item.


Modified: trunk/src/en/TODO
==============================================================================
--- trunk/src/en/TODO	(original)
+++ trunk/src/en/TODO	Tue May 24 22:59:23 2005
@@ -2,17 +2,6 @@
 
 
 ============================================================================
-NEEDED FOR 1.1 COMPLETION
-============================================================================
-
-  * Chapter 5 section "Repository Cleanup" documents the
-    pre-"transactionless reporter" (pre-1.1) state of affairs regarding stale
-    repository transactions.
-    (Whilst fixing, perhaps consider whether the importance of zombie
-    transaction cleanup is being over-stressed?  Perhaps give reassurance that
-    zombie txns do no harm, other than eating a little disk space?)
-
-============================================================================
 NEEDED FOR 1.2 COMPLETION
 ============================================================================
 

Modified: trunk/src/en/book/ch05.xml
==============================================================================
--- trunk/src/en/book/ch05.xml	(original)
+++ trunk/src/en/book/ch05.xml	Tue May 24 22:59:23 2005
@@ -1858,17 +1858,20 @@
 
       <para>Another common use of <command>svnadmin</command> is to
         query the repository for outstanding—possibly
-        dead—Subversion transactions.  In the event that a commit
-        should fail, the transaction is usually cleaned up.  That is,
-        the transaction itself is removed from the repository, and any
-        data associated with (and only with) that transaction is
-        removed as well.  Occasionally, though, a failure occurs in
-        such a way that the cleanup of the transaction never happens.
-        This could happen for several reasons: perhaps the client
-        operation was inelegantly terminated by the user, or a network
-        failure might have occurred in the middle of an operation, etc.
-        Regardless of the reason, these dead transactions serve only
-        to clutter the repository and consume resources.</para>
+        dead—Subversion transactions.  In the event that a
+        commit should fail, the transaction is usually cleaned up.
+        That is, the transaction itself is removed from the
+        repository, and any data associated with (and only with) that
+        transaction is removed as well.  Occasionally, though, a
+        failure occurs in such a way that the cleanup of the
+        transaction never happens.  This could happen for several
+        reasons: perhaps the client operation was inelegantly
+        terminated by the user, or a network failure might have
+        occurred in the middle of an operation, etc.  Regardless of
+        the reason, dead transactions can happen.  They don't do any
+        real harm, other than consuming a small bit of disk space.  A
+        fastidious administrator may nonetheless want to remove
+        them.</para>
 
       <para>You can use <command>svnadmin</command>'s
         <literal>lstxns</literal> command to list the names of the
@@ -1953,17 +1956,11 @@
 $
 </screen>
 
-      <para>Usually, if you see a dead transaction that has no log
-        message attached to it, this is the result of a failed update
-        (or update-like) operation.  These operations use Subversion
-        transactions under the hood to mimic working copy state.
-        Since they are never intended to be committed, Subversion
-        doesn't require a log message for those transactions.
-        Transactions that do have log messages attached are almost
-        certainly failed commits of some sort.  Also, a transaction's
-        datestamp can provide interesting information—for
-        example, how likely is it that an operation begun nine months
-        ago is still active?</para>
+      <para>An long-abandoned transaction usually represents some sort
+        of failed or interrupted commit.  A transaction's datestamp
+        can provide interesting information—for example, how
+        likely is it that an operation begun nine months ago is still
+        active?</para>
 
       <para>In short, transaction cleanup decisions need not be made
         unwisely.  Various sources of information—including