Heise online hat mich mit dem Artikel “Entwicklungshistorie von Gesetzen mit Git verfolgen” auf ein interessantes Git-Repository aufmerksam gemacht: Das von Stefan Wehrmeyer angelegte Depot github.com/bundestag/gesetze enthält alle Bundesgesetze und die zugehörigen Verordnungen.
Schlagwort-Archiv: git
Wie Dia entstanden ist
Hinterlasse eine Antwort
Ohloh schätzt den Aufwand zur Erstellung des Zeichenprogrammes Dia aktuell auf 98 Mannjahre – geleistet von mehr als 200 Personen. Aber wie kann man diese Leistung jemandem verständlich machen, der kein Softwareentwickler ist? Das Programm Gource analysiert die Entstehungsgeschichte der Quelltexte und visualisiert sie in Form eines Videos. Dabei werden Quelltextdateien als bunte Kugeln und Verzeichnisstrukturen über Linien dargestellt. Zwischen diesen Elementen huschen kleine Entwickler-Avatare hin- und her und verrichten ihre Arbeit mit einer virtuellen Sprühpistole.
Selbst für mich, der die Entwicklung über mehr als 10 Jahre verfolgt hat, ist diese Darstellung interessant. In mehreren Einstellungen des Videos huschte mir ein Gedanke durch den Kopf: “Was machst Du da, an dieser Stelle hast Du doch niemals gearbeitet…”. Die Nullen und Einsen im Speicher der Versionsverwaltung filtern im Zweifelsfalle weniger als das menschliche Hirn.
Sehr schade finde ich, dass selbst diese detaillierte Darstellung noch lange nicht alle helfenden Hände erfasst: Es werden nur die Entwickler dargestellt, die ein entsprechendes Benutzerkonto für die Versionsverwaltung besaßen. Entwickler, die Quelltextflicken per Email oder Bugtracker geliefert haben, erscheinen nicht, statt dessen “sprüht” ein anderer Entwickler. Allerdings ist hier Besserung in Sicht: Seit einiger Zeit wird git zur Verwaltung der Dia-Quelltexte verwendet – die Software erlaubt es, zwischen dem Autor und dem sogenannten “Committer” zu unterscheiden.
Erfreulich ist hingegen, dass auch die Historie aus den git-Vorgängersystemen CVS und Subversion durch entsprechende Konvertierungen erhalten geblieben sind.
Ich bin schon gespannt auf die Visualisierung weiterer Softwareprojekte.
git, svn, cvs, rcs
Während des Studiums habe ich auf einer HP Workstation zum ersten Mal mit einer Versionskontrollsoftware gearbeitet*): RCS.
Bedient wurde das ganze ausschliesslich auf der Kommandozeile, es wurden nur einzelne Textdateien lokal verwaltet…
Mit dem RCS-Nachfolger CVS bin ich dann durch Open Source-Projekte wie Newtonlink und Dia in Kontakt gekommen. Dadurch, dass ganze Quelltextbäume zentral auf einem Server verwaltet wurden und durch grafische Oberflächen wie WinCVS oder das Konqueror-Plugin, habe ich eine Versionsverwaltung schätzen gelernt.
Seit die “binäre Deltakompression” in CVSNT zur Verfügung stand konnte man sogar GIS-Daten (Shapefiles) effektiv verwalten.
Allerdings waren Einsteiger oft überfordert und so war ich begeistert, als die Entwicklung von Subversion (SVN) begann: Ein Programm, dass die CVS-Funktionalität bot, aber deutlich einfacher zu bedienen war. Mit der exzellenten Integration von TortoiseSVN in den Explorer und “Checkout-Links” war es auch von Nichtprogrammierern zu nutzen.
Als die Quelltextverwaltung des Dia-Projektes vor einigen Jahren von CVS auf Subversion umgestellt wurde, war ich bereits ein versierter SVN-Nutzer.
Jetzt ist es wieder soweit: Die Dia-Quelltextverwaltung wurde von SVN auf git migriert und ich habe gerade meinen ersten “git push” durchgeführt.
Als git-Anfänger kann ich noch wenig zu den Vorteilen gegenüber Subversion sagen. Dadurch, dass ganze Repositories “geklont” werden, kann eine Versionierung lokal, ohne Verbindung zu Server, erfolgen: Eine Multi-Master-Replikation für versionierte Quelltextverzeichnisse. Wer oft auf einem Laptop ohne Internetverbindung arbeitet, wird das zu schätzen wissen.
Trotz all der Fortschritte in der 20-jährigen Geschichte der Versionskontrollsoftware: Der entscheidende Erfolgsfaktor beim Einsatz der Software ist eine gute Koordination: Wenn die zwei Teammitglieder dieselbe Zeile bzw. bei Binärdateien dieselbe Datei bearbeiten und es zum gefürchteten Konfllikt kommt, hat meistens einer der beiden seine Zeit vertan. Die Software, die diesen Missstand sichtbar macht trägt keine Schuld daran.
*) Ich erinnere mich dunkel, zuvor auf dem Amiga mit RCS experimentiert zu haben, diese Experimente waren aber nicht sonderlich erfolgreich.