Gentoo Archives: gentoo-dev

From: Harley Peters <harley@×××××××××××××.net>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Problems with the current bzr eclass.
Date: Thu, 09 Jul 2009 21:07:47
In Reply to: [gentoo-dev] Re: Problems with the current bzr eclass. by Christian Faulhammer
On Thu, 9 Jul 2009 22:16:34 +0200
Christian Faulhammer <fauli@g.o> wrote:

> Hi, > > Harley Peters <harley@×××××××××××××.net>: > > Ok that's what I am doing. Was just wondering if there was something > > simple I over looked. > > To give you an idea what we gain here, I compiled some numbers. GNU > Emacs live ebuild (app-editors/emacs-cvs) will be the biggest consumer > once they switch from CVS. > > First we will compare timings > > $ time bzr checkout --lightweight > real 7m37.044s > user 1m2.789s > sys 0m2.807s > > $ time bzr checkout > > real 40m47.371s > user 3m57.881s > sys 0m8.586s > > So the normal initial checkout will be more than five times slower > than the lightweight one. If this were 1s to 6s it would be > neglectable, but we are talking about half an hour difference just > for an emerge. > > Next ist the update function. > > $ time bzr update > > real 0m11.457s > user 0m0.544s > sys 0m0.092s > > $ time bzr update > > real 0m2.710s > user 0m0.237s > sys 0m0.053s > > Clearly the normal checkout wins by factor five, but we are in the > second range, while the space gain is enormous: > > $ du -sch Emacs-lw/ Emacs > 106M Emacs-lw/ > 427M Emacs > 533M total > > V-Li >
I understand why you did it. I just need a way to prevent it from deleting a full checkout. Because the numbers don't look so good for Gnash. bzr branch Having said that it's only a two line change to the bzr.eclass code to get it to work the way I want. And I can live with that. :)


Subject Author
[gentoo-dev] Re: Problems with the current bzr eclass. Christian Faulhammer <fauli@g.o>