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.

Comments (15)

  1. mfollett 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. Anonymous

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

  3. Anonymous

    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

  4. Anonymous

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

    ---

    hg clone svn+ssh:USERNAME@SERVER/home/svnrepos/REPO/trunk

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

    [command interrupted]

    ---

    Same in command line and in THG itself.

  5. Mark Evenson

    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.

  6. Richard

    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.

  7. Augie Fackler 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).

  8. Richard

    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'
    
  9. Richard

    @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?

  10. Log in to comment