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.
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?
Solution: enlarge your --log-window-size value (default: 100).
Caveat: larger window sizes inhibited the fetching of commits with many newly added files:
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.