Changeset 2870 for trunk/packages

Timestamp:

Jan 10, 2010, 2:53:58 AM (15 years ago)

Author:

broder

Message:

I can spell, I promise.

File:

• trunk/packages/invirt-dev/README.invirtibuilder (modified) (5 diffs)

trunk/packages/invirt-dev/README.invirtibuilder

@@ -27 +27 @@
   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.
@@ -93 +93 @@
 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::
 
@@ -173 +173 @@
 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.
@@ -186 +186 @@
 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.
 
@@ -297 +297 @@
 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.