Ich brauche für (mindestens) zwei größere Projekte mit mehreren Teilnehmern ein voll ausgebautes Versionskontrollsystem mit allem Drum und Dran. Momentan schwanke ich zwischen Git und Subversion. Git scheint mir das modernere Konzept zu haben, Subversion wiederum wird von dem besten Editor der Welt und dem anderen guten Texteditor auf dem Mac direkt unterstützt (alle Teilnehmer an den Projekten sind Mac-User). Eigentlich hatte ich mich schon für Subversion entschieden, aber dieser euphorische Artikel hat mich wieder schwankend werden lassen. Hat jemand von Euch da draußen Empfehlungen? [Peter van I. per Email.]
Die tägliche Ration Wahnsinn — seit April 2000 im Netz
Über …
Der Schockwellenreiter ist seit dem 24. April 2000 das Weblog von Jörg Kantel (Neuköllner, EDV-Leiter, Autor, Netzaktivist und Hundesportler — Reihenfolge rein zufällig). Hier steht, was mir gefällt. Wem es nicht gefällt, der braucht ja nicht mitzulesen. Wer aber mitliest, ist herzlich willkommen und eingeladen, mitzudiskutieren!
Die Inhalte des Schockwellenreiters stehen unter einer Creative-Commons-Lizenz.-
Werbung
-
Soziales
Klickr Flickr
Neu in meinem Wiki
Git ist toll, und in jedemfall zu empfehlen, wenn es zum Workflow passt.
Es gibt ein paar Situationen in denen das nicht der Fall ist:
Wie jedes DVCS speichert es die gesamte History auf seiten des Users. Das klingt toll, wird aber zu einem echten Problem wenn es um große Mediadateien geht.
Zudem ist in Workflows, in denen man einzelne Dateien allgemein vor Änderungen sperren will, ein zentrales System wie Subversion besser. Das kann man mit Absprache natürlich auch mit Git erreichen, Subversion und co. überstützen den Prozess aber.
Bei git ist eines zu bedenken: Es wurde für ein Projekt mit vielen kleinen Textdateien entworfen (dem Linux Kernel), und exakt da ist es auch super für. Je stärker ein Projekt davon abweicht, umso unhandlicher kann git werden.
Wenn es SEHR große Dateien sind, und davon auch sehr viele, soll übrigens Perforce das Optimum sein. Nicht Open Source, nicht kostenlos. Aber z.B. in der Spieleentwicklung wohl immernoch am weitesten verbreitet, dank großer Texturen, Videos und co.
Übrigens arbeitet es sich mit git ganz wunderbar auf der Konsole, wenn man es den mag. Man merkt das die Macher das auch als Ziel hatten. Die GUI Tools halte ich aber alle für eher mau, vieles sind auch schlicht unvollständig oder bestenfalls frühe Beta/stark fehlerhaft.
Also ich persönlich finde ja Mercurial wirklich gut
Wenn du viel Zeit hast kannst du dir ja mal den CRE 130 anhören.
Für den Textmate gibt es ein mit fast identischen Funktionen ausgestattetes Plugin für git, das wäre also kein Argument.
Ich bevorzuge git, habe aber festgestellt, dass manche Leute ihr Denken vom “lokale Kopie -> auf den zentralen Server” auf das “distributed git” nur schwer umstellen können.
Ich sollte vielleicht noch sagen, daß es bei dem einen Projekt unter anderem um etwa 1,5 Terrabyte eingescannten Nachlaß und vielen großen 3D-Dateien (PLY und VRML) und bei dem zweiten Projekt unter anderem auch um viele Scans (digialisierte historische Bücher), aber auch um viele kleinere LaTeX-Dateien geht. Allerdings verändern sich diese Scans und 3D-Daten nicht mehr, sondern nur noch die Text-, XML-, HTML- und LaTeX-Dateien.
“Ich bevorzuge git, habe aber festgestellt, dass manche Leute ihr Denken vom “lokale Kopie -> auf den zentralen Server” auf das “distributed git” nur schwer umstellen können.”
Das geht allerdings auch mit git ganz wunderbar. Viele nutzen git nicht soo dynamisch wie es sein könnte, schlicht weil sie es nicht brauchen. Git ist jedoch extrem schnell, die lokale history ist sehr nützlich, das schnelle und saubere branchen/mergen ist praktisch, und die commandline Tools sind super.
Git ist also auch in einem “klassischen” Workflow gut aufgehoben.
Nur ist es eben leider nicht für alle Arten von Dateien gut geeignet. DVCS haben eben allgemein auch Nachteile, wenn auch nur wenige.
Pro’s für git:
- Distributed, sprich man kann auch ohne Netzanbindung arbeiten
- Operationen auf der History (Log etc) und Diffs gehen schnell, da kein Netzwerkzugriff
- sehr gute branch/merge Unterstüztung
- mit github lässt sich sehr gut eine zentrale Instanz aufziehen, für geschlossene Benutzerkreise kostenpflichtig, eventuell Rabatt für Uni oder so
- sehr schnell
Pro’s für Subversion
- einfacheres Modell, ein zentraler Server
- sehr gute Tools auf allen Betriebssystemen
- auch das CLI-Interface ist signifikant einfacher
- auschecken von Teilbäumen möglich, gerade bei großen Mediendateien ist das interessant
- locking von Binärdateien ist möglich und kann die Kommunikation im Team unterstützen (wer bearbeitet die Datei gerade?)
Generell setze ich für Teams mit wenig SCM-Affinität gerne SVN ein, da es einfach weniger Fußangeln bietet (hab ich nun gepusht oder nicht), für Teams mit mehr Erfahrung gerne auch git. Es gibt auch noch die Möglichkeit SVN einzusetzen und für alle Leute die lieber mit git arbeiten dann git-svn.
Subversion ist nur ein CVS mit Fehlerkorrekturen, es macht nichts besser. git ist ein komplett anderer und wesentlich flexiblerer Ansatz.
git ist außerdem eine Toolbox, es zwingt Dir anders als CVS und subversion keinen Workflow auf. Du mußt ihn stattdessen selber bauen und enforcen.
Siehe auch http://nvie.com/posts/a-successful-git-branching-model/ als Startpunkt.
IMHO gibt es nur ein einziges Argument, das gegen Git sprechen könnte, und zwar die GUI-Unterstützung. (Wobei ich glaube, dass Gitti und Gity inzwischen eigentlich alles Wesentliche abdecken; mir selbst reichen Shell und GitX zum Stagen von umfangreicheren Änderungen.)
Ich empfinde Git ist wesentlich anfänger- und lernfreundlicher, sofern man nicht durch SVN vorgeschädigt ist. Gerade die Kandidaten, die ihr VCS im Grunde wie einen FTP-Server verwenden, haben kaum eine Chance, ihr Repository kaputt zu bekommen. Eine SVN-Arbeitskopie ist dank der omnipräsenten .svn-Directories ja schon im Eimer, wenn man nur ein Unterverzeichnis löscht und durch identische Daten ersetzt. Oder, nicht auszudenken, ein Verzeichnis einfach an einen anderen Ort schiebt! Mit Git kann man hingegen ganz nach Belieben und ohne besondere Werkzeuge rumbasteln und dann das Ergebnis wie einen Schnappschuss auf den zentralen Server schubsen.
Und als nächsten Level lernt man dann, sich seine Aktionen nochmal anzusehen, zusammengehörige Änderungen zu stagen und zu einem kommentierten Commit zusammenzufassen. Der SVN-Workflow ohne Staging hingegen führt zumindest nach meinen Erfahrungen selbst in Gruppen mit Fortgeschrittenen immer wieder dazu, dass auch Mist in Commits landet.
“… mit github”
Wobei es hier auch Open Source alternativen gibt. Nicht so gut wie github, aber das braucht auch nicht jeder.
z.B. Gitorious (ruby on rails) oder indefero (php). Für letzteres bin ich Packagemainteiner für Ubuntu Pakete und selbst Nutzer davon. Ich mags.
@LH @Jörg Ja, Perforce wird momentan ziemlich übersehen und unterschätzt. Google verwendet es übrigens häufig in ähnlichen Szenarien. Vielleicht hat ja das Institut noch etwas Geld übrig?
Moin,
GIT und Subverson arbeiten komplett unterschiedlich. Für die Projekte sollte man sich also erstmal überlegen, ob 1 (!) zentrales Repository oder dezentrale Repos verwendet werden soll.
Zentrale Repos: SVN tut, was es soll (meistens). CVS ist ausgereifter, kann aber weniger.
Dezentrale Repos: Hier hat man die Qual der Wahl zwischen GIT und Mercurial. Interessant dazu: http://code.google.com/p/support/wiki/DVCSAnalysis
Erstmal muss man sich aber überlegen, wie die Arbeitsweise aussieht. Auf dem Notebook bin ich jedenfalls immer froh, ein DCVS zu benutzen.
“CVS ist ausgereifter, kann aber weniger.”
Dazu sei angemerkt das CVS für ein Projekt mit 1,5 TB an Daten ungefähr einem Kopfsprung von einem 30 Stockwerkehaus gleichkommt. Kann man machen, sollte man aber nicht. CVS ist von gestern. War es schon vor 10 Jahren. Ich habe auch den Fehler gemacht es zu nutzen, und es lange bereut. Wenn, dann Subversion. CVS sollte niemand mehr verwenden. Es ist so ausgereift wie eine Kuh die seit Jahren tot in der Wüste liegt. Man weiss immer wo die Knochen sind, aber bessere Milch gibt das nicht
“Wahl zwischen GIT und Mercurial.”
Und Monotone, Bazaar und Bitkeeper. Und noch einer Menge weiterer. Monotone Support ist in kürze in Indefero verfügbar. Da steht gerade die Version 0.99 an, die wohl diese Woche released wird.
Bazaar ist das DVCS von Canonical (Ubuntu Linux), und bildet die Grundlage von deren Projekten.
Bitkeeper war lange das DVCS der Wahl für den Linuxkernel. Dumme Lizenzgeschichten haben es aber aus dem Rennen geworfen.
Ich würde auf jeden Fall einen Blick auf Mercurial werfen, gerade für unerfahrene Anwender oder Leute, die bereits Subversion kennen. Git ist so unglaublich vielseitig und mächtig, dass man damit alle erdenklichen Workflows abbilden kann, aber diese Komplexität ist meiner Meinung nach der große Haken. Mit Mercurial kann man sich nicht so leicht selbst in den Fuß schießen und die GUIs gefallen mir auch besser. (Hierzu auch siehe Git vs. Mercurial: Please Relax)
Wie hier schon betont wurde: Subversion ist gut geeignet, wenn man unerfahrene Nutzer hat und die Netzinfrastruktur steht. Subversion ohne Netzwerk ist pain-in-the-ass aber im Intranet ist’s ok und man kann den Workflow der Nutzer besser steuern. Ich würde Subversion auch bei größeren Mediendateien vorziehen, da es clientseitig weniger speicherhungrig ist. (Es wird auf dem Client nur der letzte ausgecheckte Stand und der aktuelle Stand der Arbeitskopie vorgehalten, nicht alle Stände wie bei Git/Mercurial.)
Ich kenne beide, benutze beide in unterschiedlichen Projekten. Bei der Wahl muss der IT-Background der Anwender berücksichtigt. Ist hier der Hintergrund eher dürftig, dann ist das zentrale Modell von Subversion sicherlich leichter zu verstehen. Dies auch vor der Tatsache, dass sich Subversion sehr gut in Dateimanager wie dem Windows Explorer und dem Apple Finder einbinden lässt. Die meisten bisherigen Schreiber haben einen eher stark IT-lastigen Hintergrund und übersehen meistens, dass Kommandozeilen schön sind, der normale Anwender damit aber wenig anfangen kann.
Bei den anpassbaren Workflows habe ich zumeist schlechte Erfahrungen gemacht – nicht nur bei GIT. Da kann es schnell komplex werden und der Schulungsaufwand ist nicht zu unterschätzen. Insbesondere nicht bei einem örtlich verteilten Team und/oder wenn die Fluktuation hoch ist. Auch und gerade das Distributed Konzept bei GIT, das ich persönlich sehr mag, bereitet immer wieder Kopfschmerzen im Verständnis. Meiner Meinung macht GIT nur in einem grossen örtlich verteilten Team wirklich Sinn.
Mit frossem Team meine ich mehrere Hundert Mitarbeiter. Unsere Erfahrung mit Subversion und verteilten Teams in Berlin, Minsk und San Francisco hat gezeigt, dass es hier keine relevanten Probleme gibt. Die Teamgrösse liegt bei ca. 8 Personen pro Standort (nicht San Francisco). Der Umfang der Daten ist allerdings nicht annäherend bei der beschriebenen Grösse.
Zum Thema „Speicherhunger“ durch das Vorhalten aller Versionsstände sei angemerkt, dass eine SVN-Arbeitskopie ohne Versionshistorie in den seltensten Fällen wesentlich kompakter ist als ein Git-Repository mit Historie. Eine SVN-Arbeitskopie mit 1 GB Nutzdaten dürfte ziemlich genau 2 GB groß sein, denn eine unkomprimierte Vorversion wird zur Ermittlung von Änderungen vorgehalten. In Git hat man 1 GB plus die komprimierte Historie vorliegen, was unter Umständen sogar platzsparender ausfällt.
http://whygitisbetterthanx.com/#git-is-small
Nachtrag:
Bei Mercurial (und vermutlich auch bei GIT) landet immer das GANZE Projekt auf der lokalen Platte.
Zu Subversion sei noch angemerkt, dass man hier die Möglichkeit hat, Teilbäume auszuchecken. Insbesondere bei einem Repo von > 1 TB eine nicht zu unterschätzende Option
Bei Subversion hat man halt das Gehuddel mit den ganzen .svn-Unterverzeichnissen, die verhindern, dass man Ordner mal einfach so verschiebt – kann böse Begleiterscheinungen bringen. Und wie schon gesagt, ist der Speicherbedarf des ausgecheckten SVN-Teilbaumes immer doppelt so groß wie die Dateien selbst – weil eine Kopie im .svn-Unterverzeichnis verbleibt.
Sehr große Binärdateien würd icih aber nicht unbedingt in im SCM vorhalten.
@Jan: Das Problem ist nicht, daß die Binärdateien groß, sondern daß es sehr, sehr viele sind (> 10.000).
@rbq:
Bei Textdateien mag es stimmen, bei Binärdateien nicht. Da hat jedes DVCS Probleme, sobald es zu viele Änderungen gibt. Und für Änderungen hat man es ja
A successful Git branching model : http://nvie.com/posts/a-successful-git-branching-model/
NB : PDF download at end of article
Here we will briefly introduce you to Git usage based on your current Subversion knowledge : http://git-scm.com/course/svn.html
gitignore
-quote-
A gitignore file specifies intentionally untracked files that git should ignore. Each line in a gitignore file specifies a pattern.
-unquote-
Available for various languages & frameworks (check source)
manpage : http://man.cx/gitignore
source : https://github.com/github/gitignore
Visual Git reference : http://marklodato.github.com/visual-git-guide/index-en.html
Tower, a brand new Mac Git client : http://www.git-tower.com/
Gitbox has been released, free for one repository : http://gitboxapp.com/
-quote-
A new intuitive interface makes everyday tasks amazingly simple. In a single window you see all your repositories, history and working directory state. Commit, pull and push with a single click. Creating, sharing and comparing branches becomes so simple, you will start to actually use them.
-unquote-
Git Magic (downloadable or online) : http://gitmagic.lordofbikes.de/
Git from the bottom up : http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
( NB : direct link to 782 KB .pdf )
Git Immersion : http://gitimmersion.com/
-quote-
Git Immersion is a guided tour that walks through the fundamentals of Git, inspired by the premise that to know a thing is to do it.
-unquote-
Top 10 Git Tutorials for Beginners : http://sixrevisions.com/resources/git-tutorials-beginners/
Understanding the Git Workflow : http://sandofsky.com/blog/git-workflow.html
Git Is Simpler Than You Think : http://nfarina.com/post/9868516270/git-is-simpler
[...] ist doch die Einführung, auf die ich gewartet habe: Git von Anfang an und (auch, aber nicht nur) für Dummies wie mich, denn Git Is Simpler Than You [...]
Git Reference : http://gitref.org/
A Git Primer : http://danielmiessler.com/study/git