hg pull stalls

[Paul Copeland]

Hi - running into this problem on version 1.5.2. When I use hg pull
from a remote repository (https) it hangs on "adding file changes".
Same thing happens exactly with hg clone. This repo was working until
yesterday. Here is what I see on the screen -

pulling from https://hg.kenai.com/hg/jfxphoneapps~javafxphoneapps
searching for changes
adding changesets
adding manifests
adding file changes

I have left if there for hours - nothing happens - no CPU usage or
network traffic after the first few seconds. Any ideas on what might
the problem? The remote system is up. hg verify has no errors on local
repo.

Thanks


_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

--
You received this message because you are subscribed to the Google Groups "mercurial" group.
To post to this group, send email to mercuria...@googlegroups.com.
To unsubscribe from this group, send email to mercurial_gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mercurial_general?hl=en.

[Matt Mackall]

On Thu, 2010-05-06 at 08:30 -0700, Paul Copeland wrote:
> Hi - running into this problem on version 1.5.2. When I use hg pull
> from a remote repository (https) it hangs on "adding file changes".
> Same thing happens exactly with hg clone. This repo was working until
> yesterday. Here is what I see on the screen -
>
> pulling from https://hg.kenai.com/hg/jfxphoneapps~javafxphoneapps
> searching for changes
> adding changesets
> adding manifests
> adding file changes

Hmm, that's password protected.

You should try running with the progress bar:

hg --config extensions.progress= pull

If that doesn't help, try running with --debug. That should at least
tell you what file seems to be the problem.

> I have left if there for hours - nothing happens - no CPU usage or
> network traffic after the first few seconds. Any ideas on what might
> the problem? The remote system is up. hg verify has no errors on local
> repo.

Generally, that would suggest something hanging on the server. Perhaps a
very large file revision.

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

Thanks! - progressbar didn't help - stalled the same.

With --debug these are the last few lines of output -

adding JFXPhoneApps/src/common/com/oracle/satin/apps/news/SourceBox.fx
revision

files: 30 chunks
files: 31 chunks
files: 32 chunks
adding
JFXPhoneApps/src/common/com/oracle/satin/apps/news/SourceEditBox.fx revi
ions
files: 33 chunks
files: 34 chunks
adding
JFXPhoneApps/src/common/com/oracle/satin/apps/news/images/arrow.png revi
ions
files: 35 chunks
adding
JFXPhoneApps/src/common/com/oracle/satin/apps/news/images/background.png
revisions

It stays there forever apparently. Does this mean it was working on
background.png and hung there? background.png is 117 KB. I don't know
if that is considered "large". We have some larger files.

Any suggestions about how to clear it up? Any server config issue that
could be the problem? Delete that file? (might a problem for the project).

Thanks

On 5/6/2010 9:00 AM, Matt Mackall wrote:
> On Thu, 2010-05-06 at 08:30 -0700, Paul Copeland wrote:
>
>> Hi - running into this problem on version 1.5.2. When I use hg pull
>> from a remote repository (https) it hangs on "adding file changes".
>> Same thing happens exactly with hg clone. This repo was working until
>> yesterday. Here is what I see on the screen -
>>
>> pulling from https://hg.kenai.com/hg/jfxphoneapps~javafxphoneapps
>> searching for changes
>> adding changesets
>> adding manifests
>> adding file changes
>>
>
> Hmm, that's password protected.
>
> You should try running with the progress bar:
>
> hg --config extensions.progress= pull
>
> If that doesn't help, try running with --debug. That should at least
> tell you what file seems to be the problem.
>
>
>> I have left if there for hours - nothing happens - no CPU usage or
>> network traffic after the first few seconds. Any ideas on what might
>> the problem? The remote system is up. hg verify has no errors on local
>> repo.
>>
>
> Generally, that would suggest something hanging on the server. Perhaps a
> very large file revision.
>
>

[Paul Copeland]

More info - with progressbar it stalls on

adding file changes
files [
<=> ] 92

[Paul Copeland]

Sorry - to keep posting - but here is MORE info - On running "hg --debug
pull" again it get past the file it hung on before and got to a
different place where it hangs -

files: 94 chunks
adding
JFXPhoneApps/src/common/com/oracle/satin/apps/saworldcup/view/TeamScreen.
fx revisions
files: 95 chunks
adding
JFXPhoneApps/src/common/com/oracle/satin/apps/saworldcup/view/resources/a
ppIcon.png revisions
files: 96 chunks
adding
JFXPhoneApps/src/common/com/oracle/satin/apps/saworldcup/view/resources/b
ackground.png revisions

I don't know how big "saworldcup/view/resources/background.png" is since
it is a new file in my local repo.

[Matt Mackall]

On Thu, 2010-05-06 at 09:54 -0700, Paul Copeland wrote:
> Thanks! - progressbar didn't help - stalled the same.
>
> With --debug these are the last few lines of output -
>
> adding JFXPhoneApps/src/common/com/oracle/satin/apps/news/SourceBox.fx
> revision
>
> files: 30 chunks
> files: 31 chunks
> files: 32 chunks
> adding
> JFXPhoneApps/src/common/com/oracle/satin/apps/news/SourceEditBox.fx revi
> ions
> files: 33 chunks
> files: 34 chunks
> adding
> JFXPhoneApps/src/common/com/oracle/satin/apps/news/images/arrow.png revi
> ions
> files: 35 chunks
> adding
> JFXPhoneApps/src/common/com/oracle/satin/apps/news/images/background.png
> revisions
>
> It stays there forever apparently. Does this mean it was working on
> background.png and hung there? background.png is 117 KB. I don't know
> if that is considered "large". We have some larger files.

No, that's not large. Large would be, say 100MB or more.

Does it stop there consistently? It looks like the answer is no as your
other email says 92 rather than 35. That strongly suggests a server
issue, like a timeout. How long does this take?

Alternately, you may have a proxy or firewall issue - you should try
doing your pull on a machine on a different network.

> Any suggestions about how to clear it up? Any server config issue that
> could be the problem? Delete that file? (might a problem for the project).

You'll probably need to bring the server people into the loop to check
logs and so on on their end.

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

Hi - running into this problem on version 1.5.2. When I use hg pull
from a remote repository (https) it hangs on "adding file changes".
Same thing happens exactly with hg clone. This repo was working until
yesterday. Here is what I see on the screen -

pulling from https://hg.kenai.com/hg/jfxphoneapps~javafxphoneapps
searching for changes
adding changesets
adding manifests
adding file changes

I have left if there for hours - nothing happens - no CPU usage or
network traffic after the first few seconds. Any ideas on what might
the problem? The remote system is up. hg verify has no errors on local
repo.

Thanks

[Paul Copeland]

Thanks again - yes it stops inconsistently and even works for some
people sometimes but not always (more than one person on our project is
having the problem). Of course the server people claim it is not their
problem :-).

We do seem to keep hearing that ssh access will work.

Can anyone help me set that up? I can create a public key with java
keytool. How do I get hg to know to use this public key (I'm on windows)?

[Steve Borho]

On Thu, May 6, 2010 at 3:33 PM, Paul Copeland <te...@jotobjects.com> wrote:
> Thanks again - yes it stops inconsistently and even works for some people
> sometimes but not always (more than one person on our project is having the
> problem).  Of course the server people claim it is not their problem :-).
>
> We do seem to keep hearing that ssh access will work.
>
> Can anyone help me set that up?  I can create a public key with java
> keytool.  How do I get hg to know to use this public key (I'm on windows)?

Your options are:

cygwin's openssh - uses standard ssh keyfiles

Plink/TortoisePlink - uses it's own keyfile format, but it has a
keygen tool that can import openssh keys.

openssh is an order of magnitude faster, but much more difficult to
setup on Windows.

--
Steve Borho

[Paul Copeland]

thanks - meanwhile I had cygwin open-ssh sitting around and used
ssh-keygen to generate the key and ssh-keygen -y to get a printable copy
of the public key.

That works. but now... drum roll ... I get this

hg clone ssh://myname@MYHOST/jfxphoneapps~javafxphoneapps
Enter passphrase for key '/cygdrive/c/Users/jot/.ssh/id_rsa':
destination directory: jfxphoneapps~javafxphoneapps
requesting all changes

adding changesets
adding manifests
adding file changes

transaction abort!
rollback completed
abort: premature EOF reading chunk (got 57157 bytes, expected 978254)
remote: Read from remote host MYHOST: Software caused connection abort

[Paul Copeland]

Following up on prior topic "hg pull stalls" -

I switched to ssh from https and was hopeful that would take care of
it. No luck - Now I it quits with an error with ssh - so that's better
than stalling. When I use --debug it again stops on the kind of file
where it stalled with https. hg clone also fails.

This is a large server with many projects. They just moved to a new
datacenter. They have lots of users and they claim that only me and a
few others on my project are having this problem.

Does the error from hg clone below give any hints about the problem?
This was all working until a few days ago. Some of the users on my
project are not having this problem and some are.

Appreciate any suggestions. I'm really stuck on this.

> hg clone ssh://myname@MYHOST/jfxphoneapps~javafxphoneapps
> Enter passphrase for key '/cygdrive/c/Users/jot/.ssh/id_rsa':
> destination directory: jfxphoneapps~javafxphoneapps
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> transaction abort!
> rollback completed
> abort: premature EOF reading chunk (got 57157 bytes, expected 978254)
> remote: Read from remote host MYHOST: Software caused connection abort
>
>

[Matt Mackall]

On Fri, 2010-05-07 at 13:25 -0700, Paul Copeland wrote:
> Following up on prior topic "hg pull stalls" -
>
> I switched to ssh from https and was hopeful that would take care of
> it. No luck - Now I it quits with an error with ssh - so that's better
> than stalling. When I use --debug it again stops on the kind of file
> where it stalled with https. hg clone also fails.
>
> This is a large server with many projects. They just moved to a new
> datacenter. They have lots of users and they claim that only me and a
> few others on my project are having this problem.
>
> Does the error from hg clone below give any hints about the problem?
> This was all working until a few days ago. Some of the users on my
> project are not having this problem and some are.

Is there any pattern to the operating systems involved? Are any Linux
clients failing?

> Appreciate any suggestions. I'm really stuck on this.
>
> > hg clone ssh://myname@MYHOST/jfxphoneapps~javafxphoneapps
> > Enter passphrase for key '/cygdrive/c/Users/jot/.ssh/id_rsa':
> > destination directory: jfxphoneapps~javafxphoneapps
> > requesting all changes
> > adding changesets
> > adding manifests
> > adding file changes
> > transaction abort!
> > rollback completed
> > abort: premature EOF reading chunk (got 57157 bytes, expected 978254)
> > remote: Read from remote host MYHOST: Software caused connection abort

Almost all problems with push/pull are on the server side, and there's
no sign that this is an exception. That it's sporadic and affects only
some clients reinforces that. It's very likely hitting a resource limit
or timeout or similar. How long does it take to fail?

If the server folks still aren't buying it, feel free to direct them to
me.

In the mean time, you might be able to make some forward progress using
partial pulls (see pull -r)

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

Thanks on that feedback.

We have macs and windows. Not sure about linux. It may be true that
the macs are not failing and that only the windows clients are failing -
but not all windows clients.

I'm not certain of the OS pattern - this is my recollection. Will check
further.

[Matt Mackall]

On Fri, 2010-05-07 at 13:54 -0700, Paul Copeland wrote:
> Thanks on that feedback.
>
> We have macs and windows. Not sure about linux. It may be true that
> the macs are not failing and that only the windows clients are failing -
> but not all windows clients.
>
> I'm not certain of the OS pattern - this is my recollection. Will check
> further.

Ok, that's a useful observation, probably worth exploring further. The
stock memory allocator on at least some versions of Windows is.. not
ideal. Your kernel may be choking on large I/O requests.

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

We have had 5 clients failing some intermittently and some consistently.

1 linux machine stalled on hg pull several times over a period of
couple of days and has been working since.

3 windows systems - windows 7 home premium, Windows7 64 bit, Vista

Don't know what OS the 5th one is.

re. "Windows is not ideal", hey of course! But we used it with no
problems with hg for a few months so hopefully we don't all have to
switch out our workstations in order to use Mercurial ;-)

The server people are looking into it...

On 5/7/2010 2:24 PM, Matt Mackall wrote:
> On Fri, 2010-05-07 at 13:54 -0700, Paul Copeland wrote:
>
>> Thanks on that feedback.
>>
>> We have macs and windows. Not sure about linux. It may be true that
>> the macs are not failing and that only the windows clients are failing -
>> but not all windows clients.
>>
>> I'm not certain of the OS pattern - this is my recollection. Will check
>> further.
>>
>
> Ok, that's a useful observation, probably worth exploring further. The
> stock memory allocator on at least some versions of Windows is.. not
> ideal. Your kernel may be choking on large I/O requests.
>
>

[Matt Mackall]

On Fri, 2010-05-07 at 15:35 -0700, Paul Copeland wrote:
> We have had 5 clients failing some intermittently and some consistently.
>
> 1 linux machine stalled on hg pull several times over a period of
> couple of days and has been working since.

Ok, if you're seeing the same problem on Linux machines, it's definitely
not the aforementioned "large I/O" problem, which is definitely a
Windows only problem and which we haven't seen in quite a while.

--
Mathematics is the supreme nostalgia of our time.

[Steve Borho]

On Sun, May 9, 2010 at 4:52 PM, Matt Mackall <m...@selenic.com> wrote:
> On Fri, 2010-05-07 at 15:35 -0700, Paul Copeland wrote:
>> We have had 5 clients failing some intermittently and some consistently.
>>
>> 1 linux machine stalled on hg pull several times over a period of
>> couple of days and has been working since.
>
> Ok, if you're seeing the same problem on Linux machines, it's definitely
> not the aforementioned "large I/O" problem, which is definitely a
> Windows only problem and which we haven't seen in quite a while.

FWIW: Something between the upgrade to Python2.6 and MSVCRT90, and the
switch to Microsoft's C++ compiler for building the Mercurial C
extensions made most of those problems go away on Windows.

We still get the occasional MemoryError bug report, but it usually
from some questionable UI features on our part (commit preview).

--
Steve Borho

[Cameron Simpson]

On 07May2010 15:35, Paul Copeland <te...@jotobjects.com> wrote:
| We have had 5 clients failing some intermittently and some consistently.

[ ... both linux and windows ... ]
| The server people are looking into it... [...]

Speaking as a network/firewall/OS guy rather than a mercurial guy,
is it possible that a stateful firewall has decided the connection is
idle? Matt, are there periods where the hg pull might send no data in
either direction for an extended period?

Anyway, to circumvent the idleness try using:
ssh -o ServerAliveInterval=10
or put:
ServerAliveInterval 10
in your .ssh/config file at the client end. That ought to periodicly
send a ping in the ssh protocol, keeping the connection "awake" from the
point of view of a firewall, without affecting the hg data protocol.
From "man ssh_config":

ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been
received from the server, ssh(1) will send a message through the
encrypted channel to request a response from the server. The default is
0, indicating that these messages will not be sent to the server. This
option applies to protocol version 2 only.

It may be interesting to see if this changes the behaviour.
If it reliably makes stuff work, i would suspect a firewall getting
bored.

Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

[Alain] had been looking at his dashboard, and had not seen me, so I
ran into him. - Jean Alesi on his qualifying prang at Imola '93

[Paul Copeland]

Thanks - I tried that, but no luck. I know it was picking up the config
file because it complained until I changed the owner to the correct
user. Here is the config file.

>cat %USERPROFILE%/.ssh/config
ServerAliveInterval 10

Here is the pull command and result (total time = under 30 seconds) -

>hg --config
paths.default=ssh://myname@myhost/jfxphoneapps~javafxphoneapps pull

Enter passphrase for key '/cygdrive/c/Users/jot/.ssh/id_rsa':

pulling from ssh://myname@myhost/jfxphoneapps~javafxphoneapps
searching for changes

adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed

abort: premature EOF reading chunk (got 292558 bytes, expected 455902)
remote: Read from remote host myhost: Software caused connection abort

[Cameron Simpson]

On 09May2010 20:56, Paul Copeland <te...@jotobjects.com> wrote:
| Thanks - I tried that, but no luck. I know it was picking up the
| config file because it complained until I changed the owner to the
| correct user. Here is the config file.
|
| >cat %USERPROFILE%/.ssh/config
| ServerAliveInterval 10

Normally that would read:

Host *
ServerAliveInterval 10

or:

Host myhost
ServerAliveInterval 10

i.e. I'm not sure it had effect. Though I'm also surprised ssh didn't
complain either.

Could you try it again, perhaps with a bare ssh first:

ssh myname@myhost w

then again via hg.

Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Do unto others ... then split. - Mary Anne Stasium

[Paul Copeland]

I added "Host *" to the config file as shown - no luck - same thing
happened.

With bare ssh I get "...successfully authenticated" after entering my
passphrase.

If I put some random text in the config file I get errors, indicating it
is reading the config file.

[Matt Mackall]

On Mon, 2010-05-10 at 12:41 +1000, Cameron Simpson wrote:
> On 07May2010 15:35, Paul Copeland <te...@jotobjects.com> wrote:
> | We have had 5 clients failing some intermittently and some consistently.
> [ ... both linux and windows ... ]
> | The server people are looking into it... [...]
>
> Speaking as a network/firewall/OS guy rather than a mercurial guy,
> is it possible that a stateful firewall has decided the connection is
> idle? Matt, are there periods where the hg pull might send no data in
> either direction for an extended period?

On typical networks links, Mercurial is bandwidth limited. For extremely
large files (ie much bigger than we seem to be talking about here),
there may be noticeable delays. But a proxy/firewall could definitely be
to blame if it turns out to be a common factor among failing users.

The only two common factors yet identified are a) server and b) repo.

Paul, have you tried the incremental pull thing yet? It might help
identify a consistently failing cset, or it might get you past the
problem.

--
Mathematics is the supreme nostalgia of our time.

[Cameron Simpson]

On 09May2010 23:27, Paul Copeland <te...@jotobjects.com> wrote:
| I added "Host *" to the config file as shown - no luck - same thing
| happened.
|
| With bare ssh I get "...successfully authenticated" after entering
| my passphrase.
|
| If I put some random text in the config file I get errors,
| indicating it is reading the config file.

Ok, then it's probably not a bored firewall. It seemed worth exploring
and easy to try. Cheers,

--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Heavier-than-air flying machines are impossible.
--Lord Kelvin, president, Royal Society, 1895.

[Paul Copeland]

I did try the incremental pull and got a few revisions before hitting a
revision with one of the modest sized png files. The same thing happens
at that point. The actual file it stops on (with --debug) is ~100KB png
image - and not always the same image indicating it is not just one
problematic file.

On 5/10/2010 12:36 AM, Matt Mackall wrote:
> On Mon, 2010-05-10 at 12:41 +1000, Cameron Simpson wrote:
>
>> On 07May2010 15:35, Paul Copeland <te...@jotobjects.com> wrote:
>> | We have had 5 clients failing some intermittently and some consistently.
>> [ ... both linux and windows ... ]
>> | The server people are looking into it... [...]
>>
>> Speaking as a network/firewall/OS guy rather than a mercurial guy,
>> is it possible that a stateful firewall has decided the connection is
>> idle? Matt, are there periods where the hg pull might send no data in
>> either direction for an extended period?
>>
>
> On typical networks links, Mercurial is bandwidth limited. For extremely
> large files (ie much bigger than we seem to be talking about here),
> there may be noticeable delays. But a proxy/firewall could definitely be
> to blame if it turns out to be a common factor among failing users.
>
> The only two common factors yet identified are a) server and b) repo.
>
> Paul, have you tried the incremental pull thing yet? It might help
> identify a consistently failing cset, or it might get you past the
> problem.
>
>

[Matt Mackall]

On Mon, 2010-05-10 at 09:10 -0700, Paul Copeland wrote:
> I did try the incremental pull and got a few revisions before hitting a
> revision with one of the modest sized png files. The same thing happens
> at that point. The actual file it stops on (with --debug) is ~100KB png
> image - and not always the same image indicating it is not just one
> problematic file.

FYI, we just had a very similar report on IRC involving a 135MB file in
a public repo. I was able to successfully clone it and republish it such
that the user could complete their clone successfully. So still
everything is pointing to a resource limitation on the server.

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

PROBLEM SOLVED (hopefully)

1. created VMware ubuntu instance on my Vista
2. shared a directory from Vista with VM Linux
3. did hg clone on Linux to shared directory
4. now have repo on Vista and can work normally and do hg work on Linux

So it was a client problem. My feeling is that it is actually a server
problem but that the non-Windows clients are able to correct for the
problem without failing.

[Paul Copeland]

One other thing - used HG 1.4.3 - that is what comes from the Ubuntu
download site.

I was not able to find a a more recent Mercurial binary for Ubuntu.

[Matt Mackall]

On Thu, 2010-05-13 at 14:12 -0700, Paul Copeland wrote:
> One other thing - used HG 1.4.3 - that is what comes from the Ubuntu
> download site.
>
> I was not able to find a a more recent Mercurial binary for Ubuntu.

http://mercurial.selenic.com/wiki/Download

I expect your problem is actually intermittent (related to server load)
and will eventually hit in your new config.

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

Thanks - I saw that - there do not seem to be final binary releases at
these links.

On 5/13/2010 2:15 PM, Matt Mackall wrote:
> On Thu, 2010-05-13 at 14:12 -0700, Paul Copeland wrote:
>
>> One other thing - used HG 1.4.3 - that is what comes from the Ubuntu
>> download site.
>>
>> I was not able to find a a more recent Mercurial binary for Ubuntu.
>>
>
> http://mercurial.selenic.com/wiki/Download
>
> I expect your problem is actually intermittent (related to server load)
> and will eventually hit in your new config.
>
>

[Matt Mackall]

On Thu, 2010-05-13 at 22:01 -0700, Paul Copeland wrote:
> Thanks - I saw that - there do not seem to be final binary releases at
> these links.

I see 1.5.3 here:

https://launchpad.net/~mercurial-ppa/+archive/releases

--
Mathematics is the supreme nostalgia of our time.

[Paul Copeland]

Thanks -

'll try that. Not knowing what a PPA is (Philippine Ports Authority?)
or if this source was reliable or trustworthy I passed it up initially.

On 5/13/2010 10:57 PM, Matt Mackall wrote:
> On Thu, 2010-05-13 at 22:01 -0700, Paul Copeland wrote:
>
>> Thanks - I saw that - there do not seem to be final binary releases at
>> these links.
>>
>
> I see 1.5.3 here:
>
> https://launchpad.net/~mercurial-ppa/+archive/releases
>
>

[Colin Caughie]

Hi,

I just had this problem, and my scenario seems to be different enough to the ones discussed on this thread that I thought I'd report.

I have a fairly large repository on my work PC that I had cloned to my home PC. Both are running Windows 7 64 bit. At work I have hg 1.5.1, at home 1.5.3, both installed via TortoiseHG.

To access my work machine from home I use Putty to connect to our SSH server at work, opening tunnels to various ports on my work machine, including 3389 (RDP) and 8000. To clone, pull etc. from work to home I run "hg serve" on my work machine, then "hg pull http://localhost:8000" on my home machine.

Although this usually works fine, even when cloning the whole repository, I just tried to pull 10 new changesets and it failed four times before finally succeeding. There was no noticeable delay, the failure was reported almost immediately after issuing the command.

Here is the output:

> hg pull http://localhost:8000
pulling from http://localhost:8000
searching for changes

adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed

abort: premature EOF reading chunk (got 180 bytes, expected 641)

> hg pull http://localhost:8000
pulling from http://localhost:8000
searching for changes

adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed

abort: premature EOF reading chunk (got 5316 bytes, expected 56376)

> hg pull http://localhost:8000
pulling from http://localhost:8000
searching for changes

adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed

abort: premature EOF reading chunk (got 5316 bytes, expected 56376)

> hg pull http://localhost:8000
pulling from http://localhost:8000
searching for changes

adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed

abort: premature EOF reading chunk (got 2785 bytes, expected 56376)

> hg pull http://localhost:8000
pulling from http://localhost:8000
searching for changes

adding changesets
adding manifests
adding file changes

added 10 changesets with 45 changes to 46 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)

Colin

Latest News at: http://www.indigovision.com/news2010.php