* (no subject)
@ 2010-10-16 4:59 Richard Stallman
2010-10-16 6:08 ` Werner LEMBERG
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Richard Stallman @ 2010-10-16 4:59 UTC (permalink / raw)
To: emacs-devel
bzr was slow on savannah due to the use of sftp.
Do people find bzr satisfactory now?
--
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: (no subject)
2010-10-16 4:59 (no subject) Richard Stallman
@ 2010-10-16 6:08 ` Werner LEMBERG
2010-10-16 6:10 ` Werner LEMBERG
` (2 more replies)
2010-10-16 7:49 ` Is bzr+ssh's speed satisfactory? Eli Zaretskii
2010-10-19 18:28 ` (no subject) Glenn Morris
2 siblings, 3 replies; 13+ messages in thread
From: Werner LEMBERG @ 2010-10-16 6:08 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?
Well, I'm only doing `bzr pull', and it seems indeed to be more
responsive than previously. However, the amount of data transferred
by bzr is still excessively large. For example, updating from
rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
more than 20MByte! Looking at the amount of changes actually applied
to the repository, I estimate that git would need only approx. 200 to
300kByte ^[$(Q#|^[(B this is 70 to 100 times less...
It would be great if someone using an emacs git repository could
verify my estimation.
git compresses the data on the remote side before transferring it.
Does bzr omit that step? Maybe I'm missing a bzr option? Otherwise,
it looks like a severe flaw in the design. Given that many users
(including me currently) use mobile internet connections which are
sometimes extremely slow due to weak signal strength, bandwidth *is*
an issue even today.
Werner
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: (no subject)
2010-10-16 6:08 ` Werner LEMBERG
@ 2010-10-16 6:10 ` Werner LEMBERG
2010-10-16 7:54 ` Is bzr+ssh's speed satisfactory? Eli Zaretskii
2010-10-16 7:52 ` Eli Zaretskii
2010-10-18 6:26 ` (no subject) Richard Stallman
2 siblings, 1 reply; 13+ messages in thread
From: Werner LEMBERG @ 2010-10-16 6:10 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> Well, I'm only doing `bzr pull', and it seems indeed to be more
> responsive than previously. However, the amount of data transferred
> by bzr is still excessively large. For example, updating from
> rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull')
> used more than 20MByte!
I forgot to mention that I'm currently using bzr version 2.0.5 in case
this makes a difference w.r.t. the amount of transferred data.
Werner
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Is bzr+ssh's speed satisfactory?
2010-10-16 4:59 (no subject) Richard Stallman
2010-10-16 6:08 ` Werner LEMBERG
@ 2010-10-16 7:49 ` Eli Zaretskii
2010-10-19 18:28 ` (no subject) Glenn Morris
2 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2010-10-16 7:49 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 16 Oct 2010 00:59:53 -0400
>
> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?
It is significantly faster, especially with frequent updates. Where
previously I had to wait up to 5-6 minutes for an update of 3-4 days
worth of development, now it's down to 1-2 minutes or so, depending on
the amount of files that were modified. Where previously it took 2
minutes to update a few files that were modified during several hours
since the last update, it now takes 25 seconds. Previously it would
take about 40 seconds to get the "tree is up to date" result; now it
takes 10 to 15.
This is with a 3.5Mbps link, with other jobs running on the same
machine and using the link simultaneously.
I don't remember the exact timings of CVS, but I think the numbers are
comparable, perhaps even slightly faster.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Is bzr+ssh's speed satisfactory?
2010-10-16 6:08 ` Werner LEMBERG
2010-10-16 6:10 ` Werner LEMBERG
@ 2010-10-16 7:52 ` Eli Zaretskii
2010-10-18 6:26 ` (no subject) Richard Stallman
2 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2010-10-16 7:52 UTC (permalink / raw)
To: Werner LEMBERG; +Cc: rms, emacs-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2004, Size: 920 bytes --]
> Date: Sat, 16 Oct 2010 08:08:17 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: emacs-devel@gnu.org
>
> However, the amount of data transferred
> by bzr is still excessively large. For example, updating from
> rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
> more than 20MByte! Looking at the amount of changes actually applied
> to the repository, I estimate that git would need only approx. 200 to
> 300kByte ^[$(Q#|^[(B this is 70 to 100 times less...
>
> It would be great if someone using an emacs git repository could
> verify my estimation.
>
> git compresses the data on the remote side before transferring it.
> Does bzr omit that step? Maybe I'm missing a bzr option? Otherwise,
> it looks like a severe flaw in the design.
These questions are better sent to the Bazaar list
(bazaar@lists.canonical.com), where the Bazaar developers can give
definitive answers to them.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Is bzr+ssh's speed satisfactory?
2010-10-16 6:10 ` Werner LEMBERG
@ 2010-10-16 7:54 ` Eli Zaretskii
0 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2010-10-16 7:54 UTC (permalink / raw)
To: Werner LEMBERG; +Cc: rms, emacs-devel
> Date: Sat, 16 Oct 2010 08:10:01 +0200 (CEST)
> From: Werner LEMBERG <wl@gnu.org>
> Cc: emacs-devel@gnu.org
>
>
> > Well, I'm only doing `bzr pull', and it seems indeed to be more
> > responsive than previously. However, the amount of data transferred
> > by bzr is still excessively large. For example, updating from
> > rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull')
> > used more than 20MByte!
>
> I forgot to mention that I'm currently using bzr version 2.0.5 in case
> this makes a difference w.r.t. the amount of transferred data.
I doubt that: I have Bazaar 2.2.1, and the combined size of the data
between Oct 10 and yesterday was 19MB or me.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: (no subject)
2010-10-16 6:08 ` Werner LEMBERG
2010-10-16 6:10 ` Werner LEMBERG
2010-10-16 7:52 ` Eli Zaretskii
@ 2010-10-18 6:26 ` Richard Stallman
2 siblings, 0 replies; 13+ messages in thread
From: Richard Stallman @ 2010-10-18 6:26 UTC (permalink / raw)
To: Werner LEMBERG; +Cc: emacs-devel
Well, I'm only doing `bzr pull', and it seems indeed to be more
responsive than previously. However, the amount of data transferred
by bzr is still excessively large. For example, updating from
rev. 101894 (Oct. 10th) to today's rev. 101979 (with `bzr pull') used
more than 20MByte! Looking at the amount of changes actually applied
to the repository, I estimate that git would need only approx. 200 to
300kByte this is 70 to 100 times less...
It would be great if someone using an emacs git repository could
verify my estimation.
It would be interesting to set up parallel repositories, the latest
bzr and git, and update them at the same times. Then it would be
possible to rigorously compare the amount of data transferred.
git compresses the data on the remote side before transferring it.
Does bzr omit that step? Maybe I'm missing a bzr option?
It might be that the compression occurs in scp, and you're measuring
the amount of raw data rather than the amount actually transmitted.
But that's just a speculation. It would be interesting to find out
for certain.
--
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: (no subject)
2010-10-16 4:59 (no subject) Richard Stallman
2010-10-16 6:08 ` Werner LEMBERG
2010-10-16 7:49 ` Is bzr+ssh's speed satisfactory? Eli Zaretskii
@ 2010-10-19 18:28 ` Glenn Morris
2010-10-19 18:43 ` bzr on Savannah Glenn Morris
2 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2010-10-19 18:28 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
Richard Stallman wrote:
> bzr was slow on savannah due to the use of sftp.
> Do people find bzr satisfactory now?
It is much improved and personally I find it satisfactory now, yes.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bzr on Savannah
2010-10-19 18:28 ` (no subject) Glenn Morris
@ 2010-10-19 18:43 ` Glenn Morris
2010-10-19 18:58 ` Eli Zaretskii
2010-10-24 3:54 ` Richard Stallman
0 siblings, 2 replies; 13+ messages in thread
From: Glenn Morris @ 2010-10-19 18:43 UTC (permalink / raw)
To: Richard Stallman, Emacs developers
> > bzr was slow on savannah due to the use of sftp.
> > Do people find bzr satisfactory now?
>
> It is much improved and personally I find it satisfactory now, yes.
PS that comment was about basic bzr functionality. One service that
Savannah still does not provide is the ability to browse bzr
repositories via the web. The service that provides this is called
"Loggerhead", analogous to "ViewVC" for CVS repositories.
Several GNU projects have asked Savannah to implement this over many
months. Since roughly the start of the year, attempting to browse the
relevant page on Savannah simply reports:
http://bzr.savannah.gnu.org/lh/emacs
"loggerhead disabled due to instability; if you're interesting in
maintaining it, please contact us"
This issue is not as important as the sftp one was, but I think it is
important for Savannah to provide this service for Bzr repositories,
as it seems to do for every other version control system it supports.
This is the last gap in their bzr support that I can think of.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bzr on Savannah
2010-10-19 18:43 ` bzr on Savannah Glenn Morris
@ 2010-10-19 18:58 ` Eli Zaretskii
2010-10-19 19:03 ` Glenn Morris
2010-10-24 3:54 ` Richard Stallman
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2010-10-19 18:58 UTC (permalink / raw)
To: Glenn Morris; +Cc: rms, emacs-devel
> Date: Tue, 19 Oct 2010 14:43:11 -0400
> From: Glenn Morris <rgm@gnu.org>
> Cc:
>
> Since roughly the start of the year, attempting to browse the
> relevant page on Savannah simply reports:
>
> http://bzr.savannah.gnu.org/lh/emacs
>
> "loggerhead disabled due to instability; if you're interesting in
> maintaining it, please contact us"
Correction: now it reports: "HTTP 404 - File not found".
> This issue is not as important as the sftp one was, but I think it is
> important for Savannah to provide this service for Bzr repositories,
> as it seems to do for every other version control system it supports.
Yes, I agree. I posted a request to the Savannah list to fix this
up. Perhaps Richard's word will give this a boost.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bzr on Savannah
2010-10-19 18:58 ` Eli Zaretskii
@ 2010-10-19 19:03 ` Glenn Morris
0 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2010-10-19 19:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, emacs-devel
Eli Zaretskii wrote:
>> http://bzr.savannah.gnu.org/lh/emacs
>>
>> "loggerhead disabled due to instability; if you're interesting in
>> maintaining it, please contact us"
>
> Correction: now it reports: "HTTP 404 - File not found".
I still get the first form (not that it matters much either way).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bzr on Savannah
2010-10-19 18:43 ` bzr on Savannah Glenn Morris
2010-10-19 18:58 ` Eli Zaretskii
@ 2010-10-24 3:54 ` Richard Stallman
2010-10-24 19:50 ` Glenn Morris
1 sibling, 1 reply; 13+ messages in thread
From: Richard Stallman @ 2010-10-24 3:54 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
One service that
Savannah still does not provide is the ability to browse bzr
repositories via the web. The service that provides this is called
"Loggerhead", analogous to "ViewVC" for CVS repositories.
We need someone to volunteer to help Savannah and do this.
Would someone like to step forward?
Since roughly the start of the year, attempting to browse the
relevant page on Savannah simply reports:
http://bzr.savannah.gnu.org/lh/emacs
"loggerhead disabled due to instability;
What happened before then? Did it work?
Or did it fail some other way?
--
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bzr on Savannah
2010-10-24 3:54 ` Richard Stallman
@ 2010-10-24 19:50 ` Glenn Morris
0 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2010-10-24 19:50 UTC (permalink / raw)
To: rms; +Cc: emacs-devel
Richard Stallman wrote:
> We need someone to volunteer to help Savannah and do this.
> Would someone like to step forward?
Not me.
> "loggerhead disabled due to instability;
>
> What happened before then? Did it work?
> Or did it fail some other way?
I think maybe it did work at some point, but it was almost a year ago
so I can't remember.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2010-10-24 19:50 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-16 4:59 (no subject) Richard Stallman
2010-10-16 6:08 ` Werner LEMBERG
2010-10-16 6:10 ` Werner LEMBERG
2010-10-16 7:54 ` Is bzr+ssh's speed satisfactory? Eli Zaretskii
2010-10-16 7:52 ` Eli Zaretskii
2010-10-18 6:26 ` (no subject) Richard Stallman
2010-10-16 7:49 ` Is bzr+ssh's speed satisfactory? Eli Zaretskii
2010-10-19 18:28 ` (no subject) Glenn Morris
2010-10-19 18:43 ` bzr on Savannah Glenn Morris
2010-10-19 18:58 ` Eli Zaretskii
2010-10-19 19:03 ` Glenn Morris
2010-10-24 3:54 ` Richard Stallman
2010-10-24 19:50 ` Glenn Morris
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).