--- a/Hg.tex	Fri May 22 11:04:47 2009 +0100
+++ b/Hg.tex	Fri May 22 21:14:57 2009 +0100
@@ -50,7 +50,7 @@
 offering funky new stuff. These are the distributed version control
 systems (DVCS). There is more to them than just their headline
 attributes, being able to check history and do checkins while
-disconnected from a central server, but these are damm useful to start
+disconnected from a central server, but these are damn useful to start
 with.
 
 When I first heard about DVCS, it wasn't immediately obvious to me (to
@@ -513,10 +513,10 @@
 In practice this is more manageable then you might think. Consider a
 typical Mercurial usage, where the 'master' repo sits on a known
 server, and everyone pulls changes from the master and pushes their
-own efforts to the master. But default Mercurial won't let you push if
+own efforts to the master. By default Mercurial won't let you push if
 the receiving repo will gain an extra head as a result, so you
 typically pull (and do any required merging) just before
-pushing. Subversion users will recognised this pattern. Subversion
+pushing. Subversion users will recognise this pattern. Subversion
 won't let you commit a change if your working copy is not at the very
 latest revision, so the Subversion user will update, and merge if
 necessary, just before committing.
@@ -661,7 +661,7 @@
 applied.
 
 The Mercurial revlog format has proved remarkably durable. Since the
-first release of Mercurial in April 2005, these have been a total of 5
+first release of Mercurial in April 2005, there have been a total of 5
 changes to the file format. However, of those, all but one have been
 changes to the handling of file names. The most recent change, in
 October 2008, and its predecessor in December 2006, were both
@@ -686,7 +686,7 @@
 parallel. Mercurial treats these branches as arising naturally from
 the commits made and transferred between repositories. Both Git and
 Bazaar take a slightly different viewpoint, and explicitly generate a
-fresh branch for work in a particular repositories. But in both cases
+fresh branch for work in a particular repository. But in both cases
 the underlying principle of identifying changes by a globally unique
 identifier and resolving parallel development by merges between
 overlapping changes is the same. And all three can be used in a truly