← Back to team overview

launchpad-dev team mailing list archive

Re: [Branch ~launchpad-pqm/launchpad/devel] Rev 9943: [r=gary][ui=none] change our sourcecode script to honor revisions;

 

Aaron Bentley wrote:
> 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.

Wouldn't taking full advantage of our VCS involve unpacking the tarball,
so you can use diff, log on individual files, etc.?

Which nicely leads into...

What if we went to sourcecode branches for anything we patch at all
*but* we built eggs from them?

This would require some care in ensuring the internal version numbers
were bumped such that the eggs had appropriate versions in their names,
and might require some interesting mapping to pull the right rev-id for
a given build, *but* would allow us to have eggs, rather than a web of
symlinks whilst still retaining full usage of bzr to branch from
upstream and apply patches in an obvious, visible, browseable manner.

> 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.

> We could even extract the tarballs-- AIUI directories are
> acceptable eggs.

Do you mean "acceptable sourcedists to use to build eggs"? Interesting.
I think I like the idea, but I think I like putting each distinct
project into its own branch more.

Max.

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References