2009-07-24T16:29:23 sid burn

[...]

Quote

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.

Mit deinem Code gibt es keine Probleme, Wie gesagt, das problem ist das, das die Leute eine Datei im Truncate Modus geöffnet haben also mittels "open my $fh, '>', ..." und direkt die datei überschreiben.

Dann bin ich ja beruhigt. Ich hätte nicht gedacht, dass es viel Software gibt, die so unfachmännisch mit Dateien umgeht, wie Du das beschreibst -- aber eigentlich darf man sich bei Software über keine Eselei wundern ;-)

Quote

[...]
10^7 Bytes für ein Repository ist aber verdammt wenig, das sind ja nur knapp 10MiB? Das können aber nur sehr sehr kleine projekte/programme sein die so wenig speicher nutzen.

Ich trenne halt größere Dinge auch gerne in mehrere Repositories auf und habe zudem tendenziell eine eins zu eins Beziehung zwischen Branches und Repositories. Aber wer weiß wie das dann mal aussieht, wenn die Versionsgeschichten deutlich länger als ein paar Monate werden...

Quote

[...]

Quote

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

Solche Versionierungen gibt es schon. Basierend jedenfalls auf FUSE.
[...]
Aber ansonsten ist hier wohl das problem was du andeutest, irgendwie muss man dem System sagen was er versionieren soll.

Genau. Ich kenne auch ein paar Programme, die ein Repository als Dateisystem präsentieren und jedesmal committen, wenn jemand etwas speichert. Aber das finde ich höchstens als Backuplösung für ganz spezielle Anforderungen interessant. Bei der Programmierung wird da die Versionsgeschichte unübersichtlich.

Quote

[...]
Aber ansonsten sehe ich auch nicht wo vorhandene Systeme hier komplizierter sind. SVN kennt lediglich "svn commit" und commitet dann alles, bei git entweder manuel mackieren oder ebenso alles sofort commiten.

Die Komplexität der Befehle ist vielleicht auch gar nicht der springende Punkt. Wenn alles im Hintergrund transparent über normale Dateioperationen abgewickelt würde, natürlich nicht nur Commits sondern auch Branches, Merges usw., dann hätte das nicht nur den Vorteil bequem und idiotensicher zu sein, sondern auch den, dass man keine Zusatzsoftware bräuchte, um die Versionskontrolle zum Beispiel in IDEs oder existierende Arbeitsabläufe zu integrieren.

Quote

[...]
Wie willst du dem versionierungssystem beibringen das es jetzt seine daten synchronisieren soll, ein branch erzeugen soll, oder mergen soll ohne das du etwas eingeben musst?
[...]

Naja, das Branchen kann man vielleicht irgendwie durch Anlegen eines Hardlinks auslösen, das Mergen durch lustige Spezialbehandlung, wenn man Daten von einem Branchverzeichnis in ein anderes kopiert, oder so.

Aber wie gesagt, ich weiß gar nicht so genau, wie die Sache im Detail aussehen sollte. Es kann auch sein, dass sich die Idee im Endeffekt als ziemlich dumm erweist =:-)