From: Evan Broder <broder@mit.edu>
Date: Sun, 10 Jan 2010 07:53:58 +0000 (-0500)
Subject: I can spell, I promise.
X-Git-Tag: 0.1.5~23
X-Git-Url: http://xvm.mit.edu/gitweb/invirt/packages/invirt-dev.git/commitdiff_plain/8159e20cfdef0e6690d85821274b0720ac0773de?ds=sidebyside

I can spell, I promise.

svn path=/trunk/packages/invirt-dev/; revision=2870
---

diff --git a/README.invirtibuilder b/README.invirtibuilder
index 0a853bf..a60c2e9 100644
--- a/README.invirtibuilder
+++ b/README.invirtibuilder
@@ -26,10 +26,10 @@ design of the Invirtibuilder:
 
   Because of how Git tracks history, it's better suited for tracking a
   series of small repositories, as opposed to one large one
-  [#]_. Furthermore, most pre-existing tools and techniques for
-  dealing with Debian packages in Git repositories (such as
-  git-buildpackage_ or `VCS location information`_) are designed
-  exclusively for this case.
+  [#]_. Furthermore, most preexisting tools and techniques for dealing
+  with Debian packages in Git repositories (such as git-buildpackage_
+  or `VCS location information`_) are designed exclusively for this
+  case.
 
 * Synchronization between Git and APT repositories.
 
@@ -92,7 +92,7 @@ Configuration
 
 For the Invirt_ project's use of the Invirtibuilder, we adapted our
 existing configuration mechanism. Our configuration file consists of a
-singls YAML_ file. Here is the snippet of configuration we use for our
+single YAML_ file. Here is the snippet of configuration we use for our
 build configuration::
 
  build:
@@ -172,7 +172,7 @@ We considered several ways to trigger builds of new package versions
 using Git directly. However, we realized that what we actually wanted
 was a separate build queue where each build request was handled and
 processed independently of any requests before or after it. It's not
-possible to have these semantics using Git as a signalling mechanism
+possible to have these semantics using Git as a signaling mechanism
 without breaking standard assumptions about how remote Git
 repositories work.
 
@@ -185,7 +185,7 @@ server with a pocket, a package, and a commit ID from that package's
 Git repository. The remctl daemon then calls a script which validates
 the build and adds it to the build queue. Because of the structure of
 remctl's ACLs, we are able to have different ACLs depending on which
-pocket the build is destined for. This allows us to fulfil our design
+pocket the build is destined for. This allows us to fulfill our design
 goal of having different ACLs for different pockets.
 
 For simplicity, the queue itself is maintained as a directory of
@@ -296,7 +296,7 @@ As noted above, our intent was for a single instance of the
 Invirtibuilder to be used for both our trusted production environment
 and our untrusted development environment. In order to be trusted for
 the production environment, the Invirtibuilder needs to run in the
-production environment as well. However, it would be disasterous if
+production environment as well. However, it would be disastrous if
 access to the development environment allowed a developer to insert
 malicious packages into the production apt repository.