Quote

Bei 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.

Wenn du Datensicherheit möchtest musst du backups machen. Eine Speicherung in klartext ist da weniger Sicherer als eine Speicherung in einer Datei. Datensicherheit in diesem Punkt ist einfach nur albern.

Und ein Versionierungssystem ist nicht dafür zuständig das ein Datenverlust ausgeschloßen ist. Um ein Datenverlust zu vermeiden dafür sind Backup programme zuständig.

Ansonsten da es ja ein denzentrales versionierungssystem ist, hast du ja automatisch mehrere kopien vorhanden wenn du das projekt clonest.

Ich selber habe meine Git Projekte immer auf meinen Server, auf meinen Desktop PC, und auf meinen Laptop, das reicht mir persönlich aus. Wenn du dich sicherer füllst, kannst du auch 10 mal das Repro auf deiner Festplatte clonen. Auf den gleichen Rechner oder Festplatte erhöhst du dadurch aber auch nicht die Datensicherheit.

Quote

Ferner 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.

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. Die Speicherung ist also nicht ineffizent, sondern genau wegen der einen Datei effizenter. Deswegen macht man es ja auch.

Ansonsten wenn du erstmal nur commitest, dann wird der commit in einer neuen Datei abgelegt, und nicht sofort in einer großen Datei. Bei einem Standard commit verfährt es dann erstmal so, wie du meinst das es effizenter ist. Da es das aber nicht ist, kann man halt von zeit zu zeit mit "git gc" die ganzen kleinen objekte wieder zu einer zusammenfassen wodurch es dann performanter wird, und die komprimierung besser wird und der Speicherplatz geringer wird.

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. Daher ist es gemixt. Zuerst einzelne Dateien, und von Zeit zu Zeit kannst du es zusammenfassen und die Vorteile genießen.

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?

Git benutzt alle Revisionsdaten ebenfalls. Branches funktionieren in Git letztendlich nur durch Pointer. Legst du einen zusätzlichen branch an wird ein zusätzlicher Pointer auf eine Revision gelegt.

Erstellst du 100 branches, zeigen 100 Branches auf das gleiche Objekt, erst nach einen commit unterscheidet sich ein branch. weil der pointer dann auf den neuen commit zeigt, und der parent des commits auf den gemeinsamen vorgänger. Bei Git wird nirgendswo etwas umkopiert.

Gerade das es nichts umkopiert und somit speicherschonender ist, ist ja gerade ein Vorteil von Git der immer wieder betont wird.

Ich weiß nicht was du da genau über Git gelesen hast, aber das war wohl falsch.

Quote

Bekommt 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.

Anhand daran das es dir anzeigt wie die Datei vorher war kannst du History dann weiter durchschauen.

Allerdiengs muss man hierzu sagen das das ganze was du meinst eine Designentscheidung war. Es ist weder Falsch, und andere VCS machen es richtig.

Quote

Nutzen 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?

High-Level und Low-Level Befehle werden getrennt angezeigt und Sortiert angezeigt.

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. Und ein "git help" liefert dir ebenfalls eine kleine Liste von High-Level befehlen die am meisten genutzt werden.
Last edited: 2009-07-19 17:26:25 +0200 (CEST)