From: Lennart Borgman <lennart.borgman@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Surely 'bzr branch' shouldn't be this slow?
Date: Thu, 7 Jan 2010 09:37:15 +0100 [thread overview]
Message-ID: <e01d8a51001070037sbe1a5efre7e48c1043ba1188@mail.gmail.com> (raw)
In-Reply-To: <87d41m740k.GNU's_Not_Unix!%yavor@gnu.org>
On Thu, Jan 7, 2010 at 8:44 AM, Yavor Doganov <yavor@gnu.org> wrote:
> Eli Zaretskii wrote:
>> I don't think the time it takes to make the original branch (or a
>> branch outside the shared repo) is CPU-bound.
>
> It certainly is! I've been fighting for 3 days now to branch on one
> of my most powerful machines at home (AMD Duron 1.3 GHz, 500 MB RAM)
> without success, and I gave up today. Both sftp/http methods get
> stuck around 275/300 MB, and the machine is experiencing sky high
> loads; I can't even login. I'm tired of killing bzr and restarting
> the process; it always fails.
>
> At work, on a Pentium IV 2 GHz/1G RAM it took me about an hour and a
> half with a slower connection.
>
> I guess if I compress the shared repo and scp it to my home machine,
> it would work, right?
Just a comment: I have not even tried yet to use bzr. According to
what I am reading it looks impossible at the moment.
Am I right or?
next prev parent reply other threads:[~2010-01-07 8:37 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 [this message]
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 ` Surely 'bzr update' shouldn't be this slow? [was: branch] Alan Mackenzie
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=e01d8a51001070037sbe1a5efre7e48c1043ba1188@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=emacs-devel@gnu.org \
/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).