diff options
Diffstat (limited to 'README.BINREPO')
| -rw-r--r-- | README.BINREPO | 32 |
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. |