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.

  • Why are git submodules incompatible with svn externals?
  • Is there an acceptable Linux targeted GUI client for git-svn?
  • What are the advantages of git over git-svn?
  • Questions on workflow for a team using a git-svn repo
  • Drawbacks of using GIT-SVN over other SVN clients?
  • git-svn merging between multiple remotes
  • 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?

  • Failed importing code from SVN to GIT - SVN trunk is empty
  • Is there a way to automatically poll svn for a released lock?
  • Is the Subversion 'stack' a realistic alternative to Team Foundation Server?
  • Getting `svn: E160013:` when merging from command line
  • Using TortoiseSVN how do I merge changes from the trunk to a branch and vice versa?
  • SVN, GIT or Mercurial for local servers
  • 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.