← Back to team overview

launchpad-dev team mailing list archive

Re: Switching dev focus to devel rather than db-devel

 

On Sat, Nov 20, 2010 at 6:39 AM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> On Sat, Nov 20, 2010 at 3:27 AM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:

>>> Is this not still the issue?  db-devel is always going to be a superset
>>> of devel.  Or, is the assumption that we'll have fewer and fewer
>>> landings on db-devel directly for this to be an issue?
>>
>> It's an issue. With our current branch set up, we'll always be facing
>> a trade-off.
>>
>> Note that:
>>  * stacking on devel is not wrong, it is simply slower; proposing to merge to
>>    db-devel is wrong

It was a problem during a period when devel and db-devel differed by
megabytes. Hopefully that won't happen again :-)


> Most of our merges are to devel; stacking on db-devel is only faster
> because its merged up (mostly) with stable, which lags devel by at
> least 4 hours.
>
> a cronjob that does devel.fetch(db_devel) would make pushes of either
> db-devel or devel branches equally efficient. (*)

> *:
> from bzrlib import initialize, plugin, repository
> with initialize():
>    plugin.load_plugins()
>    repository.Repository.open('lp:~launchpad-pqm/launchpad/devel').fetch(
>        repository.Repository.open('lp:~launchpad-pqm/launchpad/db-devel'))


I think I've proposed this before, but I don't think anyone has done
the real calculations. We should not only do what you are proposing
for all stacked branches, but should remove the unnecessary revisions
once they exist in the stacked source branch.

My reasoning is that at the moment, we store every revision at least
twice. Developers work on their local branches, push (creating their
revisions once) and then merge to trunk (creating their revisions a
second time). My pruning unnecessary revisions from a branch that
exist in the stacked on source we half our disk space usage, Depending
on our $/GB, this work might pay for itself immediately as well as
providing future cost savings.


-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/



References