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. Deine Argumentation war das bei einem defekt (festplatte?, dateisystem?) ja dann Daten verloren gehen können. Meine Argumentation, das es sich eben auf festplatte und dateisystem verlassen muss, und es nicht aufgabe von Git ist vor defekt einer festplatte oder dateisystem zu schützen. Und genau das tut Git auch nicht. 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.


EDIT: Diesen Text bis zum nächsten Quote hinzugefügt:

Ansonsten ist es auch nicht aufgabe von Dateisystemen Daten abzuspeichern. Sondern es bietet dir nur die möglichkeit daten in container zu Speichern. Ob diese container nun binär oder ein textformat sind (wobei für den computer eh alles binär ist), das ist die aufgabe der Applikation.

Das Dateisystem hilft dir nicht wie du daten abspeicherst oder auslesen kannst, und wie du die datein befüllst mit welcher logik auch immer ist Applikationslogik.

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.

Interessant war hierdran auch das Ted Tso der Hauptentwickler von ext4 und auch ext3 die Anwendungsentwickler kritisierte da sie nicht korrekt mit daten und dateien umgehen, und z.B. nicht wie KDE ihre config in zig dateien aufsplitten sollten, sondern z.B. lieber SQLite nutzen sollten. Ted Tso also ein eintwickler kritisierte also ebenfalls das Anwender ein Dateisystem nicht korrekt nutzen.

Interessant ist das in dieser Diskussion da es das genaue gegenteil von dem ist was du für besser hälst.

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.

Man wählt halt dann ein Versionierungssystem aus wenn man ein versionierungssystem braucht, und dann eine Datenbank, wenn man eine Datenbank brauch, beide sachen definieren sich eben durch das was sie können, und das was man benötigt. Beide sollte aber mit kleinen sowie mit großen Datenmenge umgehen können.

Oder ist deine Argumentation jetzt Versionierungssysteme sind nur für wenig Daten und bei großen Datenmengen nutzt man Datenbanken? Daher wenn du Source Code Verwaltest und die Daten werden zu groß, packst du alles in Datenbanken oder wie?

Wie gesagt, wo ist deine Argumentation? Was willst du mir mit den Text sagen? Ich kann mir aus dem was du geschrieben hast jetzt dein Argument nicht zusammenbauen.

Quote

Du musst schon lesen, was ich schreibe, sonst ist die ganze Diskussion ziemlich willkürlich.

Naja tue ich, aber ich sehe deine Argumente nicht.

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!

Quote

Da kann ich Dir nur empfehlen, Dir mal Programme anzuschauen, die mit großen Datenmengen hantieren und einen Cache anlegen -- fast immer wird da die große Datenmenge in mehrere Einzeldateien in verschachtelten Verzeichnissen aufgeteilt, nicht in eine einzige große Datei gelegt, weil dadurch der Zugriff beschleunigt werden kann. Als Beispiel fällt mir spontan Marble ein.

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

Und jetzt schau dir mal die aufgabe eines Caches an. Bei einem Cache durchsuchst du den Datenbestand nicht. Sondern du weißt bereits worauf du zugreifen möchtest.

Ein Cache funktioniert nämlich simpel z.B. nach dem key/value verfahren. Wenn nun der key einfach der Dateiname ist, dann passt das auch mit der performance, da ich die zieldatei sofort öffnen kann. Da man bei einem Cache ja bereits weiß was man will. Sprich den key weiß.

Das hat jetzt aber mit einen durchsuchen des Datenbestandes nicht zu tun.

Ansonsten stell dir vor der Cache durchnummeriert einfach nur seine dateien und der key steht einfach am anfang der datei. Wenn das öffnen der Dateien irrelevant wäre dann würde das ja wenig ausmachen.

Stattdessen würde man hingehen und den keynamen und den Dateinamen lieber in einer Datei auslagern die man durchgehen kann. Sprich ein index aufbauen.

Beim durchgehen und durchsuchen von dateien geht es immer in der richtung daten in einer datei aufzubauen und nicht in möglich viele dateien aufzusplitten.

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.

Wenn du es aber Performant brauchst mit vielen Zugriffen wäre das wieder ineffizent, dafür gibt es dann wieder Lösungen wie Datenbanken, auch eine simple Datenbank wie Berkeley DB nutzt ein Binäres Format.

Und alle sachen sei es nun Datenbanken oder eine Berkeley DB machen letztendlich eine Logik wie es Git tut. Daran ist auch nichts verwerflich. Natürlich ist es auch ein höherer Programmieraufwand und komplexer, aber das kann mir als nutzer von Git ja egal sein.

Ansonsten was ich schonmal sagte ist das mir deine Argumente fehlen. Ich lese deine Beiträge, sehe aber keine Argumente. Du nennst jetzt ein Programm das ein Cache nutzt und seine Daten in vielen Dateien aufsplittet, okay. Und nun? Die aufsplittung in vielen Dateien ist jetzt sinvoll weil du ein Programm gefunden hast das dies tut?

Soll die existenz jetzt bedeuten das es so besser ist, und automatisch alle anderen Lösungen schlecht sind? Speicherung in einzelne Dateien machen Berkeley DB, SQLite, Git, MySQL (pro tabelle eine datei) etc.

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

Zum einen ist ein Cache etwas anderes als wenn man Datenspeicher hat den man durchsuchen möchte, und zum anderen haben beide wege Vor/Nachteile die man abwegen muss. Ich sehe jetzt nicht das der eine oder der andere weg absolut richtig ist und der andere absolut falsch ist. Es hängt letztendlich davon ab was man tuen möchte.

Quote

Klar, aber wenn man statt Branches in einem Repository anlegen zu müssen einfach billig das Repository klonen kann, hat man ein separates Konzept weniger und die gleiche Funktionalität. So etwas nennt man dann auch Abstraktion.

Wenn man aber branches in einem Repository erstellen kann und das Repro kopieren kann, und beides gleich genannt wird, dann ist es nur keine abstraktion.

Dann werden nur zwei unterschiedliche Dinge gleich genannt und es ist mehr verwirrend als es hilft.

Ansonsten ist Abstraktion generell auch nicht immer gut. Unterschiedliche Dinge sollten auch unterschiedlich sein, und nicht krampfhaft versucht werden sie zu abstrahieren. (Damit sage ich nicht das dies auf Mercurial zutrifft, sondern das ist eine generelle aussage.)

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

Quote

Und was kompliziert ist, ist nicht subjektiv? Jetzt bin ich aber mal auf Deine objektive Definition des Begriffes "kompliziert" gespannt...

Okay, das ist nen guter Einwand. ;)

Quote

Diese Diskussion wolltest Du allerdings unbedingt führen: Ich hatte ursprünglich lediglich angemerkt, dass mir die Manpage nicht gefällt weil ich sie unübersichtlich finde.

Ist korrekt, ich habe dich nach deiner begründung gefragt was du halt kompliziert an Git siehst. Und ja eine Begründung weil du eine übersicht der Befehle in einer manpage anstatt in zwei hast halte ich persönlich für total albern.

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.

Für mich sind das Sinnlos unterschiede die absolut keine relevanz haben. Und was ich sage ist halt wo ich ich das ungefähr einordne. Das ist für mich so als wenn jemand sagt ein Buch (also story, geschichte) ist schlecht, weil ihm die größe des buches z.B. Din A5 nicht gefällt.

Quote

Es bleibt Dir ja unbenommen, das anders zu sehen, albern ist höchstens Dein krampfhafter Versuch, Deine Ansicht in einer Geschmacksfrage als die einzig richtige darzustellen.

Ich versuche nicht meine Sachen als krampfhaft richtig darzustellen, aber ich sage dir eben wie ich deine argumente sehe.

Wenn das für dich gründe sind dann mag das okay sein, für mich sind es keine gründe.

Quote

Übrigens finde ich, dass der "Scherz" ich sei "albern" und andere persönliche Angriffe von der vielfachen Wiederholung Deinerseits nicht unbedingt besser werden.

Ich sagte nicht das "du" albern bist, sondern "ich" deine "Argumente" albern finde. Ansonsten ist für mich "albern" jetzt nicht wirklich ein persönlicher Angriff. Es ist eine flapsige bemerkung von persönlichen angriffen finde ich das aber noch weit entfernt.

Wenn es dir so vorkommt dann tut es mir leid, es ist nicht mein Ziel dich zu beleidigen.

Quote

Wenn außer dummer Sprüche kein Inhalt mehr beizutragen ist, sollten wir die Diskussion lieber beiseite legen, denn sie ist sowieso vom ursprünglichen Thema abgedriftet.

Hast du den ein Beispiel für ein Dummen spruch den ich sagte? Den ich versuche schon normal zu Diskutieren und aus meiner sicht habe ich dazu auch versucht argumente zu liefern.

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?

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.
* Weil die Liste der "High" und "Low" Level befehle in einer anstatt in zwei manpages stehen.
* Weil man das Repository von zeit zu zeit selber verwalten muss.
* Aufteilung der Befehle in Low- und High-Level und zu viele Befehle.

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.
* Es macht für mich kein Unterschied ob die Liste der Befehle in einer oder zwei manpages stehen.
* Man kann von Zeit zu Zeit "git gc" eintippen um den Speicherplatzverbrauch zu reduzieren, und das halte ich nicht für kompliziert.
* 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.

Habe ich was vergessen?

EDIT: Texte etwas überarbeitet.
Last edited: 2009-07-22 18:05:52 +0200 (CEST)