# Cloning From SVN+SSH Fails

Issue #154 wontfix
mfollett
created an issue

When attempting to clone a subdirectory from an SVN repo via the svn+ssh scheme hg fails almost immediately with the following error:

//abort: ("Can't open file '/srv/svn/repo/db/revs/25434': Too many open files", 24)//

However, if I attempt to clone the whole repository instead of a subdirectory of it then it appears to work. I don't let it follow through though because it would take days to process.

1. reporter

Hey, so we've been playing with this some more to work on our svn repo and it looks like the problem may be related to a revision a while back where we moved the trunk from one subdirectory to another.

2. reporter

Changed line 106 from: if % 50 == 0: to: if % 3 == 0: and then to: if % 2 == 0:

None of these resolved the issue.

Same issue when I try to clone the entire repository using the most up to date versions of hg and hgsubversion.

Same problem here. Unable to pull revision with branch merge (lots of changes).

Mercurial 1.5.1, hgsubversion revision b72850177e5c.

Similar problem with svn+ssh in that I can't clone an ssh repo, but different error and I suspect different root cause.

Using TortoiseGit or TortoiseSVN on Windows 7 64 bit I can clone (Git) or Checkout from svn+ssh:user@server/repo - I just need pagaent running with my ssh key loaded. With TortoiseHg, the same repo gives me "abort: Can't create tunnel: The parameter is incorrect.". I'm using Pageant to store my key to connect. I've tried from the command line or the GUI with the same results, and also tried overriding the SSH config in mercurial.ini with the ssh="path\to\plink.exe" command, both with and without the -i "keyname" parameter. I can successfully clone other svn repos through the extension.

Windows 7 Enterprise 64-bit TortoiseHg version 1.1 64-bit Mercurial 1.6

Also tested and had same problem with: TortoiseHg version 1.02 64-bit Mercurial 1.5.2

hgsubversion revision 8e621dbb82d4

Similar problem for me. I tried to clone a repo, but it FAILED, saying that it cannot create a tunnel:

---

abort: Can't create tunnel: Das System kann die angegebene Datei nicht finden.

[command interrupted]

---

Same in command line and in THG itself.

Anonymous,

That's probably a bug in the Subversion build TortoiseHg bundles, not in hgsubversion as such. Please report it to the TortoiseHg developers; there's nothing we can do about it.

Oh, and it isn't related to this bug.

I had the same problem with the subdirectory of a URL for a repository that was created by the "svn copy" of another section of the remote repo, meaning that it had a large number of files in the initial revision. The solution that worked for me was to use the "--stupid" flag for the initial clone:

  cmd\$ hg clone --stupid svn+ssh://example.com/path/to/svn/repo


I let the first couple revs clone successfully, then issued a single CTRL-C to get the process to gracefully complete. Then I was able to subsequently issue "hg pull" to complete the clone process.

durin42 suggested on #mercurial that one should check that the remote svn is from the 1.6 release branch, as earlier versions had real problems with leaving to many files open, but this suggestion did not help out my case.

I get this problem too, hg version 3.2.3, hgsubversion 1295:9d5cff8d7f67. As reported earlier in this thread, the revision that fails is a subversion merge from a branch to trunk and I'm attempting to clone trunk. I get this with --traceback:

  File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 478, in pull
File "C:/dev/hgsubversion\hgsubversion\replay.py", line 57, in convert_rev
File "C:/dev/hgsubversion\hgsubversion\replay.py", line 74, in _convert_rev
File "C:/dev/hgsubversion\hgsubversion\svnwrap\svn_swig_wrapper.py", line 466, in get_replay
File "libsvn\ra.pyo", line 837, in svn_ra_replay
SubversionException: ("Can't open file '/svn/hexagon/db/revs/1/1344': Too many open files", 24)
Traceback (most recent call last):
File "mercurial\dispatch.pyo", line 140, in _runcatch
File "mercurial\dispatch.pyo", line 850, in _dispatch
File "mercurial\dispatch.pyo", line 611, in runcommand
File "mercurial\dispatch.pyo", line 941, in _runcommand
File "mercurial\dispatch.pyo", line 912, in checkargs
File "mercurial\dispatch.pyo", line 847, in <lambda>
File "mercurial\util.pyo", line 677, in check
File "mercurial\extensions.pyo", line 151, in wrap
File "mercurial\util.pyo", line 677, in check
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 651, in clone
File "mercurial\util.pyo", line 677, in check
File "mercurial\commands.pyo", line 1371, in clone
File "mercurial\extensions.pyo", line 196, in wrap
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 640, in hgclonewrapper
File "mercurial\hg.pyo", line 423, in clone
File "mercurial\localrepo.pyo", line 1751, in clone
File "mercurial\extensions.pyo", line 196, in wrap
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 535, in exchangepull
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 501, in pull
Abort: ("Can't open file '/svn/hexagon/db/revs/1/1344': Too many open files", 24)
abort: ("Can't open file '/svn/hexagon/db/revs/1/1344': Too many open files", 24)


I tried the clone --stupid approach and then pull to get the rest of the repo, but it fails in the same place with the same error.

3. repo owner

Note to anyone encountering this: it's very likely that your client or server svn version is at fault, not hgsubversion. If you want to try getting a useful resolution, you need to include that information in your report (that is, both the client and server subversion version).

4. repo owner

I am still getting this failure. svn client and server versions below. They don't seem terribly out of date to me.

svn, version 1.8.11 (r1643975)
compiled Dec 17 2014, 21:04:03 on x86-microsoft-windows

svnserve, version 1.8.8 (r1568071)
compiled Aug 20 2015, 12:51:30 on x86_64-pc-linux-gnu


The clone seems to be failing on revisions that contain modifications to many files.

If I do the clone --stupid, then when pulling revisions the first revision comes over and then the 2nd revision always says "abort: The process cannot access the file because it is being used by another process"; traceback:

Traceback (most recent call last):
File "mercurial\dispatch.pyo", line 140, in _runcatch
File "mercurial\dispatch.pyo", line 850, in _dispatch
File "mercurial\dispatch.pyo", line 611, in runcommand
File "mercurial\dispatch.pyo", line 941, in _runcommand
File "mercurial\dispatch.pyo", line 912, in checkargs
File "mercurial\dispatch.pyo", line 847, in <lambda>
File "mercurial\util.pyo", line 677, in check
File "mercurial\extensions.pyo", line 151, in wrap
File "mercurial\util.pyo", line 677, in check
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 704, in generic
File "mercurial\util.pyo", line 677, in check
File "mercurial\extensions.pyo", line 151, in wrap
File "mercurial\util.pyo", line 677, in check
File "hgext\mq.pyo", line 3462, in mqcommand
File "mercurial\util.pyo", line 677, in check
File "mercurial\commands.pyo", line 4966, in pull
File "mercurial\extensions.pyo", line 196, in wrap
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 539, in exchangepull
File "C:/dev/hgsubversion\hgsubversion\wrappers.py", line 481, in pull
File "C:/dev/hgsubversion\hgsubversion\stupid.py", line 709, in convert_rev
File "C:/dev/hgsubversion\hgsubversion\stupid.py", line 238, in diff_branchrev
File "C:/dev/hgsubversion\hgsubversion\svnwrap\svn_swig_wrapper.py", line 551, in get_unified_diff
File "shutil.pyo", line 252, in rmtree
File "shutil.pyo", line 250, in rmtree
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'c:\\users\\rthomson\\appdata\\local\\temp\\tmpcwxd5gsvnwrap_temp\\differr'
abort: The process cannot access the file because it is being used by another process: 'c:\users\rthomson\appdata\local\temp\tmpcwxd5gsvnwrap_temp\differr'


@Augie Fackler You've marked this "won't fix" and you're supposing it to be old subversion servers, but as I posted earlier this isn't the case. How can I work with you to identify the true root cause of the problem as I run into this problem on a regular basis?

I can make a separate issue for the "file is being used" problem if you prefer.

5. repo owner

No idea. I've not seen this in years, and nobody pays me to work on this software, so I'm afraid you're pretty much on your own...