Quote

Es geht mir hier aber eben gerade nicht um die Ebene oder die Art und Weise, wie Datensicherheit geboten wird, sondern darum, dass beim Design darauf geachtet wird, dass sie auf vielen Ebenen vorhanden ist.

Genau das ist ja das Problem. Wenn man eine Versionierungssystem schreibt dann muss man eben nicht darauf achten das die Grundlage hoffentlich okay ist, und jeden Fall vorsehen und drum herum Programmieren.

Git Speichert Daten im Dateisystem. Das das Dateisystem das korrekt macht, dies korrekt abspeichert und das die Festplatte nicht kaputt geht etc. ist nicht das Problem von Git, es muss erstmal davon ausgehen das alles korrekt ist.

Möchtest du dich vor solchen Sachen schützen musst du eben andere Software oder Technologien nutzen die dich davor schützen. Das wären dann eben RAID oder ein Backup System.

Es sollte definitiv nicht Sinn sein das jedes programm auf den Fall eines Festplattenausfalls, probleme mit dem Dateisystem oder sonstiges umgehen kann.

Quote

Bei Datenbanken ergibt das allerdings einen gewissen Sinn, bei Versionskontrollsystemen nicht.

Und es macht bei einer Datenbank sinn, weil?
Und es macht bei einem Versionierungssystem kein Sinn, weil?
Du musst aussagen schon begründen, so sind sie pure willkür.

Quote

Man kann immer abwägen, ob ein bestimmtes Speicherformat mehr Vor- oder Nachteile bringt. Ein redundantes Textformat wäre bei einer Datenbank wohl kaum angebracht,

Es wäre nicht angebracht, weil? Wo sind die Argumente?

Quote

bei einem Versionskontrollsystem für ein paar Byte Metainformationen allerdings schon.

Und warum sind sie bei einen versionierungssystem angebracht? Argumente?

Ich sage es mal aus dem bisher oberen gesagten. Es macht bei beiden kein Sinn. Beide Programme müssen sich auf ihren unterbau verlassen können das dieses korrekt ist, wie bereits gesagt.

Es macht bei beiden kein Sinn wenn sie "versuchen" irgendetwas zu implementieren um probleme zu umgehen die sie sowieso nicht lösen können.

Quote

Solche "Features", wenn sie denn überhaupt existieren (eigentlich fällt mir überhaupt nur Oracle ein, als Datenbank, die das macht), verwende ich auch nicht gerne.

Naja ob du sie gerne verwendest ist ja irrelevant. Ansonsten kann soetwas MySQL. PostgreSQL nicht (Ich muss unbedingt mal PostgreSQL nutzen, mag soetwas aber auch nicht, sprich RAW Devices).

Quote

Etwas anderes habe ich ja auch nicht behauptet. Ich will nur, dass jede Software, die ich verwende, in gewissem Maße Rücksicht auf Datensicherheit nimmt.

Und das halte ich persönlich für albern. ;) Eine Software muss auf das worauf es aufbaut vertrauen können das es korrekt ist. Wenn es eine Datei speichert muss es davon ausgehen das die datei korrekt gespeichert wird.

Sollte ein Fehler in der Datei sein weil das Dateisystem etwas meldet, schelcht ist, oder weil die festplatte kaputt ist, dann ist dafür kein Anwendungsprogramm zuständig. Möchtest du dich davor schützen musst du RAIDs nutzen und Backups fahren.

Und eine Speicherung in mehrere Dateien ist hier weniger Sicherer als die Speicherung in einer Datei. Hat eine Festplatte z.B. ein defekt und zerstört dabei eine datei dann ist das einzig sinvolle die daten aus einer nicht beschädigten quelle zu holen.

Und das jedes Programm auf solch ein Fehler reagiert sollte sehe ich ebenfalls als verschwendete Energie an, möchtest du dich davor schützen hast du ja eben dadruterliegende Technolgien wie RAIDs die dafür zuständig sind.

Quote

Dazu gehört eben, dass man nicht an völlig unsinnigen Stellen auf Kosten von Robustheit und Datensicherheit auf Geschwindigkeit optimiert.

Unsinnig wäre es eher an Stellen zu "Optimieren" die weder die Datensicherheit erhöhen und letztendlich absolut gar nichts bringen können.

Quote

Ferner frage ich mich auch, warum eine Software, die nur Quellcode verwalten und versionieren soll, einen Dateisystemtreiber enthalten sollte, welchen es ja bereits an anderer Stelle gibt. So etwas führt unnötig zusätzliche Fehlerquellen ein. Dann ist das ganze noch, auch im Sinne der Performanz, in C geschrieben, was wieder zusätzliche Fehlerquellen eröffnet und den Code unnötig komplexer macht, als wenn man statt eines Makroassemblers eine echte Programmiersprache mit Abstraktionsfähigkeiten verwendet hätte.

In welcher Sprache sie das Programmieren kann mir volkommen egal sein, solange die Software das tut was sie soll. Ansonsten wird soetwas deswegen in der Anwendung programmiert da Git ja auch auf unterschiedlichen Betriebssystemen arbeiten soll.

Quote

Auch hier legst Du mir wieder Dinge in den Mund, die ich nie gesagt habe...

Ich lege sie dir nicht im Mund, das ist eher eine generelle Aussage.

Quote

In diesem Falle Platzeffizienz, was meiner Meinung nach deutlich aus dem Kontext zu erkennen war.

Für mich nicht, bei effizenz sehe ich eher die Performance. Ansonsten bei Platzeffizenz, da ist Git besser als andere. Von daher ist Git effizent.

Quote

Das mag vielleicht bei einigen aktuellen Betriebssystemen so sein, allerdings sehe ich keinen Grund, warum das prinzipiell immer so sein sollte.

Das wird deswegen prinzipell immer so sein, weil wenn du eine Datei öffnest das Betriebssystem Ressourcen anfragen muss und frei geben muss.

Quote

Im Gegenteil kann ich mir zum Beispiel gut vorstellen, dass das Öffnen und Auslesen von mehreren kleinen Dateien aus einer großen komplexen Verzeichnisstruktur, viel schneller geht als das Öffnen und Herumsuchen in einer einzigen großen komprimierten Datei.

Ich nicht, und bisher sonst wohl auch niemand. Daher werden sachen wo es auf performance ankommt wie auch Datenbanken immer ein Binärformat genutzt, und nicht direkt das dateisystem und ein haufen von dateien.

Quote

Ja, das Vereinheitlichen von Konzepten um eine neue mächtigere Abstraktionsebene zu schaffen ist tendenziell meistens eine gute Idee.

Wenn ein Konzept vereinheitlicht würde dann ja, aber das sehe ich nicht. Den du kannst ja auch innerhlab eines Repros branches anlegen, und das ganze repro dann nochmals kopieren.

Während das ganze dann wohl bei mercurial bei beiden branches heißt für zwei unterschiedliche dinge, dass ist dann doch eher ein Designfehler. So wie bei perl ein Designfehler ist das "eval ''" und "eval {}" zwei unterschiedliche dinge gleich benannt sind.

Quote

Richtig, deswegen sagte ich ja auch schoneinmal, dass das alles Geschmackssache ist.

Wenn es nur geschmackssache ist, dann kann Git ja nicht kompliziert sein. Da geschmack subjektiv ist.

Quote

Unterschiedlichen Leuten sind einfach auch unterschiedliche Dinge wichtig -- wer zum Beispiel schlecht sieht, für den mag eine ungünstig gewählte Schriftart tatsächlich ein Ausschlusskriterium sein ;-)

Was ich eher zum ausdruck bringen wollte.

Deine Argumente sind einfach albern. ;) Darüber zu Diskutieren ob die doku in eine oder zwei manpages aufgeteilt ist, ist volkommen irrelevant. Das Niveau ist das gleiche als wenn mir ein Python Programmierer sagt das Python besser ist, weil man die Klammern "{}" weg lassen kann.

Das ist sowas von wayne, und sowas von komplett irrelevant.