SVN on basis42

Windows für Web-Entwickler ist doof

Fri, 13 Jul 2012 08:19:18 +0200

Ich weiß, das wissen wir alle schon länger, aber ich durfe gerade eine svn Workingcopy unter Linux auschecken, nur um einen Symlink anlegen zu können und diesen anschließend auch ins Repository commiten zu können. Darüber ob Symlinks im svn gut sind läßt sich sicher streiten, aber manchmal muss es eben doch sein und frei nach Monty Python möchte ich einfach die prinzipielle Möglichkeit haben Babies zu bekommen, äh ich meine natürlich Symlinks anlegen zu können. So, jetzt geht’s mir schon ein wenig besser :-)!

Erste Schritte mit Git

Fri, 12 Nov 2010 18:30:31 +0100

Es hat lange gedauert, bis es bei mir soweit war, das ich mich mit Git beschäftigen musste(keine Abneigung, aber bei SVN hat mir einfach nichts gefehlt), aber just diese Woche ergab sich die Gelegenheit. Eine Library(PHPThumbs) die ich verwenden möchte hosted ihren Code auf github.com und da mir die Library gut gefällt, mir aber eine Funktion zum Erzeugen von Tiles aus einem Image gefehlt hat, habe ich das kurzerhand als Anlaß genommen, mir mal Git anzusehen, indem ich das Projekt forke, mein benötigtes Plugin implementiere und dann das ganze dann hoffentlich zurück fließen lassen kann. Das Plugin ist implementiert und den Pull-Request hab ich auch rausgeschickt und nun warte ich ganz gespannt, was als nächstes passiert, ich bin ja soooo aufgeregt :-). Und weil mir das Ganze so gut gefallen hat mit dem social coding(und das obwohl ich nicht mal ein Facebook Acount habe, he, he) hab ich gleich mal meine Zend Framework Beispiel Applikation (urlino.com) nach Github migriert. Jetzt heißt es warten und schauen, wann ich zum ersten Mal geforkt werde. Ich hab schon mal das “Fork me on GitHub” Ribbon anschraubt :-). Ansich ist Git ja wirklich angenehm, wobei ich zumindest jetzt am Anfang noch keine unerwartete Offenbarung erfahren habe, ist halt ein SCM, scheint meinen Bedürfnisse zu erfüllen und ist auch recht intuitiv zu bedienen, aber eine Sache ist mir zumindest untergekommen, die mir momentan noch nicht gefallen will: Und zwar das Einbinden von externen Libraries von denen es kein Git Repository gibt, also quasi ein svn:externals für Git, welches nicht nur mit Git Repositories spricht(gibt es und wird über submodules realisiert), sondern es auch erlaubt entfernte SVN (Teil-)Repositories auch in Git einzuhängen, was umgekehrt, also Git Repos in SVN Repo, Klasse funktioniert. Falls da ich da was übersehen habe und jemand eine clevere Lösung hat, das wär schon was :-).

svn: Tree Conflicts als einziger Commiter

Thu, 26 Aug 2010 17:45:39 +0200

Alle paar Wochen laufe ich in die selbe Falle, beim Refactoring eins kompletten Stangs von Dateien die in einem svn Repository liegen, endet es in einem Tree Conflict der unerwartet ist, wenn man sich die Definition eines Tree Conflicts in der svn Dokumentation ansieht:

svn: Nested working copy, und jetzt?

Thu, 13 Aug 2009 16:56:18 +0200

Nachdem ich mich gerade mit einer eben solchen ungewollten nested working copy(es gibt da sicher auch praktische Anwendungfälle einer gewollten nested working copy, z.B. als Alternative zum einbinden von externals) herumgeschlagen habe, stellt sich als erstes die Fage wie komme ich zu einer solchen und vielleicht noch viel wichtiger: Wie werde ich sie wieder los? Die erste Frage beantwortet sich ganz einfach: Mal kurz einen Moment nicht nachgedacht, das man sich in einer mit svn verwalteten Struktur befindet und schwubs hat man beim manuellen refactorn ein Directory verschoben ohne sich den Kommandos ‘svn move’ zu bedienen. In diesem Moment hat man den Bezug der svn root zu diem Teilstrang aufgelöst. Gleichzeit erkennt der svn-Client aber ganz richtig, das es sich bei dem noch vorhanden Strang um eine svn Struktur handelt. Zack da ist sie, unsere nested working copy, die wir gar nicht wollten. Wenn wir Glück haben bemerken wir das Missgeschick recht zügig, machen ein revert und machen dann ein svn move und alles ist gut. Wenn wir aber Pech haben, haben wir so viel über den Haufen geworgen, das es ein echtes Stück Arbeit, das alles wieder zurückzudrehen und geordnet nochmals durchzuführen. In diesem Fall hilft es, in den nested working copies die .svn Verzeichnisse zu löschen. Einziger Wermutstropfen: Die History der files geht verloren, was unter Umständen zu verschmerzen ist. Und weil es mir so gut geholfen hat, die Zeile zum rekursiven Löschen der .svn Directories, das Kommando löscht alle .svn Directories vom aktuellen Pfad abwärts:

Codeverwaltung mit Hilfe eines svn-Repositorys

Tue, 21 Apr 2009 16:53:49 +0200

Nachdem ich in der letzten Zeit häufiger den Aufbau und die klassischen Arbeitsabläufe bei der Codeverwaltung eines mittelmäßig komplexen PHP Projekts zum Besten gegeben habe, stellte sich beim Betrachten der klassischen Struktur in einem svn Repository doch häufiger die Frage: Trunk, Branches, Tags … wass’n das und wofür brauch ich das überhaupt und was passiert eigentlich beim branchen, tagen, mergen, etc. ? Dieser Artikel soll als praktischer Einstieg in die Codeverwaltung anhand eines svn Repositorys unter Verwendung des subclipse Plugins unter Eclipse dienen. Vorweg anzumerken ist natürlich, dass der von mir vorgestellte Arbeitsablauf sicher nicht der einzig “richtige” Weg ist, sondern lediglich den Weg beschreibt, der sich für mich als praktikabel erwiesen hat und der, wie ich finde, für den Einstieg die wenigsten Fallstricke bereithält. Bevor wir allerdings zu den praktischen Handgriffen kommen, betrachten wir zuerst einmal unsere eigentliche Problemstellung anhand eines hypothetischen Projekts und vergessen wir vorerst all die o.g. Verzeichnisse, Strukturen, etc.: Die Entwickler der FrickelNReload AG haben das Projekt TOLL 1.0 nicht nur laut Spezifikation abgeliefert, sondern, weil sie clever waren, das ganze Projekt auch in einem svn-Repository abgelegt, um Änderungen zu dokumentieren, selbige zurückdrehen zu können, etc. Tag X kommt und die Software wird vom erwartungsvollen Anwendern in Betrieb genommen! Aus Erfahrung weiß man: Es wird kaum 10 Minuten dauern, da ist schon der erste Featurerequest für das nächste Release geschrieben. Und, auch wenn die Entwickler einen anständigen Haufen Testcases geschieben haben, wird sich wohl auch bald der erste Bug finden… Da der Releaseplan für das nächste Release sehr ambitioniert ist, ist unmittelbar nach dem releasen von TOLL 1.0 mit der Entwicklung von TOLL 1.1 begonnen worden und auch die ersten Featurerequests wurden aufgenommen. Kaum haben die fleißigen Entwickler die Arbeit für das kommende Release aufgenommen und grundlegende Änderungen in einigen Teilbereichen begonnen, trudelt der erste Bugreport ein. Da der Bug kritisch ist, duldet das fixen keinen Aufschub, es muss sofort ein neues Release her. Im Handumdrehen haben wir ein Problem: Unser Code befindet sich aufgrund der Entwicklung von TOLL 1.1 in einem nicht konsistenten Zustand, so dass wir nicht ohne weiteres besagten Bug fixen können ohne sämtliche für die Entwicklung von TOLL 1.1 gemachte Änderungen zurückzudrehen bzw. gemachte Änderungen herauszuziehen, hinterher wieder zurückzupatchen oder was man sich da sonst noch verrücktes einfallen lassen mag. Zugegeben, natürlich lässt sich diese Situation mit konservativen Methoden der FrickelNReload AG retten, besser allerdings ist, sich von Anfang an der klassischen Struktur eines mit svn verwalteten Projekts zu orientieren, die aus den Verzeichnissen Trunk, Branches und Tags besteht. Wenn wir mal die Tags vernachlässigen, zu denen wir später kommen, dann hätte sich zum Zeitpunkt des Release von TOLL 1.0 lediglich im Trunk der Code von TOLL 1.0 befunden. Um nun die Entwicklung von TOLL 1.1 zu starten, wäre es sinnvoll gewesen, für diese Entwicklung einen eigenen Branch anzulegen. Dieser liegt, wer hätte es gedacht, im Verzeichnis Branches und ist im ersten Schritt, also bevor die Enwicklung von TOLL 1.1 beginnt, nichts weiter als eine Kopie des Trunks. Nachdem also halbwegs klar sein sollte, warum wir ein solches Feuerwerk abbrennen, ein Blick auf die Praxis. Im Folgenden gehe ich mal davon aus, dass das Anlegen eines neuen Projekts im svn-Repository samt dazugehöriger Ordnerstruktur keine besondere Hürde darstellt; sollte hier Interesse bestehen, bitte ich um einen kurzen Kommentar, dann werde ich hier entsprechendes ergänzen. Sehen wir uns also im Detail an, wie man einen Branch unter Eclipse mit Hilfe des Subclipse Plugins anlegt, wenn wir davon ausgehen, dass wir uns auf einer working copy des Trunks befinden: Zuerst über den Punkt Team des Kontextmenüs den Punkt ‘Branch/Tag…’ wählen: Im nächsten Schritt gilt es, den Namen bzw. daraus resultierend den Speicherort des Branches zu wählen, wobei der Speicherort(bzw. der Name) unter “Copy to URL” anzugeben ist. Defaultmäßig ist dort der Speicherort des Trunks vorgegeben, den man dann am einfachsten per Hand anpasst. Die weiteren Einstellungen bleiben wie vorgegeben: Typischerweise wird man wohl einen Branch auf Basis des aktuellen Trunks fahren wollen, sprich man belässt es beim vorgewählten HEAD revision of repository. Zusätzlich werden noch 2 weitere Optionen geboten, wobei mir die zweite noch nie in der Praxis untergekommen ist. Die dritte Option, working copy, macht Sinn, wenn man während eines Bugfixes im Trunk bemerkt, dass es mit einer kleinen Änderung dann doch nicht getan ist und man sich mit Hilfe eines Branches mehr Flexiblität verschafft. Anschließend sollte man seinem Branch unbedingt noch einen Namen in Form eines Kommentars geben, um diesen später ansteuern zu können. Gleichzeitig kann man seine working copy durch einen Haken bei “Switch working copy to new branch/tag” auf das durch Kopie erzeugte neue Verzeichnis setzen. In der Praxis hat es sich für mich allerdings bewährt, im Zweifel lieber Branch und Trunk in zwei einzelne working copies auszuchecken, da ansonsten das Potenzial für Verwirrung recht groß ist: Nach dem Klick auf Finish haben wir unseren Branch gefahren, was sich spannender anhört, als es wirklich ist, denn eigentlich haben nichts weiter getan, als eine Kopie unseres Trunk angelegt und dieses Anlegen der Kopie mit einer Revisionsnummer und einem Kommentar versehen. Ab sofort kann also im Branch “myBranch” fleißig entwickelt werden und der Trunk steht bereit für das Fixen von Bugs. Prinzipiell gibt es jetzt 2 Möglichkeiten, wie es weitergeht: