launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Hudson wrote:
> noreply@xxxxxxxxxxxxx wrote:
>>   [r=gary][ui=none] change our sourcecode script to honor revisions;
>>   	change our sourcecode list to include revisions.
> 
> Yay.  I wonder if we should go back to this for bzr, specifically.
> Using releases is great and all, but we're so tightly bound to this
> particular project and committing a 5 meg tarball for each patch we find
> ourselves needing for it doesn't seem sane.

I agree that committing a 5 meg tarball for each patch we find ourselves
committing doesn't seem sane.  But I think that bzr is only an extreme
case of a problem that affects the current download-cache design.

It is strange to have a branch to which you only ever add files.  Why
not make that an rsyncable location instead?  That would give people a
chance to avoid downloading irrelevant tarballs.  Is it just that we've
got lots of tools for managing branches and few tools for managing
rsyncable locations?

Better yet, why not take proper advantage of our VCS?  If we stored
ungzipped tars, the incremental cost of adding a tarball could be quite
low, because bzr would be able to groupcompress the tarball against the
previous version.

And ultimately, what if we had only a single copy of each package in a
given revision?  Then the versions.cfg could be replaced with a single
revision-id.  We could even extract the tarballs-- AIUI directories are
acceptable eggs.

The current setup has higher friction than I think we want, and
ultimately it won't scale.  There's by no means a crisis, but I'm about
to do another bzr patch...

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksP//QACgkQ0F+nu1YWqI2x2ACggsZJjPrSLjxuib82N3st1L6y
I8UAnRlMwR3Pyze/snrtud9CSEUsV26g
=jcni
-----END PGP SIGNATURE-----