On Thu, 9 Jul 2009 22:16:34 +0200 Christian Faulhammer <fa...@gentoo.org> wrote:
> Hi, > > Harley Peters <har...@thepetersclan.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 http://bzr.savannah.gnu.org/r/gnash/trunk 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. :)
