This project is read-only.

TortoiseHg Clone

Sep 7, 2010 at 6:17 PM

Anybody tried to clone DotSpatial lately?  I get the error below.  I tried on 3 other Codeplex projects (including MapWindow6) and they all worked with no problems. I have tried many times with similar results each time.

real URL is https://hg01.codeplex.com/dotspatial
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: premature EOF reading chunk (got 69481 bytes, expected 493178)

[command interrupted]

Sep 7, 2010 at 8:07 PM

I tried the command line approach to Mercurial, using all of the command line options that sounded like they might give more info. It's failing on a different file each time.  Real time was 932sec in one case and 930sec on another.  They are eerily close.  Must be a timeout or a dropped connection.

Sep 8, 2010 at 7:22 PM

So the word is that it might be possible to request the earlier version first, and then pull the subsequent updates.  Codeplex might not be able to transfer the full content without a connection timeout.

Sep 9, 2010 at 12:07 AM

Success!  It was not painless.  TortoiseHg apparently does not have a way to "pull" a revision without FIRST "downloading and viewing all incoming changesets".  But once again, that step timed out as well.  So, I had to resort to hg command line pulls.  I had to do 6 hg pulls (approximately spaced out to a codeplex page of changesets).  So, to save some headaches for the next poor person to experience this:

  1. Use TortoiseHg Clone and check the "Clone to revision" box.  Enter the hex id for the very first revision (b912aaca7751).
  2. Open a command window to where TortoiseHg is installed.  For me, that was C:\Program Files\TortoiseHg
  3. Repeatedly run: "hg pull -r <changesetid> -R <path to your local DotSpatial repository> https://hg01.codeplex.com/DotSpatial" giving it a different changesetid each time.  The changesetids that I used were e11d4835f55d, 0bb49bb4f870, c14c452f7856, 94c23b9a2f6a, b8709a424dbb, 9f6a6afdf22c.  By the time someone needs this, more revisions will have been added, so you might need to do some additional ones before the next step works.
  4. Now, you can use TortoiseHg Repository Explorer and "Download and view incoming changesets" or just "Pull incoming changesets". 
  5. Right-click on the top "default" "tip" changeset and run "Update..."

I am a TortoiseHg/Mercurial newby, so my instructions above may not be perfectly mercurial and tortoisey, but they worked for me.   The solution then built and the test viewer ran.  IMHO, this was way more painful than it should have been.  It makes me wonder if we are using codeplex source control in just the right way to make the Repository pulls so lengthy.

 

 

 

 

 

Sep 26, 2010 at 10:25 AM

I got the same problem with TortoiseHg.  Is there any simpler way?

Sep 26, 2010 at 5:02 PM

I wonder if there is some way we could tweak things to where you could download the latest source without the entire history.  (I assume that's what's causing the problem?)  I don't know, but I'm very new to TortoiseHG.  But if someone has an idea of something we could do on the codeplex site to make it work better, I'm willing to do it, I just don't know what to do yet.

Sep 26, 2010 at 5:25 PM

If some of you are not necessarily having to push back to the repository, maybe we should also host a downloadable file with a zip of all the current source code in the repository?  But with the repository, if you can survive the very first pull, then updates should be a snap.  With the zip-file situation, each time you would be having to pull the whole file structure.  Is it possible you guys are using a different software setup?  It took about five minutes where a green status bar with white text updated me on how many of the 17158 chunks had been downloaded, and then about thirty seconds or so for the status bar showing how many of the 6800 or so files had been updated.  I did not get any kind of time-out, but my internet connection is pretty fast, so I suspect that the bandwidth constraints were on codeplex's side in my case.  It might not work so well if you are using a slower dsl connection or dialup.  But if this is a basic timeout "feature" of codeplex, I'm not sure if grouping the files in a different format would get around what may be a fundamental codeplex timeout limitation.

Sep 26, 2010 at 7:31 PM

 

If some of you are not necessarily having to push back to the repository, maybe we should also host a downloadable file with a zip of all the current source code in the repository?  

 

Download button on the source control page?

Sep 27, 2010 at 1:50 AM

Why not just set up a TortoiseSVN repository alternatively.  I think the TortoiseHG is not as stable and easy to use as TortoiseSVN.

Sep 27, 2010 at 6:56 PM

I suppose it could be on my end, but we have a fiber internet connection.  It should have been pretty fast to download.  I also turned off my virus scanner with no improvement.

Sep 27, 2010 at 7:30 PM

Actually, braveheal, it was my personal experience with TortoiseSVN that provoked me to switch to TortoiseHG.  It was really a nightmare.  Literally every merge required 10 minutes at a time for each failed effort on the server side and you would make some changes and try again.   It could cost me a day if someone other than me was so bold as to make a single edit in parallel and committed binaries into the repository or something.  Being able to maintain the business logic on your desktop, iron out any problems directly and only involve the network latency for a one-time push is a huge advantage.  Also, if we can get people to survive the initial cloning process, the rest of the upkeep should not cause them trouble.  People may be having bandwidth problems regarding codeplex, but those bandwith problems seem to be related to a duration cutoff (15 minutes) or whatever and might not be fixed by using SVN.  I am not against ideas that might reduce the likelihood of people having trouble from timeouts, but switching to TortoiseSVN would likely only make things worse for a project this size.  TortoiseHG is new and for sure there is a learning curve with it.  I haven't even figured out how to use most of the features, and for the life of me there is probably a simple option somewhere that would fix the problems Kyle and others are having now, so I am not ready to switch back.  We might consider splitting up the repository, but it is extremely nice to be able to use one commit and take care of everything.  There has to be a way to allow it to resume where it left off it is cut off rather than roll-back.  We just need to find it.

Oct 1, 2010 at 9:29 PM

I've been reading "Mercurial: The Definitive Guide" and I'm learning that like most source control systems, Mercurial is best at handling text files.  I suspect the support files (GDAL dlls, etc.) may be what is causing the problem.  We may want to consider downloading them separately.  I know that is not a perfect solution either because the support files sometimes need to be synchronized with the source files.

Kyle

Oct 2, 2010 at 1:34 AM

What DotNet needs is a good dependency solution like Maven... they got the GAC, they have pretty installers, but I have yet to see a nice centralized repository for libraries, like maven.

 

Yes, you can add a DLL.refresh, but that it really not a complete solution to use, create artifacts, publish for others to utilize.