aboutsummaryrefslogtreecommitdiffstats
path: root/README.BINREPO
diff options
context:
space:
mode:
Diffstat (limited to 'README.BINREPO')
-rw-r--r--README.BINREPO32
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.