1

I am trying to clone an svn repository into git on Windows 10. To provide a sense of the size of the repository, it contains 100 revisions and the current (exported) codebase is about 4MB in 430 files. The repository does not have the "standard" root/branch/tag layout.

My "anonymized" command is:

git svn clone https://my_svn_url --prefix=svn/ --no-metadata C:/my_folder_path

The clone command reports "Initialized empty Git repository ..." and I can see the resulting folders, but beyond that, I see a perl process chewing up CPU with nothing happening. I've let it run for about 15 minutes before giving up and killing the processes.

Is there something wrong with my command? Is it just very slow? (I am running on a 2.4GHz i7 laptop and the perl process sits at about 18%). Is it unable to handle the non-standard repository layout?

Zenilogix
  • 1,318
  • 1
  • 15
  • 31

1 Answers1

1

Considering the Git for Windows 2.21 released a few hours ago does fix an obscure git svn hang (issue 1993), make sure to upgrade first and see if the issue persists.

git svn clone, git svn fetch, and git svn rebase all hang with perl.exe using about 18% CPU. Downgrade to 2.20.0 and it all works fine.

SVN repository is via https and requires username and password. 2.20.0 prompts to accept certificate (self signed). 2.20.1 doesn't prompt at all.

See the details in this issue comment.

The OP Zenilogix confirms in the comments the issue is the SVN version used on the server.

I updated the server software (still on the same old server) to 3.6.5 (Dec 2017) and it now appears to be working.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I upgraded as suggested, but now instead of a hang it comes back after a few seconds with: " 4 [main] perl 16792 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump". As before, all I am left with is a bare git repository (has not created anything prior to this failure). I would attach the stackdump, but I don't know where to look for it. – Zenilogix Feb 27 '19 at 15:14
  • @Zenilogix Can you check with `where git` and `git --version` if Git is indeed 2.21? – VonC Feb 27 '19 at 15:16
  • @Zenilogix Can you try with a simplified PATH in a CMD to see if the issue persists? (https://stackoverflow.com/a/54359814/6309) – VonC Feb 27 '19 at 15:19
  • git version 2.21.0.windows.1 … I was initially using a git bash window launched from git extensions; tried opening cmd window, PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\Git\cmd … same result; found stackdump, first line: Exception: STATUS_ACCESS_VIOLATION at rip=00000000000 – Zenilogix Feb 27 '19 at 15:53
  • @Zenilogix Make sure to use the full simplified path I mention in https://stackoverflow.com/a/54359814/6309: not just cmd – VonC Feb 27 '19 at 16:00
  • Not sure I understand the instructions, but the 3 set PATH commands resulted in PATH=C:\Program Files\Git\bin;C:\Program Files\Git\usr\bin;C:\Program Files\Git\mingw64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\ … git command result was same as before – Zenilogix Feb 27 '19 at 16:19
  • @Zenilogix OK, so the issue is not in the PATH then – VonC Feb 27 '19 at 16:20
  • FWIW SVN is hosted on VisualSVN standard edition 2.0.7 on Windows Server 2008 (not R2). It's all old c. 2009 - could this be a factor? – Zenilogix Feb 27 '19 at 16:49
  • 1
    @Zenilogix That is possible indeed. Ideally, you might consider importing that SVN repo into one managed by a more recent SVN server, just for testing, and `git svn` from that server. – VonC Feb 27 '19 at 17:14
  • I updated the server software (still on the same old server) to 3.6.5 (Dec 2017) and it now appears to be working. – Zenilogix Feb 27 '19 at 18:13