Fix some typos & bad URLs

1 files changed, 16 insertions, 16 deletions

diff --git a/README.BINREPO b/README.BINREPO
index 5063b17..bc4c0d4 100644
--- a/README.BINREPO
+++ b/README.BINREPO
@@ -40,14 +40,14 @@ survive.  Thus another mechanism which relies on dates instead of revisions
 numbers is needed.
 
 When a binary is uploaded to the binrepo, the file `sha1.lst` is updated to
-have the files's hash and commited in the main text repo. This file will be
+have the files's hash and committed in the main text repo. This file will be
 used as the reference when the user uses -r REV on mgarepo. mgarepo will
 checkout the package in the main text repo with -r REV and then will use
 the "Last Changed Date" of `sha1.lst` to checkout the binrepo part. Thus,
-`sha1.lst` should be always commited to the main text repository *after* the
-corresponding binary files have been commited to the binrepo. Hooks in the
+`sha1.lst` should be always committed to the main text repository *after* the
+corresponding binary files have been committed to the binrepo. Hooks in the
 main repository may be used to try to enforce this, by checking if the files
-changed in `sha1.lst` are already commited in the corresponding binrepo.
+changed in `sha1.lst` are already committed in the corresponding binrepo.
 
 Computation of `sha1.lst` is unlikely to be an issue:
 
@@ -55,8 +55,8 @@ Computation of `sha1.lst` is unlikely to be an issue:
 - it takes[0] less than 10s to sha1sum all SOURCES of openoffice.org-3.1-1mdv2010.0.src.rpm
 - it probably takes way less than the time to upload the file into the repository
 - it can be computed in parallel to the binrepo commit, and probably finish
-  before that, thus ready by the time `sha1.lst` should be commited
-- users don't need to verify the SHA1s "everytime", but the build system
+  before that, thus ready by the time `sha1.lst` should be committed
+- users don't need to verify the SHA1s "every time", but the build system
   does, thus Repsys can default to not verify and avoid wasting users' time
 
 The use of `sha1.lst` has the valuable property of tying the state of the main
@@ -82,11 +82,11 @@ property in the main text repository would be kept, such that for any given
 main repository revision, the corresponding state of the binrepos is
 obtainable (using the registered date).
 
-This would be "more transparent", as it can be maintened simply by using
+This would be "more transparent", as it can be maintained simply by using
 subversion hooks, without user intervention.  OTOH, as every time the user
 commits to a binrepo this would result in a commit in the main repository,
 it would require the user to "svn up" the directories from there before
-commiting, after every binrepo commit.  Also, this might result in a big
+committing, after every binrepo commit.  Also, this might result in a big
 number of "bogus" commits to the main repository, which could be seen as log
 pollution, and may potentially increase space usage etc..
 
@@ -101,14 +101,14 @@ Why a new repository without the tarballs
   failure very expensive, much more so than the more valuable data
 - there is no easy way to strip undesired tarballs without recreating the
   whole repository
-- fedora and ubuntu have separated repositories, so we must have it too!
+- Fedora and Ubuntu have separated repositories, so we must have it too!
 
 Numbers
 -------
 
-Current repository is +390000 revisions and ~340Gb big, while the bzip2ed
+Circa 2011 repository is +390000 revisions and ~340Gb big, while the bzip2ed
 dumps backup for it takes about a bit more than half that size (FIXME:
-estimative, can't check in the backup server right now).  Current txtrepo
+estimate; can't check in the backup server right now).  Current txtrepo
 with the same number of revisions is ~180Gb big, takes about 2-3 days to be
 imported, while the gzipped full dump backup for it currently takes ~1.2Gb. 
 Initial binrepo for cauldron (only `current/` packages' branches) took ~28Gb
@@ -137,8 +137,8 @@ We would have to update the configuration files from all the users in order
 to add a new stable repository. spuk suggests to use properties in the main
 text repo that would point to the right repository locations.
 
-How to handle failures when operating on more repositores?
-----------------------------------------------------------
+How to handle failures when operating on more repositories?
+-----------------------------------------------------------
 
 binrepos should replicate the structure of the main text repo. What we
 should do if the markrelease succeeds in the binrepo, but fails in the main
@@ -155,7 +155,7 @@ would work like:
 
 0. mark beginning of markrelease, early failing the package build if it fails
 1. do markrelease
-2. mark sucessful end of markrelease
+2. mark successful end of markrelease
    or mark failed markrelease, so we can replay it later
 
 
@@ -207,7 +207,7 @@ upgrading to a newer version of the package
 ::
 
   $ cd bla/SOURCES/
-  $ wget http://prdownloads.sourceforge.net/bla/bla-1.6.tar.bz2
+  $ wget https://prdownloads.sourceforge.net/bla/bla-1.6.tar.bz2
   $ mgarepo upload bla-1.6.0.tar.bz2
 
 - mgarepo notices this is a tarball (checking filename and/or file size)
@@ -342,7 +342,7 @@ assuming repository manipulation with mgarepo (for ease).  Repsys could
 xdelta tarballs and add it to SVN with a special filename, then use it when
 checking out.  Would require a policy/algorithm on when to ditch old whole
 binaries, too (i.e.  hopefully wouldn't need to be handled manually by the
-maintainer).  Also, this is something complemental to splitting the
+maintainer).  Also, this is something complementary to splitting the
 repository, so we may do it later, for binrepos.