git svn Klon: Zweige von Repo/in Repo/Zweige/und verschoben "Malformed XML: kein Element gefunden"

Question

Mit git 2.8.2 und svn 1.9.4 unter Cygwin, beim Klonen unseres Repository mit git svn clone, traf ich einen Ziegelstein -Wall bei einem bestimmten 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: Wenn sie mit -r3600:HEAD Klonieren, das heißt, aus einer aktuellen Commit-genug, gelingt es die Operation. Langwierige Experimente zeigten, dass das Problem auftritt, wenn mit dem Klonen von etwa 100 Revisionen vor dem problematischen Commit begonnen wird.

Beobachtung # 2: Das scheint für Zweige der obigen Form nur geschehen: versehentlich in dem Repo-Stamm erstellt repo/<branchname>, und zog dann nach repo/branches/<branchname>

Was ist das Problem und wie man es beheben?

Answer 1

Lösung: vergrößern Sie Ihren --log-window-size Wert (Standard: 100).

Caveat: größere hemmten Fenstergrößen das Abrufen von Commits mit vielen neu hinzugekommenen Dateien:

• Fenstergröße von 7000 wiederholt nicht nach 3961 neuen Dateien in einem
• Fenstergröße begeht von 4000 nach 4927 gescheitert neuen Dateien in einem Commit

Es gab tatsächlich 8430 neue Dateien in der betroffenen Festschreibung.

Dies ist alles unter Cygwin und ich konnte diese Probleme unter Linux nicht reproduzieren, so dass Ihre Laufleistung variieren kann.

---

bemerkte ich eine Ähnlichkeit zwischen der Revisions Entfernung beobachtet, die den Fehler und den Standardwert der git svn fetch --log-window-size Option wird: Beide sind 100

ein Protokollfenster von 4000 löste das Problem in meinem Fall verwenden, others haben noch größere Werte für die Beschleunigung der anfänglichen Clone/Fetch-Operation verwendet.

Ich habe das Problem durch Klonen von 10 Revisionen vor der problematischen Revision verifiziert und --log-window-size=1 verwendet - es ist erneut fehlgeschlagen.

Es wäre interessant zu wissen, ob dies ein beabsichtigtes Verhalten oder ein Fehler auf der Seite von git-svn ist, da --log-window-size dokumentiert ist, um die Clone-/Abrufoperation zu beschleunigen, und nicht als eine Notwendigkeit, einige Verzweigungsprobleme zu beheben.