2009-07-22T09:25:41 sid burn

Quote

Tja und genau das tut Git eben nicht, sondern programmiert um das Betriebssystem herum und erfindet das Dateisystem neu.

Git speichert Daten Binär ab, so wie es etliche andere Programme auch tun. Und diese Dateien speichert es im Dateisystem ganz normal.
[...]

"Normal" ist hier eine Definitionsfrage. Git speichert ein kompliziertes Containerformat, das einem Dateisystemimage ähnelt. Dadurch erhöht sich die Komplexität des Codes, den Git benötigt, um auf seine Repositories zuzugreifen, wesentlich. Meiner Meinung nach ergeben sich dadurch aber andereseits keine nennenswerten Vorteile.

Quote

[...]
Und ein Programm das seine Daten in hunderte von Dateien speichert und von mir aus sogar Textformat erhöht dadurch die Datensicherheit letztendlich kein bischen.

Dadurch erhöht sich zwar die Datensicherheit des Dateisystemes oder der Platten nicht, allerdings wird die Rekonstruktion nach einem katastrophalen Datenschaden leichter, bzw. überhaupt erst möglich. Und das sehe ich bei Versionsgeschichten nunmal als Vorteil.

Um das also nochmal zu betonen: Ich stimme Dir vollkommen zu, dass Backups, RAIDs und andere technische Maßnahmen für die Datensicherheit unverzichtbar sind und dass ein redundanteres oder einfacheres Speicherformat sie keinesfalls ersetzen kann. Für den Fall, dass alle verteilten (Sicherungs-)Kopien böswillig in die Luft gesprengt wurden und nurmehr eine einzige, etwas angekokelte Platte mit einem partiellen Datensatz vorhanden ist, will ich aber immer noch eine Chance zur Datenrettung haben, und wünsche mir daher ein Format, bei dem ich notfalls die Chance habe, die Bytes einzeln von Hand wieder zusammenzusetzen ;-)

Quote

[...]
Was mir gerade übrigens dazu einfällt. Es gab vor nicht alzu langer zeit ein "pseudo" bug in ext4. Pseudo deswegen weil es kein bug war. Wurde allerdiengs als ein ext4 Bug angekündigt der dazu führte das ext4 datenverlust hat.
[...]

Soweit ich gehört habe, ging es dabei um ein Verhalten in ext4, welches das übliche Verfahren zum atomaren Ersetzen einer Datei (temporäre Datei auf dem gleichen Dateisystem erstellen, mit Daten füllen, durch Umbenennen der temporären Datei die ursprüngliche Datei ersetzen) unsicher machte, wenn man hinterher keinen full sync ausführte. Vorrausgesetzt diese Information ist korrekt, so halte ich das durchaus für einen Bug, da nur der Rootbenutzer einen full sync ausführen kann und sich auch so ungefähr jedes Datenbanksystem darauf verlässt, dass dieses atomare Dateiersetzen funktioniert, um Transaktionssicherheit zu gewährleisten.

Quote

Quote

Üblicherweise sind die Datenmengen unterschiedlich und bei sehr großen Datenmengen beginnt ein kompakteres Speicherformat von Vorteil zu sein -- genau das sagte ich aber auch bereits in meinem letzten Post.

Und mir fehlt immer noch eine Begründung. Ja Datenmengen sind unterschiedlich. Das trifft auf Versionierungssystemen zu sowie auf Datenbanken.

Ich meine, dass die relevante Datenmenge bei Datenbanken üblicherweise groß ist, bei Versionskontrollsystemen üblicherweise klein. Ein Versionskontrollsystem speichert lediglich wenige Metainformationen und die Größe der versionierten Daten selber tut wenig zur Sache, da deren Inhalt primär nur abrufbar sein muss, aber nicht irgendwie vom Versionskontrollsystem interpretiert werden muss. Daher könnte man die Metainformationen meiner Meinung nach ohne Probleme als Textdateien ablegen.

Quote

Quote

Allerdings sind einige Dateideskriptoren gegenüber einem riesigen Dateiinhalt eine vernachlässigbare Datenmenge.

Wenn es um Performance geht, dann leider nicht.

Schonmal eine große Datei mit 1 GiB kopiert? und dann gehe mal hin kopiere 1 GiB an Daten aufgeteilt in 1Mio. Dateien. Du wirst überrascht sein was Dateideskriptoren für ein Unterschied machen!

Ich sagte ja auch "einige Dateideskriptoren", nicht "einige tausend Dateideskriptoren". Ein Versionskontrollsystem muss auch bei einem Speicherformat mit vielen Dateien nur größenordnungsmäßig vier Deskriptoren offen halten -- einen für eine Datei mit Metainformationen, zwei für Dateien mit Nutzdaten und einen für eine Datei mit Differenzen.

Quote

Quote

Da kann ich Dir nur empfehlen, Dir mal Programme anzuschauen, die mit großen Datenmengen hantieren und einen Cache anlegen
[...]

Du hattest ursprünglich mal gesagt das es nicht performant wäre die Datenmenge zu durchsuchen.

Zum Durchsuchen zählt auch das Durchsuchen mit Hilfe von Indizes. Ein Dateisystem stellt bereits einen hierarchischen Index in Form des Zugriffes über Dateipfade zur Verfügung. Da man für ein Versionskontrollsystem primär genau so einen Index auf die Revisionsidentifikation und darunter auf die Namen der versionierten Dateien braucht, finde ich es nicht sehr sinnvoll, die eingebaute Unterstützung des Dateisystemes zu umgehen und selbst nachzubilden.

Speichert man in einer großen Binärdatei auch so einen Index, ist das sicherlich nicht weniger performant als der "direkte" Zugriff über das Dateisystem, aber es ist definitiv umständlicher zu implementieren und ich vertrete eben den Standpunkt, dass es keinen Sinn ergibt so einen Umstand zu machen, wenn die Funktionalität doch bereits vorhanden ist.

Quote

[...]
Ansonsten ist Marble eine simple Desktop Applikation und da wirst du auch nie ansprüche haben das der cache jetzt riesig ausgelastet sein wird, ein performance nachteil durch viele dateien ist also vernachlässsigbar, und hier ist der vorteil der leichten implementation.

Zum einen finde ich den Vorteil der leichten Implementation nicht zu vernachlässigen, weil damit auch eine Quelle von Bugs ausgeschlossen wird. Zum anderen solltest Du vielleicht nochmal bedenken, dass so ein hochauflösender Rasterbilddatensatz der Erdoberfläche leicht in der Größenordnung einiger hundert Gigabyte liegen kann, und ein Programm wie Marble auch damit noch klarkommen muss (und kann).

Quote

[...]
Natürlich ist es auch ein höherer Programmieraufwand und komplexer, aber das kann mir als nutzer von Git ja egal sein.

Es ist mir persönlich eben nicht egal, wenn ein Programm umständlicher arbeitet, als es sein müsste. Zum einen vergrößert es meinen Arbeitsaufwand, wenn ich den Code des Programmes lesen will, was ich fast immer irgendwann tue, meistens schon im Rahmen der Testphase um zu beurteilen, ob ich das Programm wirklich benutzen will. Zum anderen finden sich in umständlichem Code tendenziell mehr versteckte Fehler.

Quote

[...]
Die nennung von irgendeiner Software ist jetzt aber kein argument für irgendetwas.

Aber ein Beispiel. In diesem Falle ein Gegenbeispiel zu Deiner Behauptung, niemand käme auf die Idee, so abzuspeichern.

Quote

[...]
Ansonsten ist Abstraktion generell auch nicht immer gut. Unterschiedliche Dinge sollten auch unterschiedlich sein, und nicht krampfhaft versucht werden sie zu abstrahieren.

Das ist zwar eine mehr philosophische Frage, aber ich sehe das anders. Es mag sehr schwer sein für bestimmte Dinge eine geeignete gemeinsame Abstraktionsebene zu finden und nicht nur einen kleinsten gemeinsamen Nenner, aber wenn eine echte Abstraktion gefunden wird, ist diese immer eine Verbesserung gegenüber separaten Konzepten.

Quote

Gutes Beispiel ist wie bereits gesagt der "eval" Befehl in Perl. Macht zwei komplett unterschiedliche Dinge die gleich benannt sind.

Das ist keine Abstraktion, sondern Überladung.

Quote

[...]
Das ist halt das Gleiche wenn man Sprachen vergleicht und mir einer erzählt das Python lesbarer ist weil man einrücken muss. Oder man keine Semikolions braucht und es auch durch ein newline abschliest, oder noch so weitere sinnlose komplett irrelevante sachen wie das man keine klammern nutzt etc.

Das mag für die Funktion irrelevant sein, für den Programmierer ist aber auch die Form interessant. Ich bin durchaus der Meinung, dass man in einer Sprache mit einer für den eigenen Geschmack angenehmeren Syntax besser programmieren kann.

Quote

[...]
Zum anderen ist es auch nicht die feine englische art wenn du mir vorwirfst ich würde persönlich angreifend sein, und du kurz danach sagst das alles was ich bisher geliefert habe dumme sprüche wären und ohne inhalt. Inhalt hatten wir denke ich doch genug?

Ich sagte nur, wir sollten aufhören zu diskutieren, falls uns nur noch dumme Sprüche und kein Inhalt mehr einfielen. Damit wollte ich nicht behaupten, dass Du nichts sinnvolles von Dir geben würdest, sondern etwas plakativ davor warnen, dass die Diskussion zu sehr entgleitet.

Quote

Wenn wir zum ursprünglichen Thema kommen, warum du also Git kompliziert findest zum erlenen kann ich also zusammen fassen, die Argumente aus deiner Sicht.

* Weil Git seine Daten in einer Datei anstatt viele Dateien speichert.

Genereller: Eeil Git ohne guten Grund eine einzige Datei als Container verwendet, und damit alles mögliche komplizierter macht.

Quote

* Weil die Liste der "High" und "Low" Level befehle in einer anstatt in zwei manpages stehen.

Genereller: Weil ich persönlich die gesamte Dokumentation unübersichtlich finde, unter anderem aufgrund der Aufteilung, die mir nicht zusagt. Hier gebe ich aber sofort zu, dass das eine reine Geschmacksfrage ist.

Quote

* Weil man das Repository von zeit zu zeit selber verwalten muss.

Das ist eine Konsequenz aus dem ersten Punkt, ja.

Quote

* Aufteilung der Befehle in Low- und High-Level und zu viele Befehle.

An der Aufteilung in High- und Low-Level-Befehle an sich finde ich nichts auszusetzen. Eher an der schieren Menge. Da fehlen mir auch ein paar clevere Abstraktionen ;-)

Quote

Deine Gründe aus meiner Sicht:

* Als nutzer von Git ist es mir egal wie es seine Daten verwaltet, und komplizierter wird dadurch in der Benutzung auch nichts.

Die Komplexität des Interfaces hängt in der Tat nicht direkt mit dem Design des Backends zusammen. Ich habe halt das unangenehme Bauchgefühl, dass Git generell die Philosophie verfolgt, alles so kompliziert wie möglich zu machen ;-) Und wie ein Backend funktioniert ist mir auch als Nutzer noch nie egal gewesen, ich akzeptiere aber auch, wenn sich jemand gar nicht darum kümmern will.

Quote

* Man kann von Zeit zu Zeit "git gc" eintippen um den Speicherplatzverbrauch zu reduzieren, und das halte ich nicht für kompliziert.

Das ist in der Tat nicht kompliziert, es erscheint mir nur so überflüssig.

Quote

* Als nutzer von Git hat man üblicherweise nur mit den High-level befehlen zu tun, und die Anzahl der Befehle die man lernt ist hier dann nahezu identisch zu anderen. Die Low-Level befehle muss man nicht kennen.

Mindestens gefühlt hat Git dreimal soviele Befehle wie alle anderen jemals erfundenen Versionskontrollsysteme zusammen ;-) Das liegt aber sicher auch an meiner Abneigung gegen die Dokumentation.

Quote

Habe ich was vergessen?

Nichts, was ich bisher schon erwähnt hätte und weitere Gründe erwähne ich jetzt lieber nicht, damit wir diese Diskussion mal beenden können ;-)