Wie gut ist Subversion bei der Speicherung von vielen Binärdateien?

Question

Ich suche nach einem Ort, an dem ich ein paar GB an Dokumenten (hauptsächlich .doc y .xls ). Mein Team hat bereits einen Subversion-Server für die Verwaltung der von uns erstellten Dokumente eingerichtet, daher würde ich diesen vorziehen. Wie gut wird Subversion mit all diesen zusätzlichen Daten umgehen können? Das meiste davon sind Altdaten und werden immer nur eine Version haben, aber es ist möglich, dass ein paar Dokumente aktualisiert werden könnten.

Ich bin gewarnt worden, dass SVN nicht besonders "lots-of-big-binary-files"-freundlich ist. Ich zögere, es auszuprobieren, um zu sehen, ob es funktioniert, da sie immer in der Repository-Historie sein werden, auch wenn ich sie später lösche.

Gibt es Alternativen? Wir brauchen die Möglichkeit, Dokumente zu kommentieren und/oder zu markieren, aber wir können einen Delicious-ähnlichen Dienst in Kombination mit den URLs für die Dokumente in SVN (oder ähnlichem) verwenden.

Später Ich bin nicht so besorgt über die Diffs der Binärdateien, da sie, wie oben erwähnt, nicht viel ändern werden. Ich habe kein Problem mit einem kleinen Problem, wenn sie es tun - es ist nicht schlimmer als SharePoint.

Answer 1

In meiner früheren Firma haben wir Subversion für die Speicherung von CAD-Dateien eingerichtet. Dateien bis zu 100 MB wurden in Subversion gespeichert. Wenn viele Leute große Dateien zu Subversion "hinzufügen", kann der Webserver zu einem Engpass werden. Inkrementelle Übertragungen waren jedoch völlig in Ordnung.

Subversion speichert 'Binärdelta'. Tatsächlich werden auf der Serverseite Binär- und Textdateien bei der Speicherung des "Deltas" genau gleich behandelt. Lesen Sie den Abschnitt "Verbesserungen der Binärdelta-Kodierung" auf Seite http://subversion.tigris.org/svn_1.4_releasenotes.html . Dort heißt es ausdrücklich: " Subversion verwendet den xdelta-Algorithmus zur Berechnung der Unterschiede zwischen Byte-Ketten " (und nicht "Zeichenketten").

Zu Versuchszwecken habe ich die Version 10 von CAD (CATIA-Teiledatei) gespeichert. Bei jeder Version habe ich kleinere Änderungen am Teil vorgenommen und dann die Größe des serverseitigen Repositorys überprüft. Die Gesamtgröße war etwa 1,2x für etwa 10 Revisionen (x - ist die ursprüngliche Dateigröße).

Denken Sie daran, die Eigenschaft svn:needs-lock zu setzen. Meiner Erfahrung nach ist es am besten, "auto props" zu verwenden, um die svn:needs-lock-Eigenschaft anhand der Dateierweiterung zu setzen.

Answer 2

Es gibt einen Unterschied zwischen vielen großen Binärdateien und einer großen Anzahl von Binärdateien.

Nach meiner Erfahrung kommt SVN mit einzelnen Binärdateien von mehreren hundert Megabyte gut zurecht. Die einzigen Probleme, die ich gesehen habe, beginnen bei einzelnen Dateien von etwa einem Gigabyte oder so. Operationen schlagen aus mysteriösen und unbekannten Gründen fehl, möglicherweise kann SVN mit Netzwerkproblemen nicht umgehen.

Mir sind keine SVN-Probleme bekannt, die mit der Anzahl der Binärdateien zusammenhängen, abgesehen von der fehlenden Merge-Fähigkeit und der Tatsache, dass Binärdateien oft nicht effizient als Deltas gespeichert werden können (SVN kann Deltas verwenden).

Also;

• 1000 1MB-Dateien = gut.
• 100 10MB-Dateien = gut
• 10 100MB-Dateien = gut
• 1 Datei >1000MB = keine gute Idee.

Ich hoffe, dass der Umfang Ihrer Dokumente in eine der feinen Kategorien passt :)

Answer 3

Wir haben unser Subversion Kunden, da wir wirklich große Design-/Beratungsaufträge hatten, die eine Versionskontrolle erforderten. Wir hatten nie irgendwelche Probleme damit.

Answer 4

Das hängt davon ab, wie oft die Dateien aktualisiert werden. Es kann nichts über das Zusammenführen von Binärdateien tun, und jedes Mal, wenn es einen Konflikt gibt, werden Sie Schmerzen haben. Ansonsten geht es nur um das Speichern und Abrufen, und das geht zwar nicht so gut wie mit Text, aber immer noch ganz gut.

Answer 5

Ich persönlich verwende Mercurial für solche Aufgaben. Ich habe damit mehrere hundert Gigabyte an Medien gespeichert. Ja, es braucht etwas Speicherplatz, aber Speicherplatz ist billig. Mit Mercurial haben Sie auch den Vorteil, dass es verteilt ist, so dass Sie beim "Auschecken" oder Klonen, wie es in Mercurial heißt, das gesamte Projektarchiv erhalten, nicht nur einen Schnappschuss. Wenn Ihr Server jemals stirbt, sind Sie immer noch im Geschäft.