Jemand zu Hause?![[twitter]](/battie/theme/default/icons/twitter.gif){kind=icon}
Leser: 40
+32 replies![[default_avatar]](/battie/theme/default/default_avatar.gif){kind=avatar}
![[Homepage]](/battie/theme/default/homepage.gif)
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
+3 replies
+2 replies
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
2009-07-15T09:01:30 pqalso ein versionierungssystem würde ich nie als overkill bezeichnen. ich habe schon erlebt, wie es sein kann, in einer firma anzufangen, die erst ein jahr zuvor mit CVS angefangen hat. du kriegst einfach keine info mehr darüber, was vorher passiert ist.
also, versionierungssystem halte ich für pflicht, und ein einfaches svn aufsetzen ist wirklich in wenigen minuten getan.
+3 replies
+2 replies
Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
2009-07-15T08:56:14 pqIch habe mich beim ersten Mal verklickt, sorry. _blush_edit: ah, der verschiebe-kommentar ist gelöscht. jetzt versteh ichs noch weniger...
eigentlich wird beim verschieben das ziel-board automatisch eingetragen...
+23 replies
+22 replies
+2 replies
2009-07-15T17:37:51 tophovenWas wäre denn besser für einen Debian Linux Server geeignet? CVS oder Subvention?
+19 replies
+18 replies
+17 replies
2009-07-18T15:47:21 murphyWenn die Komplexität ein Problem darstellt, dann würde ich von Git auf jeden Fall abraten -- es ist zwar mächtig, aber ich kenne kein modernes VCS, das noch umständlicher zu benutzen ist.
+15 replies
+14 replies
2009-07-19T01:24:55 murphyWarum, zum Beispiel, muss man bei Git von Hand eine Garbagecollection des Repositorys anstoßen?
QuoteWarum ist das Repository überhaupt in einem komischen Binärformat abgelegt, das ich nicht notfalls von Hand kontrollieren kann?
QuoteWarum baut man in einem modernen VCS absichtlich keine Unterstützug für das Umbenennen von Dateien ein?
QuoteFerner erscheint mir die Aufteilung von Git in bestimmt ein dutzend einzelne low-level Kommandozeilenprogramme plus weitere high-level Kommandozeilenwrapper unübersichtlich.
+13 replies
2009-07-19T02:41:45 sid burn2009-07-19T01:24:55 murphyWarum, zum Beispiel, muss man bei Git von Hand eine Garbagecollection des Repositorys anstoßen?
Wenn das jedesmal bei jeden commit gemacht werden würde, oder push, dann würde die commit und push phasen zu lange dauern. [...]
QuoteQuoteWarum ist das Repository überhaupt in einem komischen Binärformat abgelegt, das ich nicht notfalls von Hand kontrollieren kann?
Das Repository wird LZMA Komprimiert abgespeichert, um Speicherplatz zu sparen. Aber auch um den Traffic über das Internet zu reduzieren. Und warum willst du ihn von Hand kontrollieren?
Quote[...] Wenn man eine Datei umbenennt mit seinen herkömlichen mitteln sagen wir einfach "mv" unter Linux, dann erkennt Git das auch selbstständig. [...]
QuoteQuoteFerner erscheint mir die Aufteilung von Git in bestimmt ein dutzend einzelne low-level Kommandozeilenprogramme plus weitere high-level Kommandozeilenwrapper unübersichtlich.
Du musst die Low-Level Sachen auch nicht lernen/nutzen.
+12 replies
QuoteBei einem Versionskontrollsystem ist es mir wichtig, dass ein Datenverlust so gut wie ausgeschlossen werden kann. Ein binäres Repository, noch dazu in nur einer einzigen komprimierten Datei, birgt aber ein größeres Risiko, dass das Versionskontrollsystem seine Datensammlung zerschiesst und es mir auch manuell nicht mehr möglich ist, sie zu reparieren, während ich bei textuellen Metainformationsdateien wenigstens im Notfall eine realistische Chance habe, daran herumzueditieren.
QuoteFerner ist diese Speichervariante extrem ineffizient, wenn man wie ich auch gerne mal lokal mehrere Branches anlegt um verschiedene Dinge auszuprobieren. Da sind die Speicherschemata bei Mercurial und Bazaar cleverer, weil nicht für jeden Branch ein riesiger Datenhaufen kopiert werden muss, sondern alle gemeinsamen Revisionsdaten auch gemeinsam benutzt werden können.
QuoteBekommt es auch wirklich mit, dass die gleiche Datei jetzt anders heißt und übernimmt korrekt die Versionsgeschichte?
QuoteNutzen muss ich sie nicht, aber wenn ich zum Beispiel einfach mal man git eingebe, bekomme ich eine solch riesige Liste von Kommandos um die Ohren gehauen, dass ich schon gar keine Lust mehr habe, mich auf die Suche nach dem passenden Highlevelbefehl zu machen, den ich brauche.
+11 replies
2009-07-19T15:12:14 sid burnQuoteBei einem Versionskontrollsystem ist es mir wichtig, dass ein Datenverlust so gut wie ausgeschlossen werden kann.
[...]
Wenn du Datensicherheit möchtest musst du backups machen. Eine Speicherung in klartext ist da weniger Sicherer als eine Speicherung in einer Datei.
[...]
QuoteQuoteFerner ist diese Speichervariante extrem ineffizient, wenn man wie ich auch gerne mal lokal mehrere Branches anlegt um verschiedene Dinge auszuprobieren.
[...]
Naja die Speichervariante ist eigenltich extrem effizent. Zum Suchen muss nämlich nur eine Datei durchsucht werden. Und eine Datei zu öffnen ist I/O mäßig schnellerer sprich effizenter als zig hunderte kleine Dateien. Und da es komprimiert ist, kann git schneller commits anzeigen und darin suchen als wenn es zig kleine Dateien hat.
[...]
Quote[...]
Was daran jetzt eine Designentscheidung ist weiß ich nicht. Hat man ein haufen kleine Dateien ist es ineffizent und man verschwendet viel speicher. Bei jedem commit allerdiengs immer wieder alles zusammenzuführen ist auch nicht gerade effizent.
[...]
Quote[...]
Naja und gerade für lokale branches ist Git ja bekannt das es schnell ist, und nein, für lokale branches muss auch nichts kopiert werden. Wie kommst du darauf das für branches ein haufen kopiert werden muss?
[...]
QuoteQuoteBekommt es auch wirklich mit, dass die gleiche Datei jetzt anders heißt und übernimmt korrekt die Versionsgeschichte?
Ja bekommt es. Es bekommt es sogar mit wenn du die Datei leicht modifizierst. Git zeigt dir prozentual an zu welcher Datei die neue Datei identisch ist.
QuoteQuoteNutzen muss ich sie nicht, aber wenn ich zum Beispiel einfach mal man git eingebe, bekomme ich eine solch riesige Liste von Kommandos um die Ohren gehauen, dass ich schon gar keine Lust mehr habe, mich auf die Suche nach dem passenden Highlevelbefehl zu machen, den ich brauche.
Einfach unter der Rubrik "High-Level Commands" zu schauen ist wohl zu schwer?
Quote[...]
Ansonsten sind die High-Level befehle ziemlich identisch zu denen in anderen VCS Systemen. Und wenn du die Befehle einmal kennst, musst du in der Regel auch nicht mehr einen Befehl suchen.
[...]
+10 replies
QuoteDatensicherheit im Programmdesign und Backups schließen sich nicht aus, sondern ergänzen sich. Ich mache ja auch Backups von Datenbanken, will aber trotzdem, dass die Datenbank ACID-Transaktionen kann.
QuoteDu kannst es gerne albern finden, dass ich Datensicherheit auf mehreren Ebenen haben will, aber ich sehe es eher so, dass ich da einfach höhere Anforderungen als Du habe.
QuoteZur Geschwindigkeit habe ich gar nichts gesagt, da man darüber nicht vernünftig diskutieren kann, ohne Randbedingungen wie das verwendete Dateisystem und dessen Einstellungen genauer festzulegen und richtige Benchmarks zu machen.
QuoteDer Speicherverbrauch mehrerer Repositories mit ähnlichem Inhalt ist aber definitiv höher, wenn jedes Repository die gesamte Versionsgeschichte als eine große Datei enthält, als wenn sich diese Repositories untereinander teilweise dieselben Daten, z.B. mittels Hardlinks, teilen.
QuoteIch denke, wir haben hier wohl etwas aneinander vorbeigeredet, da bei Git der Begriff Branch etwas anders verwendet wird als bei einigen anderen verteilten Versionskontrollsystemen. Ich bin es mehr gewohnt, dass ein Repository im wesentlichen identisch mit einem Branch ist und habe beim Schreiben nicht beachtet, dass Git ja pro Repository mehrere Branches speichern kann.
QuoteNun, das Speicherformat der Repositories ist auf jeden Fall eine Designentscheidung.
QuoteEinfach zwei Manpages git und git-lowlevel schreiben, damit der Überblick gewahrt bleibt und man nicht mit überflüssigen Informationen bombardiert wird, ist wohl zu schwer? ;-)
QuoteGenau deswegen hat mich die Manpage ja so genervt: Die Kommandos, die ich nicht durch Ausprobieren sofort gefunden hatte, fand ich im dortigen Datenwald auch erstmal nicht ;-)
+9 replies
2009-07-20T17:21:29 sid burnQuoteDatensicherheit im Programmdesign und Backups schließen sich nicht aus, sondern ergänzen sich. Ich mache ja auch Backups von Datenbanken, will aber trotzdem, dass die Datenbank ACID-Transaktionen kann.
Das was du ansprichst ACID-Transaktionen ist aber eine ganz andere Datensicherheit auf einen ganz anderen Level.
[...]
QuoteUnd wenn wir schon bei Datenbanken sind. Datenbanken selber speichern ebenfalls in einem eigenen Binärformat, und die abstraktion hier ist ähnlich hoch, daher man kann es mit eigenen Dateisystem vergleichen.
QuoteSo bieten die Datenbanken ja auch in der Regel an direkt mit RAW Devices zu kommunizieren was sogar die Performance erhöht da diese auch Caching etc. selber implementieren.
QuoteEs kann hierbei sogar schädlich sein wenn man keine RAW Devices nutzt da sonst ein doppeltes Caching entsteht. Datenbank + Filesystem und dann z.B. ACID nicht mehr gewährleistet sein kann.
[...]
QuoteAnsonsten erhöht dir auch ACID nicht die Datensicherheit über die wir gesprochen haben. Gibt es ein defekt an den Binärdateien dann hast du ein problem.
QuoteAber deswegen wirst du mir bestimmt gleich sagen das du deswegen auch keine Datenbank nutzt sondern alles schön in performante CSV Dateien auslagerst. ;) :p
Quote[...]
Aber ansonsten finde ich es nicht albern das du höhere Datensicherheit haben möchtest. Ein Versionierungssystem ist nur einfach keine Software die Datensicherheit bringt, sondern Source Code Verwaltet und Versioniert.
QuoteDatensicherheit ist sicherlich ein gutes Thema. Ich finde es aber ein Trugschluß wenn man meint das man ein Versionierungssystem nutzt und man hat dann bereits Datensicherheit.
QuoteWahrscheinlich habe ich höhere Anforderung an Datensicherheit als du, das ich ein Versionierungssystem nicht in der Kategorie "Datensicherheit" einstufe. ;)
QuoteQuoteZur Geschwindigkeit habe ich gar nichts gesagt [...]
Naja du hast von "effizenz" gesprochen. Was meintest du den dadrunter?
Quote[...]
Einen haufen kleine Dateien zu öffnen ist für ein betriebssystem auffendiger als eine einzelne Datei zu öffnen. Das liegt in der Natur des ganzen.
Quote[...]
Was natürlich eine gute Designentscheidung ist, wenn andere Versionierungssysteme zwei unterschiedliche sachen "Reposiory" und "Branches" als das "gleiche" ansieht. ;)
Quote[...]
Letztendlich wenn man möchte findet man immer etwas das man aussetzen kann. Mir gefällt die Font nicht. Die Schriftart ist nicht toll. Bei Mercurial nummerieren sich mit Dezimalen zahlen durch, woanders mit römischen zahlen... ;)
[...]
Quote[...]
Naja wie gesagt welcher Datenwald? Es gibt zwei Kategorien, einmal HIGH-LEVEL Kommandos und einmal LOW-LEVEL Kommandos. Suchst du ein HIGH-LEVEL Kommando scrollst du zu den HIGH-LEVEL Kommandos und gehst du Alphabetisch Sortierte liste durch.
[...]
+8 replies
QuoteEs 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.
QuoteBei Datenbanken ergibt das allerdings einen gewissen Sinn, bei Versionskontrollsystemen nicht.
QuoteMan kann immer abwägen, ob ein bestimmtes Speicherformat mehr Vor- oder Nachteile bringt. Ein redundantes Textformat wäre bei einer Datenbank wohl kaum angebracht,
Quotebei einem Versionskontrollsystem für ein paar Byte Metainformationen allerdings schon.
QuoteSolche "Features", wenn sie denn überhaupt existieren (eigentlich fällt mir überhaupt nur Oracle ein, als Datenbank, die das macht), verwende ich auch nicht gerne.
QuoteEtwas 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.
QuoteDazu gehört eben, dass man nicht an völlig unsinnigen Stellen auf Kosten von Robustheit und Datensicherheit auf Geschwindigkeit optimiert.
QuoteFerner 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.
QuoteAuch hier legst Du mir wieder Dinge in den Mund, die ich nie gesagt habe...
QuoteIn diesem Falle Platzeffizienz, was meiner Meinung nach deutlich aus dem Kontext zu erkennen war.
QuoteDas mag vielleicht bei einigen aktuellen Betriebssystemen so sein, allerdings sehe ich keinen Grund, warum das prinzipiell immer so sein sollte.
QuoteIm 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.
QuoteJa, das Vereinheitlichen von Konzepten um eine neue mächtigere Abstraktionsebene zu schaffen ist tendenziell meistens eine gute Idee.
QuoteRichtig, deswegen sagte ich ja auch schoneinmal, dass das alles Geschmackssache ist.
QuoteUnterschiedlichen 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 ;-)
+7 replies
2009-07-21T17:21:27 sid burnQuoteEs 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.
[...]
QuoteQuote[...]
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?
Quote[...]
Du musst aussagen schon begründen, so sind sie pure willkür.
Quote[...]
QuoteDas 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.
QuoteQuoteIm 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.
[...]
QuoteQuoteJa, 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.
[...]
Quote[...]
Wenn es nur geschmackssache ist, dann kann Git ja nicht kompliziert sein. Da geschmack subjektiv ist.
Quote[...]
Deine Argumente sind einfach albern. ;) Darüber zu Diskutieren ob die doku in eine oder zwei manpages aufgeteilt ist, ist volkommen irrelevant.
+6 replies
QuoteTja und genau das tut Git eben nicht, sondern programmiert um das Betriebssystem herum und erfindet das Dateisystem neu.
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.
QuoteDu musst schon lesen, was ich schreibe, sonst ist die ganze Diskussion ziemlich willkürlich.
QuoteAllerdings sind einige Dateideskriptoren gegenüber einem riesigen Dateiinhalt eine vernachlässigbare Datenmenge.
QuoteDa 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.
QuoteKlar, 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.
QuoteUnd was kompliziert ist, ist nicht subjektiv? Jetzt bin ich aber mal auf Deine objektive Definition des Begriffes "kompliziert" gespannt...
QuoteDiese 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.
QuoteEs 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.
QuoteÜbrigens finde ich, dass der "Scherz" ich sei "albern" und andere persönliche Angriffe von der vielfachen Wiederholung Deinerseits nicht unbedingt besser werden.
QuoteWenn 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.
+5 replies
2009-07-22T09:25:41 sid burnQuoteTja 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.
[...]
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.
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.
[...]
QuoteQuoteÜ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.
QuoteQuoteAllerdings 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!
QuoteQuoteDa 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.
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.
Quote[...]
Natürlich ist es auch ein höherer Programmieraufwand und komplexer, aber das kann mir als nutzer von Git ja egal sein.
Quote[...]
Die nennung von irgendeiner Software ist jetzt aber kein argument für irgendetwas.
Quote[...]
Ansonsten ist Abstraktion generell auch nicht immer gut. Unterschiedliche Dinge sollten auch unterschiedlich sein, und nicht krampfhaft versucht werden sie zu abstrahieren.
QuoteGutes Beispiel ist wie bereits gesagt der "eval" Befehl in Perl. Macht zwei komplett unterschiedliche Dinge die gleich benannt sind.
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.
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?
QuoteWenn 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.
Quote* Weil die Liste der "High" und "Low" Level befehle in einer anstatt in zwei manpages stehen.
Quote* Weil man das Repository von zeit zu zeit selber verwalten muss.
Quote* Aufteilung der Befehle in Low- und High-Level und zu viele Befehle.
QuoteDeine 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.
Quote* Man kann von Zeit zu Zeit "git gc" eintippen um den Speicherplatzverbrauch zu reduzieren, und das halte ich nicht für kompliziert.
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.
QuoteHabe ich was vergessen?
+4 replies
Quote"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.
QuoteDadurch 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.
QuoteSoweit 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.
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;
QuoteIch meine, dass die relevante Datenmenge bei Datenbanken üblicherweise groß ist, bei Versionskontrollsystemen üblicherweise klein.
QuoteZum 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.
QuoteAber ein Beispiel. In diesem Falle ein Gegenbeispiel zu Deiner Behauptung, niemand käme auf die Idee, so abzuspeichern.
QuoteDas 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.
QuoteDas 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.
QuoteDa fehlen mir auch ein paar clevere Abstraktionen ;-)
+3 replies
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.
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.
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 10open 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;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
my $config = new Krasses::Config::Objekt(); { open my $in, '<', 'config.ini' or die ...; $config->load($in) or die ...; } $config->...; # modifiziere Konfiguration { my $out = new File::Temp(TEMPLATE => 'config.ini.XXXXXXXX') or die ...; $config->dump($out) or die ...; $out->flush() or die ...; $out->sync() or die ...; rename $out, 'config.ini' or die ...; # <-- Datei atomar ersetzen }
Quote[...]
QuoteIch 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.
Quote[...]
QuoteZum 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?
Quote[...]
QuoteDa fehlen mir auch ein paar clevere Abstraktionen ;-)
Welche den als Beispiel? ;)
+2 replies
QuoteOk, wenn es da ein gutes Werkzeug für Git gäbe, wäre das ein Argument
QuoteWenn 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.
QuoteMir 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,....
QuoteHmm, ich bin halt eher Datenbanken in der Größenordnung von 10^12 Bytes und Repositories im Bereich 10^7 Bytes gewöhnt.
QuoteGar 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.
QuoteAuf jeden Fall hätte ich gerne etwas, was mit ganz wenigen Operationen auskommt.
QuoteAm 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
2009-07-24T16:29:23 sid burn[...]
QuoteWenn 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.
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.
Quote[...]
QuoteAm 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.
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.
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?
[...]
Schrift
Blog
Einstellungen![[feed]](/battie/theme/default/icons/feed.png){kind=icon}
![[Powered by Battie]](/battie/img/powered.png)
