Thanks for the suggestion to pull revision 0 and then iteratively pull some successive revisions until working up to the current revision. That worked!
This does bring up one more question though. I am a novice user of TortoiseHg, but I did not see a way to pull a specific revision without FIRST "downloading and viewing all incoming changesets". Unfortunately, "downloading and viewing all incoming changesets" timed out as well. I had to resort to straight hg command line pulls. Once I got far enough along in the history with successive hg pulls, I was then able to "download and view all incoming changesets". Does anyone know if there was a simpler way to do these incremental pulls in TortoiseHg without resorting to hg pulls from the command line? Thanks, Kyle -----Original Message----- From: Mads Kiilerich [mailto:[email protected]] Sent: Tuesday, September 07, 2010 5:46 PM To: Kyle Ellison Cc: [email protected] Subject: Re: [thg] Clone premature EOF Kyle Ellison wrote, On 09/07/2010 11:37 PM: > > I'm trying to Clone a Codeplex project and the Clone aborts at around > the 15 to 16 minute mark. I switched over to the command line option > of hg just to get more detailed info shown below. I tried setting the > 'timeout' value in my mercurial.ini file to -600 (the documentation > said a negative number meant no timeout). This made no difference. I > also read that this might be a result of a timeout value on the > codeplex server. Any help would be appreciated. I'm using hg version > 1.6.3 and tortoisehg version 1.1.3 on Windows 32-bit. > > Thanks > > C:\Program Files\TortoiseHg>hg clone --debug --traceback --verbose > --profile --t > > ime https://hg01.codeplex.com/DotSpatial N:\DotSpatialHg > > N:\DotSpatialHg.txt > (This problem is with a pure Mercurial, so the Mercurial mailing list might be more appropriate. And note that adding --profile probably will make Mercurial quite a bit slower and thus might make the problem worse.) It seems like this is a pretty huge repository with a lot of big files. It is quite possible that it is a server side process quota limitation that kicks in and stops the server side process. You can try to clone revision 0 and then incrementally pull "few" changesets at a time to avoid hitting the limit. You can also try to ask the project owner if they see the same problem elsewhere, and perhaps file a bug report at codeplex. /Mads > > Abort: premature EOF reading chunk (got 1709557 bytes, expected 2708572) > > abort: premature EOF reading chunk (got 1709557 bytes, expected 2708572) > > Time: real 932.137 secs (user 34.766+0.000 sys 40.328+0.000) > > Next is the last few lines of the file to which I directed the stdout > > ---------------------------------------------------------------------------- --- > > SupportFiles/GDAL64bit/libecwj2.dll revisions > > files: 6920/13831 chunks (50.03%) > > adding SupportFiles/GDAL64bit/libexpat.dll revisions > > files: 6921/13831 chunks (50.04%) > > adding SupportFiles/GDAL64bit/libfcgi.dll revisions > > files: 6922/13831 chunks (50.05%) > > adding SupportFiles/GDAL64bit/libmap.dll revisions > > files: 6923/13831 chunks (50.05%) > > > ---------------------------------------------------------------------------- -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > > > _______________________________________________ > Tortoisehg-discuss mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
