Git Design Entscheidung über das Speichern von Inhalten statt Unterschiede

Ich konnte die Antwort nicht mit einem schnellen Google finden, aber ich glaube, es läuft auf ein einfaches "Es ist egal, weil Speicherplatz billig ist".

Das Speichern von Revisionen in einem Quellcodeverwaltungstool ist schwierig. Wenn Sie nur den Unterschied zwischen der vorherigen Revision und der aktuellen speichern, haben Sie zwei Probleme:

1. Die letzte Revision (der übliche Fall) erfordert die meiste Arbeit, da der Code diese Revision zusammenstellen muss, indem er jede Revision zusammenfügt.
2. Jeder Fehler (z. B. ein Festplattenfehler) für eine Revision beschädigt den Zugriff auf jede spätere Revision.

Ich glaube, dass die meisten modernen VCS die aktuellste Version speichern (aus Performance-Gründen), und Unterschiede, wenn sie verwendet werden, werden verwendet, um in der Zeit zurückzugehen, nicht vorwärts.

Ein Artikel, der sich mit diesen (und verwandten) Problemen befasst, ist Repository-Formate . Dies war einer der Artikel, die meine Entscheidung beeinflusst haben, vor ein paar Jahren nach Git zu ziehen. Hier ist ein Auszug:

  

Angesichts dieses Arguments sollte klar sein, dass die Repository-Struktur von git besser ist als andere, zumindest für das Nutzungsmodell von X.org. Es scheint einige interessante Eigenschaften zu enthalten:

     

1. Dateien mit Objektdaten werden niemals geändert. Nach dem Schreiben ist jede Datei ab diesem Zeitpunkt schreibgeschützt.

  

2. Die Komprimierung erfolgt offline und kann verzögert werden, bis die primären Objekte auf den Sicherungsmedien gespeichert wurden. Diese Methode bietet eine bessere Komprimierung als jeder inkrementelle Ansatz. Dadurch können Daten auf der Festplatte neu angeordnet werden, um sie an die Verwendungsmuster anzupassen.

  

3. Objektdaten sind inhärent selbstüberprüfend; Sie können ein Objekt im Repository und die Escapeerkennung nicht ändern, wenn das Objekt zum ersten Mal referenziert wird.

  

Lassen Sie mich Ihre Missverständnisse klären:

  

Könnte jemand mir eine Idee geben, warum git-Entwickler eine Design-Entscheidung getroffen haben, den Inhalt von Dateien (Blobs) zu speichern, wenn also der Inhalt geändert wird, muss ein neuer Blob erstellt werden?

Eine ziemlich gute Erklärung des (anfänglichen) Git-Designs findet sich in Tom Preston-Werners Der Aufsatz Git Parabel (zusätzlich zu dem, der mit Greg Hewgill antwortet ).

Die Idee dahinter ist, dass in einer neuen Revision in der Regel nur wenige Dateien aus einer großen Anzahl von Dateien in einem Projekt geändert werden, so dass nur verschiedene Versionen des Dateiinhalts gespeichert werden können. Dies ist die gleiche Idee, die Subversion in seiner "billigen Kopie" -Technik verwendet (es verwendet Hardlinking, IIRC).

Auch der Inhalt der Datei ist zlib (deflate) komprimiert (oder genauer gesagt, jedes Objekt in der git-Repository-Datenbank ist komprimiert, einschließlich der comit-Objekte).

  

Ich glaube, dass Subversion Revisionen statt Inhalte speichert. Wenn sich der Inhalt also ändert, verfolgt er einfach die Unterschiede zwischen den beiden. Könnte es nicht auch so gemacht haben? Was ist der Vorteil des Speicherns von Inhalten anstelle von Revisionen?

Ich verstehe nicht, was Sie hier sagen wollten.

Wenn das Speichern von Unterschieden Speicherplatz spart, dann möchte ich Ihnen zusätzlich zu dem "losen" Format sagen (wo jeder Blob, dh jeder (unterschiedliche) Inhalt einer Datei in einer separaten Datei in% gespeichert wird. co_de%) hat auch das 'gepackte' Format , in dem viele Objekte in deltaförmiger Form gespeichert werden, wobei binäres Delta aus der LibXDiff-Bibliothek verwendet wird.

Dieses Format wurde für die Netzwerkübertragung erstellt (großer Speicherplatz ist zwar billig, aber die Bandbreite nicht) und wurde ebenso wie das Festplattenformat angepasst. Dieses Format ist sehr effizient, eines der effizienteren, wenn nicht effizientesten Versionssteuerungssysteme, was git-Repositories zu einem der kleinsten Versionskontrollsysteme macht. Abhängig von den Umständen kann full clone des git-repository (welches den vollständigen Verlauf enthält) kleiner sein als das entsprechende Subversion checkout (enthält zusätzliche Kopie der ursprünglichen Änderungen, so dass .git und svn diff arbeiten ohne Notwendigkeit der Netzwerkübertragung, mit angemessener Geschwindigkeit).

Dieses Design ('loose' und 'packed' Format) hat den Vorteil eines sehr effizienten Packens, hatte aber den Nachteil, dass Sie manuell mit " svn status " neu packen mussten (nicht für Festplattenspeicher, sondern für Performance - Datenträger) I / O); Heutzutage packen die meisten git-Befehle das Repository (sicher) bei Bedarf neu.