2009-07-22T21:49:31 sid burn

[...]
Und das absolut alles ausfällt, naja so etwas vertrauen muss man schon haben. Wenn irgendwie 4 rechner (github, server, 2 eigene pcs) zum beispiel ausfallen evtl sogar weltweit verteilt (andere entwickler?) und das auch noch alles zufällig gleichzeitig kommt es mir vor als wenn wir wohl größere probleme haben anstatt sich um sein source code zu kümmern.

Naja, ich gehe halt aus purer Paranoia immer erstmal davon aus, dass ich auch Daten verwalten will, die ich nicht öffentlich zugänglich machen will, bei denen ich also selbst für sämtliche Sicherheitskopien und deren Isolation von der Außenwelt sorgen muss. Ferner gehe ich davon aus, dass ein Gegner mit nahezu unbegrenzten Resourcen existiert, der ohne Rücksicht auf Kollateralschäden meine Daten klauen oder kaputt machen will. Vor diesem Hintergrund will ich dann immer noch ein bischen Sicherheit haben, auch wenn ich mir bewusst bin, dass das kaum noch möglich ist, da ich nur begrenzt Zugriffskontrollen einbauen kann, die mich selbst daran hindern, an meine Daten zu kommen, sollte ich unter Fremdeinfluss stehen ;-)

Quote

[...]
Aber unabhängig davon, ich weiß nicht inwiefern bei Git ein Recovery möglich ist. Nur weil es eine Binärdatei ist bedeutet es ja nicht das deswegen kein recovery mehr möglich ist. Ein kaputtes Dateisystem kannst du ja auch reparieren, und viele andere Programme bieten ja auch ein recovery an, für binärdateien.

Ok, wenn es da ein gutes Werkzeug für Git gäbe, wäre das ein Argument.

Quote

[...]
Um ein Beispiel zu nennen. man hat eine datei "config.ini", möchte sie auslesen, etwas verändern und die datei danach neu schreiben. Das was die gängigen C Programmierer machen ist dann nach Perl Code Portiert folgender halb pseudo Perl Code.

Code (perl): (dl )

1
2
3
4
5
6
7
8
9
10

open my $read, '<', 'config.ini' or die ...;
# es wird nun die config eingelesen und bearbeitet etc.
my $config = ...
close $read;

# config datei wird wieder geschrieben
open my $write, '>', 'config.ini' or die ...;
# die config datei wieder schreiben
print $write....
close $write;

Das ist natürlich blöder Code, ich dachte eher an so etwas:

Wenn letzterer Code mit ext4 immer noch derart funktioniert, dass anderer Code der nebeläufig ausgeführt wird, entweder komplett die alte oder komplett die neue Konfiguration sieht, und dass anderer Code, der später ausgeführt wird, komplett die neue Konfiguration sieht, dann sehe ich da auch keinen Bug.

Mir hat jemand erzählt, bei ext4 reiche fsync plus rename nicht mehr aus, damit andere Prozesse danach auch wirklich die synchronisierten Daten sehen, weil das rename aufgrund der Delays beim Schreiben von Metainformationen dann auch nicht mehr atomar sei, und man könne das nur verhindern, indem man hinterher den Kernel anweise sämtliche I/O-Puffer zu flushen, was zum einen nicht portabel möglich ist und zum anderen Rootrechte erfordert. Ich habe diese Information allerdings nicht selbst überprüft, sondern mich nur ein wenig gewundert.

Quote

[...]

Quote

Ich meine, dass die relevante Datenmenge bei Datenbanken üblicherweise groß ist, bei Versionskontrollsystemen üblicherweise klein.

Naja das sehe ich nicht ganz so. Wenn ich mal auf unserer Arbeit die Datenbanken für unsere Webseiten betrachte. Der durschnitt der Datenbanken liegt bei ca 2 MiB. so ca 10 Webseiten liegen im 5-10 MiB Bereich und unsere größte ist lediglich bei ca. 200 Mib. Und das für über 100 Webseiten.

Unser CMS System was wir entwickeln hat aber durch die History knapp einen verbrauch von 70 MiB. Zumindest als ich es in Git Importiert habe. Bei SVN selber müsste das vielleicht nochmal größer sein.

Hmm, ich bin halt eher Datenbanken in der Größenordnung von 10^12 Bytes und Repositories im Bereich 10^7 Bytes gewöhnt. Dann kommt aber hinzu, dass ein Versionskontrollsystem die meiste Zeit nur mit den Metainformationen herumrechnen muss, die nur einen Bruchteil des ganzen Repositorys ausmachen, während es die eigentlichen Nutzdaten nur gelegentlich und meistens unverändert durch die Gegend schieben muss.

Quote

[...]

Quote

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.

Sofern dieser überhaupt nutzbar ist. Wenn ich in meinen Sourcecode nach einer Funktion suchen möchte, inwiefern kann mir dann die Hirachie der Verzeichnise und Dateien dafür behilflich sein?

Gar nicht, aber ein Versionskontrollsystem tut so etwas auch selten bis gar nicht. Und eine riesige komprimierte Datei, die man erst stückweise dekomprimieren und von der man dann noch Teile ausblenden muss, ist auch nicht gerade ideal nach einem String zu durchsuchen.

Quote

[...]

Quote

Da fehlen mir auch ein paar clevere Abstraktionen ;-)

Welche den als Beispiel? ;)

Sobald ich mir darüber im klaren bin, wie ich das wirklich haben will, schreibe ich selber ein ordentliches Versionskontrollsystem ;-)

Auf jeden Fall hätte ich gerne etwas, was mit ganz wenigen Operationen auskommt. Am besten präsentiert sich ein Branch einfach als Dateisystem / Verzeichnis und versioniert sich automatisch, während ich darin arbeite, das aber so intelligent, dass nicht jedes Speichern zwischendurch um etwas auszutesten, permanent in der Versionsgeschichte abgelagert wird -- ich weiß nur noch nicht, wie man das am intelligentesten anstellt. Vielleicht, indem man verschachtelte Transaktionen zulässt und damit mehrere Änderungen bündeln kann. Oder noch besser, indem man die Konzepte Branch und Transaktion / Commit in einer neuen Abstraktion vereinigt, die Fähigkeit zur beliebigen Verschachtelung hinzufügt und dann eine hübsche Schnittstelle dafür entwickelt...