Ich bin auf der Suche nach einer schnellen, aber nicht so dreckigen Art, Schnappschüsse aus einer Reihe von Dateien mit insgesamt etwa 80 Gigs zu machen. Das Problem hier ist, dass viele der Dateien etwa 1 GB groß sind.Versionskontrollsystem für große Dateien?
Was ist das beste kostenlose Versionskontrollsystem für diese Art von Sache?
Ich weiß ZFS ist eine Option, aber ich würde lieber etwas anderes zuerst versuchen.
Subversion wird Ihre> 1 GB Dateien mit gutmütig aplomb zum größten Teil handhaben, aber wenn es viele großen Veränderungen erwarten, dass die Erzeugung von diffs eine Weile dauern ...
Subversion Best practices einen Abschnitt über große Dateien hat:
Eine nette Eigenschaft von Subversion ist, dass es vom Entwurf her keine Beschränkung auf die Größe der Dateien gibt, die es verarbeiten kann. Dateien werden "streamily" in beiden Richtungen zwischen Subversion-Client und Server, mit einer kleinen, konstante Menge an Speicher auf jeder Seite des Netzwerks gesendet.
Natürlich gibt es eine Reihe von praktischen Fragen zu berücksichtigen. Während gibt es keine Notwendigkeit, sich über Dateien im Kilobyte-Bereich (zB typischen Quellcode-Dateien) sorgen, kann die Annahme größerer Dateien eine enorme Menge an Zeit und Speicherplatz (z. B. Dateien, die Dutzende oder Hunderte von Megabyte sind) groß.)
mit zu beginnen, denken Sie daran, dass Ihre Subversion Kopie speichert pristine Kopien aller versionskontrollierten Dateien im .svn/text-base/ Bereich arbeiten. Dies bedeutet, dass Ihre Arbeitskopie mindestens doppelt so viel Platz belegt wie der ursprüngliche Datensatz. Darüber hinaus folgt der Subversion-Client einem (derzeit nicht einstellbaren) Algorithmus zum Festschreiben von Dateien:
. Kopiert die Datei in .svn/tmp/(kann eine Weile dauern und verwendet vorübergehend zusätzlichen Speicherplatz))
. Führt ein Binärdiff zwischen der tmpfile und der ursprünglichen Kopie oder zwischen der tmpfile und einer leeren Datei durch, wenn neu hinzugefügt wurde. (Kann eine sehr lange Zeit zu berechnen, obwohl nur eine kleine Datenmenge könnte letztlich über das Netzwerk gesendet werden)
. Sendet die diff an den Server, bewegt dann den tmpfile in .svn/text-base/
So während gibt es keine theoretische Grenze für die Größe der Dateien, werden Sie müssen sich bewusst sein, dass sehr große Dateien möglicherweise erfordert ein wenig von Patienten warten, während Ihr Client tuckert weg. Sie können beruhigt sein, jedoch, dass im Gegensatz zu CVS, Ihre großen Dateien den Server nicht untauglich machen oder andere Benutzer betreffen.
Wir verwenden jetzt seit ungefähr zwei Wochen Subversion für diesen Zweck, und es funktioniert gut. Ein Check-in in einem Datensatz von etwa 80 Gigs, die über 130.000 Dateien verteilt sind, dauert etwa eine Stunde pro Nacht, um einzuchecken. Die täglichen Deltas betragen 50 MB. Die größte einzelne Datei im Datensatz ist 800 MB. –
Tolles Zeug, Ben. Froh, dass Sie das nützlich fanden. –
ascii oder binär? – Johan
binär - obwohl ich keine modernen Versionskontrollsysteme kenne, die Algorithmen haben, die zwischen ascii und binär unterscheiden. Ich werde es ausprobieren und meine Ergebnisse hier posten. –
Das initiale Commit ist ausgelastet und mit dem file: // - Protokoll überträgt subversion durchschnittlich 1,5 MB pro Sekunde. Ziemlich verdammt langsam. –