Was die Geschwindigkeit einer SVN 1.6-Zusammenführungsoperation bestimmt

Ich bin überrascht, wie lange es dauert, eine sehr kleine Änderung von einem bestimmten Zweig in einen Stamm zu verschmelzen; 1-2 Minuten, um einige Textzeilen zusammenzuführen, die sich in einer einzelnen Textdatei geändert haben, die nur 2 km lang ist.

Ich möchte, wenn möglich, eine Menge schneller machen, aber ich weiß nicht, wo ich anfangen soll. Ich habe eine schnelle Google gemacht und die möglichen Gründe für langsame Zusammenführungen scheinen alle und alle der folgenden enthalten: -

• Große Repo-Größe (sowohl hinsichtlich der Größe auf der Festplatte als auch der Anzahl der Revisionen).
• Grosser Quellbaum (anscheinend muss SVN den Baum hinunterkriechen, um Änderungen auszuarbeiten)
• Die Version von SVN Server / Client
• Sehr große (mehrere MB) Dateien (wir haben keine sehr großen einzelnen Dateien, also bezweifle ich, dass uns das betrifft)

Ich denke, ich möchte wirklich wissen, wie ich herausfinden kann, welche der oben genannten Punkte die Verschmelzung so langsam machen.

Im Moment bin ich im Unklaren darüber, ob es auf dem Client arbeitet oder auf dem Server arbeitet, der am meisten Zeit beansprucht (ich vermute, es ist der Client, da die CPU-Auslastung auf dem Server nicht groß ist). Ich dachte, dass es die riesige Menge an Mergeinfo sein könnte, die über 100 Merges angehäuft hat, aber ich habe einen Test durchgeführt, bei dem ich alle Merge-Informationen aus ein paar Branches gelöscht habe und dann eine Merge-Operation durchgeführt habe und die gleiche Langsamkeit gefunden habe / p>

Was ich also fragen möchte ist: - * Wie würde man die SVN-Aktivität diagnostizieren / profilieren? * Basierend auf den unten stehenden Informationen, gibt es etwas wirklich Offensichtliches, das die schlechte Leistung verursacht?

Danke

Chris

Hier sind einige Fakten / Zahlen über unser SVN-Setup

• Unser SVN-Repository hat etwa 32000 Revisionen.
• Repo-Größe auf der Festplatte: 8.3GB
• Unsere Entwicklungszweige haben jeweils etwa 1400 versionierte Ordner (19.000 versionierte Dateien)
• SVN Server: 1.6.6 (r40053) (gehostet in Apache auf Ubunto Lucid Lynx)
• Ich benutze Tortoise 1.6.9 unter Win7 (obwohl andere Teammitglieder SmartSVN verwenden und sie die gleiche Geschwindigkeit melden).

Bearbeiten

Es könnte sich lohnen, hinzuzufügen, dass wenn wir verzweigen / zusammenführen, wir von trunk abzweigen und immer den gesamten Zweig zurück in trunk zusammenführen. Also alle Mergeinfo ist auf dem Stamm (und Filialen) Ordner.

Schlussfolgerungen

In meinem Fall schien es der Plattenzugriff zu sein, der den Engpass im Zusammenführungsprozess darstellte - wenn ich meinen Quellbaum von meiner Festplatte auf meine SSD verlagerte, ging die gleiche Zusammenführung von 50 +/- 5s auf 7 + / - 1s.
Die Beobachtung des Tortoise-SVN-Prozesses im Prozess-Explorer während der Zusammenführung war ziemlich bezeichnend: Während der Zusammenführung auf meiner Festplatte lagen die I / O-Bytes für die meiste Zeit zwischen 500 kb / s und 3 mb / s. Auf der SSD waren die E / A-Bytes bis zu 10-20 MB / s. [Etwas verwirrenderweise waren einige Zusammenführungen auf meiner HDD von vergleichbarer Geschwindigkeit (und E / A-Bytes waren ähnlich hoch) wie auf meiner SSD - in diesen Fällen nehme ich an, dass viele der gelesenen Dateien bereits im Windows-Dateicache waren ].

Ich fand die folgende erhöhte Mischgeschwindigkeit

• Zusammenführung von & amp; zu einem Ordner tiefer in der Quellhierarchie: das ist für uns eigentlich keine Option "im wirklichen Leben", da Merge-Tracking fast unmöglich wird, wenn es nicht im Ordner "trunk-level" aufgenommen wird, aber das Zusammenführen viel kleinerer Bäume zeigt der Prozess viel schneller.
• Reduzieren der Größe des Arbeitssatzes, der zusammengeführt wird, hilft (vorausgesetzt, dass Sie die Zusammenführungsoption "Arbeitssatz" verwenden und nicht die vollständig rekursive) - also durch einfaches Löschen der Ordner (aus meinem Arbeitssatz unter Stamm) erhöhte Geschwindigkeit .