[Top][All Lists]

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

Re: [Savannah-hackers-public] Savannah bzr server errors out

From: Bake Timmons
Subject: Re: [Savannah-hackers-public] Savannah bzr server errors out
Date: Sun, 22 Jan 2012 23:13:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Martin Pool <address@hidden> writes:

> On 21 January 2012 20:26, Eli Zaretskii <address@hidden> wrote:
>> > From: Bake Timmons <address@hidden>
>> > Date: Fri, 20 Jan 2012 17:52:58 -0500
>> >
>> > I'm unable to upgrade my emacs trunk repo past certain revisions (106781
>> > and 106890).  Rather than download a whole bzr repo for a third time, I
>> > am reporting this problem and will just use a git repo until I can use
>> > bzr again.
>> >
>> > What the 'bzr pull' failures have in common is that they occur after
>> > about 2-2.5 hours on my 28.8 kbps dialup connection (a little over 20MB
>> > of data transferred).  The failures happen using bzr, nosmart+bzr, and
>> > http protocols and under the bzr client versions 2.5b4 and 2.5b5.
>> > Running 'bzr check' showed nothing wrong with the repo, in the case of
>> > emacs trunk version 106781 and in the case of version 106890.
>> > [...]
>> >   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/",
>> > line 286, in _read_more
>> >     "Unexpected end of message. "
>> > ConnectionReset: Connection closed: Unexpected end of
>> > message. Please check connectivity and permissions, and report a
>> > bug if problems persist.
>> It's a "feature": the savannah bzr server has a 2-hour timeout, so it
>> simply closes the connection after that.
>> The timeout was introduced because otherwise zombie instances of the
>> bzr server would be left after broken connections and gradually bring
>> bzr.savannah to its knees.
>> I'm told that bzr 2.5, to be released in a few weeks, will have
>> built-in features that will allow to remove the timeout.  I hope once
>> bzr 2.5 is out, we could have it installed on savannah and fix this
>> problem.
>> Until then, I'm afraid your only choice would be to use a faster link.
>> Martin, is there any other workaround?  For that matter, did I
>> describe the issue correctly?
> Hi, Eli,
> It looks like it was actually running at full wire speed (3.1kB/s!).
> I wonder if there really should have been 20MB of updates to download
> - a -Dhpss run would help tell that - but it seems possible a fairly
> stale emacs checkout would need that many.
> You could install 2.5b5 now - it is at release stability now and it
> will be useful to get some feedback on whether it helps people like
> Bake.  Using 2.5b5 on the client may help too.
> --
> Martin

Hi Martin,

Yes, it was very close to the optimal speed my connection can support.

Although I have noticed even bigger updates than 20MB from one revision
to the next of trunk, I also have doubts about this *particular* case
(based on my reading of the log update).  I was just trying to update to
from 106890 to 106891 (using 'bzr pull -r 106891') -- just one
revision up.

I am ready to test with client 2.5b5.


reply via email to

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