git svn clone: branches moved from repo/ to repo/branches/ and “Malformed XML: no element found”

With git 2.8.2 and svn 1.9.4 under Cygwin, when cloning our repository with git svn clone, I hit a brick-wall at a certain commit:

r3640 = eb94... (refs/remotes/svn/trunk)
Found possible branch point: https://.../repo/<branchname> => https://.../repo/branches/<branchname>, 3641
Initializing parent: refs/remotes/svn/<branchname>@3641
Error from SVN, (175009): Malformed network data: The XML response contains invalid XML: Malformed XML: no element found

Observation #1: When cloning with -r3600:HEAD, that is, from a recent-enough commit, the operation succeeds. Tedious experimentation indicated that the problem appears when starting to clone from around 100 revisions before the problematic commit.

  • What is the format of an authors file for git svn, specifically for special characters like backslash or underscore?
  • Local Git Server Setup (using bonobo)
  • Import previous commits using git-svn
  • How can I use git-svn together with Github, and avoid conflicts?
  • How do I resolve a git-svn index mismatch?
  • How to create a git clone with branches of a “subproject”?
  • Observation #2: This appears to happen only for branches of the above form: mistakenly created in the repo root repo/<branchname>, and then moved to repo/branches/<branchname>

    What is the problem and how to fix it?

  • Paired JAR and native library binaries for SVN Java bindings (JavaHL) on Windows?
  • how to use nested branches through git-svn
  • Is it possible to have a subversion repository as a “submodule” in git?
  • Magento staging and production
  • How do you easily unmerge a topic branch in Subversion/git?
  • How to start an SVN project from the command line?
  • One Solution collect form web for “git svn clone: branches moved from repo/ to repo/branches/ and “Malformed XML: no element found””

    Solution: enlarge your --log-window-size value (default: 100).

    Caveat: larger window sizes inhibited the fetching of commits with many newly added files:

    • window size of 7000 failed repeatedly after 3961 new files in a commit
    • window size of 4000 failed after 4927 new files in a commit

    There were actually 8430 new files in the affected commit.

    This is all under Cygwin and I couldn’t reproduce these problems on Linux, so your mileage may vary.

    I noticed a similarity between the observed revision distance that causes the error and the default value of the git svn fetch --log-window-size option: both are 100.

    Using a log window of 4000 solved the problem in my case, others have used even larger values for speeding up the initial clone/fetch operation.

    I have verified the issue by cloning from 10 revisions before the problematic revision and using --log-window-size=1 — it failed again.

    It would be interesting to know whether this is intended behavior or a bug on git-svn’s side, as --log-window-size is documented to speed up the clone/fetching operation, and not as a necessity for fixing some branching issues.

    Git Baby is a git and github fan, let's start git clone.