Gibt es ein verteiltes VCS, das große Dateien verwalten kann?

Question

Gibt es ein verteiltes Versionskontrollsystem (git, bazaar, mercurial, darcs usw.), das mit Dateien umgehen kann, die größer sind als das verfügbare RAM?

Ich muss in der Lage sein, große Binärdateien (dh Datensätze, Quellvideo/Bilder, Archive) zu committen, aber ich muss nicht in der Lage sein, sie zu differieren, nur in der Lage sein, zu bestätigen und dann zu aktualisieren Änderungen.

Zuletzt habe ich mir das vor etwa einem Jahr angeschaut, und keiner der offensichtlichen Kandidaten hat das erlaubt, da sie alle so entworfen wurden, dass sie im Speicher nach Geschwindigkeit unterscheiden. Das ließ mich mit einem VCS für die Verwaltung von Code und etwas anderes ("Asset Management" -Software oder nur rsync und Skripte) für große Dateien, die ziemlich hässlich ist, wenn die Verzeichnisstrukturen der beiden überlappen.

Answer 1

Es ist schon 3 Jahre seit ich diese Frage gestellt, sondern, wie der Version 2.0 Mercurial die largefiles extension enthält, das, was erreicht ich ursprünglich suchte:

Die largefiles extension ermöglicht das Tracking großer, inkompressibler Binärdateien in Mercurial, ohne dass eine übermäßige Bandbreite für Klone und Pulls erforderlich ist. Dateien, die als Largefiles hinzugefügt wurden, werden nicht direkt von Mercurial verfolgt. Ihre Revisionen werden vielmehr durch eine Prüfsumme identifiziert, und Mercurial verfolgt diese Prüfsummen. Auf diese Weise werden die großen Dateien in älteren Revisionen des Repositorys nicht benötigt, wenn Sie ein Repository klonen oder Changesets übernehmen. Es werden nur die Dateien heruntergeladen, die für die Aktualisierung auf die aktuelle Version erforderlich sind.Dies spart Speicherplatz und Bandbreite.

Answer 2

Ich denke, es wäre ineffizient, binäre Dateien in irgendeiner Form von Versionskontrollsystem zu speichern.

Die bessere Idee wäre, Metadaten-Textdateien im Repository zu speichern, die auf die binären Objekte verweisen.

Answer 3

Muss es verteilt werden? Angeblich ist die eine große Vorteil Subversion zu den neueren, verteilten VCSes seine überlegene Fähigkeit, mit Binärdateien umzugehen.

Answer 4

Kein freies verteiltes Versionskontrollsystem unterstützt dies. Wenn Sie diese Funktion wünschen, müssen Sie sie implementieren.

Sie können git abschreiben: Sie interessieren sich für rohe Leistung für den Anwendungsfall Linux Kernel-Entwicklung. Es ist unwahrscheinlich, dass sie jemals den Performance-Kompromiss bei der Skalierung zu riesigen Binärdateien akzeptieren würden. Ich weiß nichts über Mercurial, aber sie scheinen ähnliche Entscheidungen getroffen zu haben wie git, indem sie ihr Betriebsmodell an ihr Speichermodell für die Leistung gekoppelt haben.

Im Prinzip sollte Bazaar in der Lage sein, Ihren Anwendungsfall mit einem Plugin zu unterstützen, das Tree/Branch/Repository-Formate implementiert, deren Speicher- und Implementierungsstrategie für Ihren Anwendungsfall optimiert ist. Falls die interne Architektur Sie blockiert und Sie nützlichen Code freigeben, erwarte ich, dass die Core-Entwickler die interne Architektur verbessern. Sie können auch einen Vertrag zur Feature-Entwicklung mit Canonical einrichten.

Der wohl pragmatische Ansatz, und zwar unabhängig von dem spezifischen DVCS wäre ein Hybridsystem zu bauen: implementieren eine Riesen-Datei zu speichern, und speichern Sie Verweise auf Blobs in diesem Laden in die DVCS Ihrer Wahl.

Volle Offenlegung: Ich bin ein ehemaliger Angestellter von Canonical und arbeitete eng mit den Basar-Entwicklern zusammen.

Answer 5

Ja, Plastic SCM. Es ist verteilt und es verwaltet riesige Dateien in Blöcken von 4 MB, so dass es nicht begrenzt ist, sie zu jeder Zeit vollständig in mem zu laden. Finden Sie ein Tutorial über DVCS hier: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

Answer 6

BUP könnte das sein, was Sie suchen. Es wurde als eine Erweiterung der Git-Funktionalität für Backups erstellt, aber das ist praktisch das Gleiche. Er zerlegt Dateien in Chunks und verwendet einen rollenden Hash, um den Dateiinhalt adressierbar zu machen/effizient zu speichern.

• https://github.com/bup/bup
• http://blogs.kde.org/node/4440

Answer 7

Ich kam zu dem Schluss, dass die beste Lösung in diesem Fall die ZFS zu verwenden sei.

Ja ZFS ist kein DVCS aber:

• Sie Platz für Repository über die Schaffung neuer FS
• zuordnen können Sie Änderungen durch die Schaffung von Snapshots verfolgen können
• Sie Schnappschüsse senden können (verpflichtet) zu einem anderen ZFS-Datensatz