2014-01-09 23 views
52

In unserem Projekt haben wir die Entscheidung getroffen, die Build-Zeit durch Verwendung vordefinierter Binärdateien zu reduzieren. Wöchentlich/monatlich erstellen wir eine stabile Version und binden sie an das Repository. Der Build verwendet diese Binärdateien, anstatt alles aus der Quelle zu erstellen.Reduzieren der Größe des .svn-Ordners

Für Build-Geschwindigkeit ist das fantastisch. Aber es überrascht nicht, dass es wirklich die SVN-Checkout-Größe aufbläht. Unser Kofferraum befindet sich derzeit bei ~ 22   GB. Mir ist klar, dass dies nicht die beabsichtigte Verwendung von Subversion ist. Aber wir haben im Moment keine Alternative.

Aber ich möchte die aktuelle Situation verbessern. Der Ordner .svn trägt erheblich zur Größe des Trunks auf der Festplatte bei. Wenn die Binärdateien aktualisiert werden, scheint es mehrere Basen im .svn-Ordner zu behalten. Das heißt, wenn eine Binärdatei 4   GB ist, gibt es eine Kopie in der .svn. Wenn es aktualisiert wird, dann enthält der Ordner .svn die ursprüngliche Basis plus die neue Basis und bulks bis zu 8   GB für diese eine Datei.

Ist es möglich, Subversion zu sagen, keine Basis im Ordner .svn für bestimmte Dateien zu halten? Durch Google fand ich eine ähnliche Frage, How to decrease .svn folder size?.

Die Antwort Simon erhielt, war

  • Verwenden Sie einen Teil-Kasse (die nicht für mich arbeiten, wie ich die Binärdateien benötigen)
  • Dies ist noch nicht eine Funktion von Subversion
  • diskutiert wurde , wird aber kein Merkmal, bis mindestens Subversion 1,8

zum Glück für mich seine Subversion 1.8 ist erschienen. Wurde diese Funktion hinzugefügt?

Ich habe es in the release notes nicht bemerkt. "Directory and property storage reduction" sieht vielversprechend aus.

+1

Dies ist nicht wirklich, wo Subversion glänzt - Sie sollten in Artefakt oder Nexus suchen, um die Artefakte zu speichern und sie mit Ihrem Build-Skript auflösen (abholen). – thekbb

+0

Leider wussten wir das. Aber es ist einfach so bequem, Svn zu verwenden. In der Vergangenheit haben wir bei einem anderen Projekt Maven eingesetzt. Aber anscheinend hat das einen schlechten Geschmack im Mund vieler Leute hinterlassen. Als nächstes kam ein benutzerdefiniertes Tool, das ich nur als Maven beschreiben kann (aber das löste natürlich alle Probleme von Maven). Auch das hat einen schlechten Geschmack hinterlassen. In unserem neuesten Projekt haben wir gerade svn genutzt. –

Antwort

49

Es gibt keine Möglichkeit, die Notwendigkeit, Pristines zu diesem Zeitpunkt zu speichern, loszuwerden. Es wurde darüber gesprochen, aber es ist eigentlich kein einfaches Problem zu lösen, weil es so viele verschiedene Anwendungsfall-Situationen gibt, die durch das optionale Entfernen dargestellt werden.

With 1.7 the pristine storage was changed und in einigen Fällen können Sie die Situation sogar als schlimmer als vor 1.7 sehen. Pristinen werden jetzt in Dateien gespeichert, die durch den Hash des Unbereinigten benannt werden. Wenn Sie also mehrere identische Dateien haben, werden keine doppelten Pristinen gespeichert. Wir reinigen aber auch keine Prismen mehr. Also bauen sie einfach weiter auf. Sie können unbenutzte Prismen auslösen, die mit svn cleanup entfernt werden sollen.

Es gibt einen Punkt, unbenutzte Pristines herum zu halten, wenn Sie zwischen den Zweigen wechseln, müssen wir nicht mehr Dinge herunterladen, für die Sie in 1.8 bereits den ursprünglichen Wert haben.

+0

Danke Ben. Ich vermutete, dass dies die Antwort sein würde. Aber ich hoffte anders, nehme ich an. Der Svn Cleanup Tipp ist praktisch zu wissen. Wir vermuten, dass es die extra Pristine (s) entfernen könnte, aber noch nicht getestet hatte. Ich mag es, dass ein MD5 verwendet wird, um nur einzigartige Kopien zu behalten. Aber das Entfernen alter Kopien scheint nicht korrekt zu sein. Branch Switching ist ein Szenario, das dieses Verhalten unterstützt. Aber ich "ahnte", dass das Alte immer öfter nicht mehr benutzt wird. d. h., es wird nur Speicherplatz beanspruchen. Während unsere, nicht empfohlene, Verwendung von svn dies zu einem spürbaren Nachteil macht, denke ich, dass es auch für normale Projekte gilt. –

+0

Wir stimmen zu, es gibt ein Problem, das auf dieser Seite offen ist: http://subversion.tigris.org/issues/show_bug.cgi?id=4071 –

+2

Das ist großartig, zusammen mit [svn update --set-depth = exclude] (http: //stackoverflow.com/a/8446590/1904815) das hat mir 12 GiB gespart. – JonnyJD

19

Für diejenigen TortoiseSVN Client Cleanup-Befehl statt svn cleanup Befehl können .svn Ordner Größe, indem sichergestellt wird verringert werden, dass Vacuum unberührte Kopien Option aktiviert ist:

enter image description here

Außerdem ist es empfehlenswert, Bereinigung auf der obersten Ebene der Arbeitskopie, wie angegeben here.

[Bearbeiten]

Nach this answer und SVN change log, svn cleanup hat eine Option, unberührte Kopien Vakuum (/vacuum). Dies geschieht standardmäßig ab 1.8.