--- a/Hg.txt	Fri Mar 06 21:17:07 2009 +0000
+++ b/Hg.txt	Tue Mar 31 12:09:11 2009 +0100
@@ -75,8 +75,8 @@
 
 o Speed. Mercurial is fast. In the same ballpark as Git. Bazaar
 wasn't, and although it has improved significantly, has, in my
-estimation, added user complexity in the process, and is still off the
-pace for some operations.
+estimation, added user complexity in the process, and at the time
+of writing is still off the pace for some operations.
 
 o Documentation. At the time, Bryan O'Sullivan's excellent Mercurial
 book (http://hgbook.red-bean.com) was a clear winner for best
@@ -198,7 +198,7 @@
 that you can't record an empty directory in your repository.
 
 (Footnote: I tripped over this converting a work Subversion
-repository. One possibility is to create a placemaker file in the
+repository. One possibility is to create a placeholder file in the
 directory. In the event I created the directory (which receives build
 products) as part of the build instead.)
 
@@ -305,7 +305,7 @@
 revision plus your change. Perhaps that's what Mercurial did?
 
 No. What Mercurial did is central to Mercurial's view of the
-world. You took your working copy back to an old changeset, and the
+world. You took your working copy back to an old changeset, and then
 committed a fresh change based at that changeset. Mercurial actually
 did just what you asked it to do, no more and no less. Let's see the
 initial evidence.
@@ -486,9 +486,9 @@
 answer'.  I found the explanation helpful, so this section attempts
 the 10,000ft (FL100 if you prefer) view of Mercurial.
 
-(Foornote: Bryan O'Sullivan's excellent Mercurial book has a chapter
-on the subject, and the Mercurial website has a fair amount of detail
-too. This is 'research', OK?)
+(Foornote: For the curious, Bryan O'Sullivan's excellent Mercurial book
+has a chapter on the subject, and the Mercurial website has a fair amount
+of detail too.)
 
 First remember that any file or component can only have one or two
 parents. You can't merge more than one other branch at once.
@@ -634,15 +634,16 @@
 distributed manner, with full history and the ability to commit being
 available locally.
 
-I want now to reflect on the consequences all this has for that
-all-important question of whether a DVCS is a suitable vehicle for
-your data.
+So instead of chatter on about workflows, I want instead to reflect on
+the consequences all this has for that all-important question of
+whether a DVCS is a suitable vehicle for your data.
 
 The first is a minor and rather obvious point. If you want to store
-files that are both very large and which change often in your DVCS,
-then all the compression in the world is unlikely to stop the storage
-requirements for the full project history from becoming
-uncomfortably large.
+files that are very large and which change often in your DVCS, then
+all the compression in the world is unlikely to stop the storage
+requirements for the full project history from becoming uncomfortably
+large, particularly if the files are not very compressible to start
+with.
 
 The second, and main, point is that there is an important question you
 need to ask about your data. We've seen that a DVCS relies on