[svnbook commit] r1333 - in trunk/src/en: . book
svnbook-dev at red-bean.com
Tue May 24 22:59:24 CDT 2005
Date: Tue May 24 22:59:23 2005
New Revision: 1333
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.
--- 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
--- 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
<para>You can use <command>svnadmin</command>'s
<literal>lstxns</literal> command to list the names of the
@@ -1953,17 +1956,11 @@
- <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
<para>In short, transaction cleanup decisions need not be made
unwisely. Various sources of information—including
More information about the svnbook-dev