emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Surely 'bzr update' shouldn't be this slow? [was: branch]


From: Alan Mackenzie
Subject: Re: Surely 'bzr update' shouldn't be this slow? [was: branch]
Date: Thu, 7 Jan 2010 13:40:12 +0000
User-agent: Mutt/1.5.9i

Hi, Óscar,

On Wed, Jan 06, 2010 at 03:06:37PM +0100, Óscar Fuentes wrote:
> Jason Rumney <address@hidden> writes:

> > Alan Mackenzie wrote:

> >>>> Having created a local copy of the bzr repository in my directory
> >>>> ~/emacs/emacs.bzr/trunk, I then went to create the now familiar
> >>>> quickfixes branch from it, with this command:



> >>>>     $ time bzr branch emacs.bzr/trunk/ quickfixes/


> >> Ah, right.  The .../quickfixes/ needs to be physically under
> >> .../trunk, not just "related" to it.  Thanks!


> > I fear you may be heading for another 39 minute wait now.  quickfixes
> > needs to be under emacs/emacs.bzr, alongside trunk/, not under it.

Thanks!  Did that, and it took 33 seconds.  That's OK.

> As far as the directories containing the branches are under the
> directory that acts as the shared repository, you will benefit from the
> fast operations the shared branch brings in. You can move and rename
> branches within the shared repository (as long as they are not
> referenced by other branches: if you work with the recommended
> decentralized workflow, renaming `trunk' will require some tweaking on
> the other branches.)

OK.  Hopefully the other branches are referred to via a relative path
rather than an absolute one.

> 39 minutes for branching outside the shared repository corresponds to a
> slow machine. It is 10 minutes on a GNU/Linux 2.4 GHz 64 bits
> worksation-class machine. Bazaar is no speed daemon, but in this case it
> has to process more than 200 MB of data (not merely copying it around.)

I beg your pardon?  My machine is a 1.2 GHz Athlon.  That is NOT a slow
machine by any measure, except that even faster machines are now common.
Why does Bazaar need to "process" this data?  It's essentially doing
copying, with some accompanying administrivia.  Is it doing heavy number
crunching in Python, when it really needs a C module, or something like
that?

I just did a 'bzr update' on my .../trunk.  It took 23 minutes,
transferring nearly 200Mb to/from savannah in the process.  This compares
with all our source files (.c, .h, .el) being ~64Mb.  Could it be that
'bzr update' just downloads the whole repository again?  Or has somebody
else raised this issue on another thread that I've missed?

There seems to be a substantial mismatch between the assumptions of the
bzr project and the realities of the Emacs project.  My impression is
that bzr is so slow as to be barely usable at the moment.

> -- 
> Óscar

-- 
Alan Mackenzie (Nuremberg, Germany).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]