From: Evan Broder 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 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.