Welches RCS und wo lasse ich meine Repos

Nachdem ich mich entschieden hatte, dass ich nicht mehr ohne ein RCS (Revision Control System) arbeiten wollte, begann eine Zeit des Leidens. Das letzte mal hatte ich vor 16 Jahren im Studium eben mit RCS auf einer Sun Sparc Station gearbeitet. Die große Liebe zu Sun, Unix, Programmieren für Unix und vor allem für RCS kam bei mir nicht auf. Im Gegenteil, ich habe es gehasst.

In den folgenden Jahren klappte es auch nicht so richtig mit RCS, weil immer noch gängige Meinung war, eine Revisionskontrolle brauche man eigentlich gar nicht, ein echter Programmierer würde seinen Code auch ohne solche organisieren und sichern können. Wenn der Chef auf keinen Fall will, hat man als Angestellter schlechte Karten… Dazu kam erschwerend, dass ich etliche Jahre eigentlich nur für Navision Financials programmiert habe. Da dort der Quelltext fest in der Datenbank gespeichert ist, hat man erst einmal relativ schlechte Karten für eine Versionierung. 

Mit der verstärkten Hinwendung zu Linux  war auf einmal das Thema Versionierung wieder brandaktuell auf dem Tisch. Nachdem ich mich durch die üblichen Verdächtigen gekämpft hatte, blieben eigentlich nur noch 4 Kandidaten übrig. SVN, Mercurial, bazaar und Git. RCS, CVS und Perforce fielen schon den ersten Recherchen zum Opfer. Das nächste Opfer im Entscheidungskampf wurde bazaar. Es war zwar schon installiert, ich scheiterte dann aber an der Bedienung. Bei größeren Sachen habe ich gern mein Eye-Candy und einen ausgefeilten graphischen Client. 

Nächstes Opfer wurde Mercurial, die Papierform von Git überzeugte. Meine Entscheidung für SVN war eigentlich trotz allem  schon gefallen, flugs einen eigenen Server aufgesetzt und festgestellt: Gaida hat sich mal wieder fürchterlich übernommen.  Git und SVN schafften es bei mir in den Endkampf aufgrund von 2 Tatsachen: Für SVN sprach die Verfügbarkeit von Tortoise, für Git die Modernität und das in meinen Augen geniale Konzept der dezentralen Repos. Zum ersten Mal seit dem Aufsetzen meines Linux-Servers war ich so richtig am fluchen. Na klar, es gab SVN und git für Ubuntu. Einen sudo apt-get install … kann ja eigentlich jedes Kind absetzen. Hab ich auch getan. Klasse. 

Es stellte sich heraus, dass in meiner grenzenlosen Einfalt und Naivität vergessen hatte, ein entscheidendes Kriterium ernsthaft zu prüfen. Die Verfügbarkeit des graphischen Clients. Trotteliger Weise hätte ich nie im Traum daran gedacht, dass es Tortoise nicht für Linux geben sollte. Tortoise ist ein echter Pluspukt für SVN unter Windows, leider aber nicht für Linux. Nachdem ich mich mit eigentlich jedem, auch toten Client für Revisionskontrolle beschäftigt hatte und das Entsetzen immer größer wurde, fand ich SmartSVN, das optisch, von den Konditionen (Free und sehr bezahlbarer Kaufclient) und vom Support einen wunderbaren Eindruck machte. Zwar nicht ganz Tortoise, aber für meine Ansprüche schon im jetzigen Entwicklungsstadium als sehr ausgereift und in der Entwicklung sehr lebendig. An dieser Stelle noch einmal einen recht herzlichen Dank an Herrn Singer von syntevo, der mir SVN zwar nicht unbedingt ausredete, aber mein Interesse noch einmal in Richtung git lenkte. 

Das Problem des graphischen Clients hatte ich nun von den Hacken, der SmartSVN ist einfach nur genial, vor allem aber plattfomübergreifend, was für mich bei Web-Entwicklung relativ wichtig ist. Grafik und Doku mache ich jetzt zwar mehr und mehr auch unter Linux, manche Tools habe ich aber unter Windows und möchte auf meine Repositories aben auch unter Windows und vielleicht auch Macces zugreifen können, ohne mich jedes Mal an einen neuen Client gewöhnen zu müssen. 

Das womit der Revisionierung war damit geklärt und fing auf jeden Fall mit Smartxyz von Syntevo an. Die weitaus wichtigere Frage war jetzt, wohin mit dem Zeug. Git oder SVN war mir zu diesem Zeitpunkt eigentlich völlig egal, Ausschlusskriterium war diesmal, welchen Server kriege ich schneller ans laufen und wie verwalte ich den Kram. Die jeweiligen Daemons waren schnell aufgesetzt und ich stellte fest, daß ich allein mit einem Revisionierungssystem keinen Blumentopf gewinnen würde. Das oben schon angesprochene Eye-candy fehlte. Im Klartext: Wenn ich mich entschließe, Revisionen zu halten, dann aber auch richtig. Das heisst: Ohne Projektverwaltung, Bugtracker, Webanbindung läuft überhaupt nichts. Als mir diese Tatsache bewusst wurde (nach der Installation von Track, Redmine …) war ein eigener dedizierter Server gestorben. Ich wollte doch einfach nur komfortabel arbeiten und nicht die nächsten Monate mit der Organisation von Datenhaltung, -bereitstellung und ordentlicher Präsentation meiner Arbeit verbringen.

An diesem Punkt starb SVN. Auf dem eigenen Server hätte für mich ein zentrales Repository durchaus sehr viel Sinn gemacht, mögliche Performanceverluste durch die Arbeitsweise hätte allein die Netzwerkgeschwindigkeit wettgemacht, was solls, wenn beim Auschecken ein paar MB mehr oder weniger über das Netzwerk gehen. Bei ausserhäusiger Haltung der Daten sehe ich dieses Problem als ein wenig ernster an. Die Entscheidung stand in diesem Moment fest, git würde es sein und bleiben, einen Client hatte ich, die Welt war schön. Was fehlte, war ein Hoster mit viel PlusPlusPlus. Projektverwaltung, Timeline, möglichst viele aktive Projekte, Projektmanagement, Bugtracker. Praktisch alles, woran ich mich privat verhoben hatte. 

WOCHEN SPÄTER: Ich hatte zwischendurch den Artikel einfach in der Ecke liegen und schimmeln lassen. Die Entscheidung für git finde ich immer noch gut, es ist genau so, wie ich es mir vorstelle. SmartGit ist wieder ein Stück weiterentwickelt worden und läuft gut. Das einzige Problem habe ich momentan bei der Wahl des geeigneten Hosters. Github ist Klasse, nur ein wenig beschränkt im Platz. Da man laut deren Aussage unbegrenzt freie Software darauf hosten kann, werden ich meine Projekte dort ablegen. Das Bedienkonzept ist toll, das Platzangebot eigentlich auch. Meine privaten Daten, die ich versioniert extern ablegen möchte, kommen zu ProjectLocker. Dort gefallen mir der sehr viel größere kostenlose Speicherplatz und die technischen Möglichkeiten, die ich nicht mal ansatzweise ausnutze. Zum täglichen Arbeiten gefällt mir github wesentlich besser und mehr am Prinzip von git orientiert. Es arbeitet sich einfach klasse damit und ich bin restlos begeistert. Jetzt muss ich nur noch mehr als die Grundprinzipien von Git verstehen, das Ding kann einfach mehr, als ich hoffentlich je brauchen werde.

Leave a Reply