Auch ohne mich direkt auf die Suche nach passenden Artikeln zum Thema Git gemacht zu haben ist es sehr schwer, den Begriff Git auf irgendeiner Projektwebsite eines Open Source Projekts zu ignorieren. „Moved to Git“ oder so ähnlich titulieren viele der entsprechenden Ankündigungen.Irgendetwas muss also dran sein, an dem noch relativ jungen Versionsverwaltungssystem. Nun gut, 6 Jahre ist in der aktuellen Zeit schon wieder alt, aber nennen wir’s doch eher reif! Für die Entwicklung meines kleinen Forensystems Yella setze ich bislang auf Subversion. Nun gut, die Versionsverwaltung hat dabei auch nicht viel zu tun: keine Branches, kein Merging, nur ein Entwickler respektive Repository. Würde Git etwas daran ändern können? An Subversion schätze ich die vielfältigen Tools. Angefangen von lokalen Helfern wie TortoiseSVN bis hin zu Webstatistiken per StatSVN oder schicken Webrepositories via WebSVN: selbst für kleine Projekte sind nützliche Dinge vorhanden. Aber auch Git hat hier mittlerweile einiges zu bieten. TortoiseGit schickt sich an, das Pendant zur SVN-Variante zu werden und Weboberflächen gibt es auch hier zu genüge. Die steigende Popularität von Git hat also auch ganz praktische Früchte hinterlassen. Nun aber wieder zurück zu den eigentlichen Kernthemen. Git ist als verteiltes Versionsverwaltungssystem zu betrachten, was ganz einfach heißt: kein Server nötig, die Entwicklung kann vollständig lokal geschehen. Nettes Feature, aber noch kein Killerkriterium. Schauen wir lieber auf die eigentliche Entwicklungsmöglichkeiten und die sind bei Git sehr flexibel: das gesamte Branching und Merging Konzept scheint auf den ersten Blick relativ einfach gestaltet zu sein. Um ehrlich zu sein, war das auch der Punkt, warum ich darauf bei Subversion verzichtet habe. Bei Git könnte ich mir durchaus vorstellen, das Branching Konzept anzuwenden, selbst für so ein kleines Projekt wie Yella. Weitere Vorteile, die bei Git angepriesen werden, sind unter anderem das Staging Konzept (ein Commit muss nicht alle Änderungen enthalten), die Anpassung von Git an den Entwicklungsablauf des Projekts (und nicht anders herum) oder die Schnelligkeit. Diese Dinge spielen bei mir aber eher eine untergeordnete Rolle, doch auch so scheint Git durchaus eine attraktive Sache zu sein. In Sachen Dokumentation sticht Git hervor. Neben zwei Open Books existieren viele Seiten mit Tipps & Tricks. Für eine 6 Jahre alte Software ist das erstaunlich viel Material, auf unterschiedlichste Art präsentiert. Mein vorläufiges Fazit lautet folglich: Git hat es durchaus verdient, näher getestet zu werden und ist auf den ersten Blick sehr reizvoll. Aber auch Subversion wird weiterhin weiterentwickelt und zielt eben auf einen ganz anderen Ansatz. Daher gibt es auch keine Gründe, eine vorschnelle Entscheidung für ein System treffen zu müssen.
Schlagwort-Archive: Subversion
Auf den zweiten Blick
Bevor ich mich mit dem Thema CVS beschäftigte, hatte ich zuerst das Vergnügen mit Subversion, doch damals verstand ich die Systematik noch nicht ganz. Nun, nach der Einarbeitung in CVS (zugegebenermaßen auf die nötigsten Sachen) habe ich nocheinmal einen Blick auf Subversion geworfen und mir die Unterschiede nochmals vor Augen geführt.
Im Gegensatz zu CVS erkennt Subversion Nicht-Textdateien automatisch (z.B. Bilder, Binärdateien, ..), ist in aktiver Entwicklung und arbeitet schneller. Subversion bietet gerade im Tag/Branches Bereich aber ein grundlegend anderes Konzept, zum einen erhalten einzelne Dateien keine Revisionsnummer mehr, sondern nur noch ganze Projekte. Tags ansich scheint es zudem nicht mehr zu geben.
Subversion erfordert also definitiv eine Umgewöhnung, wenn man CVS schon einmal im Einsatz hatte, lässt aber auch einige Vorteile erkennbar werden. Wenn sich mal die ein oder andere Minute findet, werde ich mir Subversion auf jeden Fall etwas genauer anschauen, derzeit gefällt mir CVS aber noch besser.