On Thu, 9 Jul 2009 22:16:34 +0200
Christian Faulhammer <fauli@g.o> wrote:

> Hi,
> 
> Harley Peters <harley@...>:
> > 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. :)