Am Dienstag, 7. September 2010, 14:07:01 schrieb Thomas Schmidt:
Hallo!
Ich sehe bei SVN den größten Vorteil darin, dass jeder User die Logik mit dem großen allmächtigen Server und den kleinen Clients versteht. Bei GIT ist jeder technisch gleich, logisch gibt es aber nach wie vor den Master und die Untertanen. Da entsteht eine unnötige Diskrepanz zwischen Programmbedienung und gefühlter Logik.
Selbst Gefühle können sich ändern.
Für mich ist wichtig, dass Repositories auch teilweise ausgechekt werden können. Das geht mit SVN sehr gut. Wenn z.B. die Buchhaltung nur die Buchführung, aber nicht die 10 GB Rechnungen braucht, holt es sich auch nur diesen Teil.
Guter Punkt!
Gegen GIT spricht als KO-Kriterium die schlechte Verfügbarkeit an Oberflächen. Damit kann ich GIT nicht im Unternehmen etablieren.
Ich habe leider Tortoise-Git selbst nicht angefaßt, denke aber, daß es _durchaus_ verwendbar ist.
@Bernhard: Mich stört auch, dass ein mv auf Dateisytemebene nicht funktioniert, sondern im SVN-Client gemacht werden muss. Würde man es einfach im Dateisystem machen, wäre das für SVN ein Delete und Add.
Ja. Du schilderst die Client Seite. Ich meinte die Server-Seite. Von dort kommt nämlich bei svn update delete && add an (statt mv). Und das kostet Bandbreite.
Ich denke aber, ein intelligenter Client könnte auf den Trichter kommen, dass nur verschoben wurde, und das dem Server mitteilen. Dafür sind die SVN-Clients momentan noch zu blöd.
Warum ist GIT konsistent by design? Kann mir das bitte jemand erklären?
Ganz grob: Jeder Eintrag hat seinen Typ, eine sha1-Checksumme des Inhalts und den Verweis auf einen Vorgänger, der widerum seine eigne sha1-Ckecksumme hat. An jeder Stelle im "Geäst" des Versionsbaumes ist sozusagen ein inhaltsadressierter Weg zurück zur Wurzel möglich. Und das wird von git intern und oft genug überprüft! Nachträgliche Manipulationen werden sofort bemerkt (auch wenn es "nur" HD- Lesefehler sein sollten!) Du kannst als ersten Commit ja eine von Dir (gpg-) signierte Textdatei nehmen. Damit hättest Du jeden späteren Inhalt (besser den Weg dahin) digital signiert und jeder könnte das nachprüfen (und tut's auch unbemerkt) ! Versuch das mal woanders!
Der Hardcore-Link dazu (von git-scm.com) http://eagain.net/articles/git-for-computer-scientists/
Ja, damit kann man sogar solche Sachen wie revisionssichere E-Mail- Archivierung angehen. a la: sha1sum <Maildatei> | git commit -a -m"`Mail-Eingang"
Damit hätte man Reihenfolge (sogar Zeit, weil im Namen der <Maildatei>) und Inhaltshash gut gesichert.
Später könnte man eine E-Mail an einen RA schreiben: " Bitte senden Sie diese Mail qualifiziert signiert an mich zurück: 2007 <sha1 des letzten git commits> 2008 <sha1 des letzten git commits> 2009 <sha1 des letzten git commits> mfG. Bernhard " Und bei Empfang hättest Du einen ganzen Zeitraum (hier ein Jahr) "versiegelt". Durch die Angabe der "alten" Summen ist noch nicht mal nötig, das der Key des RA von z.B. 2007 (immer noch) überprüfbar ist.
Da kein Mail-Inhalt selbst unter git verwaltet wird, könntest Du eine Mail sogar löschen (Stichwort wg. Datenschutz <->private Mail), jeder würde sehen können das da was fehlt und der Rest wäre trotzdem "revisionssicher" | nicht betroffen. (Rechtlich gefordert muß man "Geschäftsbriefe" aufbewahren. Was von der E-Mail darunter fällt, ist letztlich Entscheidung des Geschäftsführers. Die Idee, einfach alles aufzubewahren, ist sehr verkürzt.)
Dumm bloß, daß der Gesetzgeber von Technik keine Ahnung hat ...
Viele Grüße! Thomas
Bernhard