On Thu, Jan 20, 2005 at 10:25:55PM -0600, Daniel Goller wrote:
Note: The implementation ideas are just that. Ideas. If you find some structural flaw in them, tell us, don't flame :-)
I have a identified a problem that this will cause... Ok, so we're keeping all old versions of the eclasses to satisfy your proposed plan. This will have a major negative impact on the size of the tree.
Let's focus on a specific example: eutils.eclass, the mainstay of a lot of development. It's currently revision 1.141. Current file size is 42243 bytes. Average file size over those 141 revisions is 28308 bytes. If we had to keep ALL of these 141 revisions, that bloats the tree by 3991553 bytes.
This file is not typical of eclasses, as it's a good deal larger than
many others, and has the most revisions, but it ideal for pointing out
what the end result could be.
I make a rough total for keeping every revision of every ebuild as 15+ MB of data. (Assuming 4kb blocks for files smaller than 4kb).
This is nearly an 18% increase in the size of the tree. We're already trying to get it down (expect my email later today about stuff in files/ violating the 20k goal).
an easy solution would be to not download them on every sync, but on demand, when a ebuild actually needs it, similar to distfiles only being downloaded when needed, and similar to how the discussion went on about keeping large patches out of the tree in a previous thread
also testing more and including many changes in one bump rather than making very many incremental bumps would cut down on revisions needed
test more, commit less to avoid the number of eclass versions to explode
signature.asc
Description: OpenPGP digital signature
