unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Surely 'bzr update' shouldn't be this slow?  [was: branch]
Date: Thu, 7 Jan 2010 13:40:12 +0000	[thread overview]
Message-ID: <20100107134011.GA2381@muc.de> (raw)
In-Reply-To: <87hbqze39u.fsf@telefonica.net>

Hi, Óscar,

On Wed, Jan 06, 2010 at 03:06:37PM +0100, Óscar Fuentes wrote:
> Jason Rumney <jasonr@gnu.org> 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).




  parent reply	other threads:[~2010-01-07 13:40 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-03 17:47 Surely 'bzr branch' shouldn't be this slow? Alan Mackenzie
2010-01-03 17:59 ` Óscar Fuentes
2010-01-06 13:10   ` Alan Mackenzie
2010-01-06 13:28     ` Jason Rumney
2010-01-06 14:06       ` Óscar Fuentes
2010-01-06 18:23         ` Eli Zaretskii
2010-01-06 20:21           ` Stefan Monnier
2010-01-07  7:44           ` Yavor Doganov
2010-01-07  8:37             ` Lennart Borgman
2010-01-07  9:31               ` Juanma Barranquero
2010-01-07 19:18               ` Stephen Berman
2010-01-07 19:54               ` Eli Zaretskii
2010-01-07 20:09                 ` Lennart Borgman
2010-01-07 21:48                   ` Jason Earl
2010-01-07 23:48                     ` Lennart Borgman
2010-01-08  2:07                       ` Jason Earl
2010-01-08  7:10                         ` Lennart Borgman
2010-01-08  8:13                   ` Eli Zaretskii
2010-01-07 14:46             ` Stefan Monnier
2010-01-07 17:05               ` Yavor Doganov
2010-01-07 19:43                 ` Stefan Monnier
2010-01-07 19:46                   ` Lennart Borgman
2010-01-07 20:26                     ` Thrashing [was: Surely 'bzr branch' shouldn't be this slow?] Stephen J. Turnbull
2010-01-07 20:20                       ` Lennart Borgman
2010-01-07 13:40         ` Alan Mackenzie [this message]
2010-01-07 13:56           ` Surely 'bzr update' shouldn't be this slow? Óscar Fuentes
2010-01-07 14:03             ` Lennart Borgman
2010-01-07 15:18               ` Jan Djärv
2010-01-07 14:52             ` Alan Mackenzie
2010-01-07 15:00               ` Juanma Barranquero
2010-01-07 15:17                 ` Karl Fogel
2010-01-07 17:51                   ` Glenn Morris
2010-01-07 20:48                     ` Karl Fogel
2010-01-07 21:21                       ` Glenn Morris
2010-01-08  8:48                       ` Eli Zaretskii
2010-01-07 15:17               ` Óscar Fuentes
2010-01-07 17:54               ` Stephen J. Turnbull
2010-01-07 15:06           ` Stefan Monnier
2010-01-06 14:37     ` Surely 'bzr branch' " Stefan Monnier
2010-01-07  5:00     ` Karl Fogel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100107134011.GA2381@muc.de \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).