launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

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

Max Bowsher wrote:
> Aaron Bentley wrote:
>> 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.
> 
> Wouldn't taking full advantage of our VCS involve unpacking the tarball,
> so you can use diff, log on individual files, etc.?

See below.

> Which nicely leads into...
> 
> What if we went to sourcecode branches for anything we patch at all
> *but* we built eggs from them?

I don't know what you mean.  We already create branches on launchpad
like lp:~launchpad/bzr/2.0.0-lp whenever we have to patch, and then we
make distribution tarballs out of them.  Is that what you mean?

>> 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.
> 
> A caveat: we'd have to branch lp-source-dependencies for every launchpad
> branch with differing dependency requirements.

No, we can just pull to whatever revision we need.  Maybe not even that.
 Depends on how good our tool support is.

>> We could even extract the tarballs-- AIUI directories are
>> acceptable eggs.
> 
> Do you mean "acceptable sourcedists to use to build eggs"?

Well, I actually meant they were acceptable eggs-- all the contents of
my eggs subdir are directories with names like
zope.principalannotation-3.6.0-py2.5.egg, and I assumed we could just
reuse directories like that, because it's worked with ez_install for me.
 Today's experimentation shows buildout is a lot less directory-friendly
than I was hoping.

> Interesting.
> I think I like the idea, but I think I like putting each distinct
> project into its own branch more.

IMO, that's too slow, because you have to scan each branch to see if
it's changed, and mostly they won't have changed.  I think a single
point of coordination is much easier to cope with.

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

iEYEARECAAYFAksQR4AACgkQ0F+nu1YWqI1t1gCeO+pI8eMiY3xjpbr2a7J12kf6
mqsAn2gjl0D3A46PU7UDivBfKTaEUZqp
=PmQH
-----END PGP SIGNATURE-----