Der Mensch ist ein Gewohnheitstier. Leider auch im Machen von Fehlern. Ein Beispiel für eine solche Fehl-Leistung hat mich gestern wieder im Zusammenhang mit Eclipse und der SVN-Verwaltung neu angelegter, kundenspezifischer PHP-Projekte ereilt. Für die PHP-Entwicklungsarbeit nutze ich primär Eclipse unter Linux.

Beim Zusammenstellen der Verzeichnisse und Dateien für neue PHP-Projekte unter Eclipse kopiere ich manchmal ganze Verzeichnisstrukturen aus anderen, früheren PHP-Projekten. Wenn ich dabei zu bequem vorgehe, erwische ich beim Datentransfer auch alle vorhandenen “.svn”-Verzeichnisse innerhalb der kopierten Verzeichnishierarchie.

Vergesse ich nun (wie gestern geschehen), diese “.svn”-Verzeichnisse zu löschen, bevor ich eine Zuordnung des neuen kundenspezifischen PHP-Projekts zu einem SVN-Repository vornehme, so führt dies zwangsläufig zu Problemen mit der Versionsverwaltung der kopierten Dateien im neuen PHP-Projekt. Je nach Projekt-Setup

• wundert man sich anschließend ggf. über unabgeschlossene SVN-“Commit”-Vorgänge bzgl. der (kopierten) Verzeichnisse in das eben zugeordnete SVN-Repository
• oder aber man erkennt an der grafischen Darstellung des PHP-Explorers, dass es zugrunde liegende SVN-Links zwischen dem neuen und den alten Projekten gibt, die man im neuen, kundenspezifischen Projekt aber nicht haben will und auch nicht beabsichtigt hatte.

Um die durch die Kopiererei verkorkste SVN-Situation unter Eclipse zu bereinigen, muss man das neu angelegte Projekt mit den kopierten Verzeichnissen wieder von SVN lösen, die kopierten “.svn”-Verzeichnisse rekursiv beseitigen – also löschen – und dann erneut die Zuordnung des neuen Projektes zu einem SVN-Repository durchführen.

Aber der Reihe nach.

2 Arten der Nutzung vorhandener Arbeitsergebnisse und Dateien in neuen PHP-Projekten unter Eclipse

Beim Anlegen von bestimmten neuen PHP-Projekten unter Eclipse stelle ich mir als Ausgangspunkt meiner Arbeit Verzeichnisstrukturen zusammen, bei denen ich die Früchte bisheriger Arbeit nutze. Hierbei gibt es u.a. zwei Hauptvarianten:

Zugriff auf Dateien zentraler Bibliotheken

Dabei spielt zum einen der Zugriff auf Verzeichnisstrukturen zentraler Klassen- und Funktions-Bibliotheken eine Rolle. Diese Bibliotheken und deren Dateien werden bei mir über eigene spezielle Projekte gepflegt. Sie stellen das Fundament dar, auf dem kundenspezifische Projekte aufbauen können.

Die Dateien der zentralen kunden-unspezifischen Bibliotheken (und ihre dort definierten Klassen/Funktionen) können und sollen von anderen Projekten genutzt werden. Den Zugriff auf solche Ressourcen von einem kundenspezifischen PHP-Projekt aus erreiche ich unter Eclipse durch Ordner-Verlinkung und ein entsprechendes Setup der PHP-Build-Pfade.

Man legt den neuen Ordner im Projekt einfach als Verweis auf ein vorhandenes Verzeichnis an.

(Man ignoriere die Fehleranzeige bei den Projekten – so schlimm wie das erscheint, ist die Situation in meinen Projekten wahrlich nicht 🙂 . Der Fehler vererbt sich durch regelmäßige Referenz auf bestimmte phpmyadmin-Dateien.

Je nach Rechte-Setup kann ich danach von einem spezifischen Kunden-Projekt aus die zentralen Ressourcen bei Bedarf auch modifizieren. Das Ergebnis steht dann automatisch auch allen anderen kundenspezifischen Projekten zur Verfügung. Für die Unterstützung der “Content-Assist”-Funktionalität (Vorschläge beim Coding – Variablen, Klassen etc.) muss man im PHP-Projekt ggf. die Build-Pfade richtig setzen.

Die SVN-Versions-Verwaltung der zentralen Bibliotheken erfolgt in
meinem Fall natürlich getrennt von der SVN-Verwaltung des spezifischen neuen Kunden-Projektes. Die SVN-Verwaltung der zentralen Klassenbibliotheken führe ich über deren eigene Projektumgebung und gemäß des zugehörigen SVN-Setups durch und nicht über die Kundenprojekte.

Die Eclipse SVN-Plugins erkennen die verlinkte Verzeichnis-Struktur der Kundenprojekte und reagieren adäquat:

Die per Link eingebundenen Verzeichnisse und Dateien werden beim Ein- und Auschecken in das spezifische SVN-Repository des neuen kundenspezifischen PHP-Projektes ignoriert. Das ist vernünftig, weil ressourcenschonend und so auch von mir gewünscht. Die Projekte für die zentralen Bibliotheken habe ihr eigene SVN-Repository-Verwaltung – unabhängig von meinem kundenspezifischen Projekt. So weit, so gut.

Kopierte Verzeichnisse und Dateien, die projektspezifisch verändert werden

Zum anderen “kopiere” ich mir aber auch etliche Verzeichnisse mit spezifischen Klassendefinitionen und PHP-Programmen in mein PHP-Projekt. Dabei verlinke ich die entsprechenden Ordner nicht wie bei der Benutzung echter, zentral gepflegter Bibliotheken:

Ich kopiere, weil die entsprechenden Files (Programme, Funktionen, Klassen) projektspezifisch verändert werden sollen.

Die kopierten Verzeichnisse können dabei durchaus eine komplexe Subverzeichnisstruktur aufweisen. Einen Teil der Verzeichnisstrukturen richte ich dabei zudem auf Samba-Verzeichnissen ein, so dass die entsprechenden Dateien unter (virtuellen) Windows-Maschinen parallel auch in Dreamweaver-Projekte eingebunden werden können. (Wie man einen entsrpechenden durchgehenden Arbeitsfluss gestaltet, beschreibe ich vielleicht mal in einem gesonderten Beitrag). Aus Hygienegründen trenne ich das Samba-Verzeichnis vom Eclipse-Workspace-Verzeichnis ab. Unter Eclipse führe ich alle Ressourcen aber wieder durch geeignete Projekt-Setups zusammen.

Dabei schließe ich Dreamweaver-spezifische “_notes”-Verzeichnisse und “*.LCK”-Dateien, aber auch “.svn”-Verzeichnisse aus der Projektstruktur- und Build-Verwaltung über das Setzen von rekursiven “Ressource-Filtern” aus.

Im PHP-Explorer erscheinen die entsprechenden Verzeichnisse und Dateien dann nicht mehr ! (SVN geht natürlich trotzdem).

Die erforderlichen initialen Kopiervorgänge führe ich der Bequemlichkeit halber oft außerhalb von Eclipse auf Kommandozeilenebene oder mit einem Dateimanager durch. Manchmal benutze ich aber auch die Exportfunktionalität innerhalb von Eclipse.

Ein klassisches SVN-Problem entsteht anschließend, wenn ich aus Unachtsamkeit oder Bequemlichkeit die aus den älteren Projekten vorhandenen “.svn”-Verzeichnisse in das neue Projekt mit hinein kopiert habe. Und das können je nach Tiefe der Verzeichnisstruktur sehr, sehr viele “.svn”-Ordner sein (pro vorhandenem Subverzeichnis nämlich ein “.svn”-Ordner!).

Manchmal vergesse ich leider die kopierten “.svn”-Verzeichnisse einfach aufgrund anderer Themen, die mir dazwischenkommen (ja das Alter!), und wegen der gesetzten Ressource-Filter fallen mir die kopierten “.svn”-Ordner anschließend auch nicht mehr ins Auge.

SVN übernimmt die Verwaltung der kopierten Verzeichnisse und Dateien nicht wie gewünscht

Nach den ersten Schritten im Projekt erreicht man dann schnell ein Stadium, in dem man seine Ergebnisse der Versionsverwaltung SVN anvertrauen möchte.

Mein SVN-Plugin stellt unter dem Menüpunkt “SVN >> Share Projects …” eine menügeführte Möglichkeit zur Zuordnung eines Projekts zu einem Repository bzw. einem Unterbereich davon zur Verfügung. Ich “share” also mein
neu angelegtes Projekt und platziere es in einem eigenen SVN-Repository oder einem eigenen Zweig eines vorhandenen Repositories.

Natürlich möchte ich nun, dass bei der Anlage dieses projektspezifischen Repository-Bereichs eine initiale Erfassung auch derjenigen Verzeichnisse und Dateien erfolgt, die in mein kundenspezifisches Projekt kopiert wurden. Genau das funktioniert aber leider nicht wie erwartet, wenn in den Verzeichnissen bereits gültige “.svn”-Ordner existieren!

SVN meint dann, dass diese Verzeichnisse ja schon einer SVN-Verwaltung unterliegen würden und nutzt SVN-interne Links auf die bereits verwalteten SVN-Ressourcen.

Das ist natürlich nicht im Interesse meines neuen Projekts – ich bewege mich da ja in einem völlig anderen Kontext und was dort mit den kopierten Dateien geschieht, hat mit den in den Änderungen, die in der Versionsverwaltung eines anderen Projektes erfasst werden, nichts zu tun. Die SVN-interne Verlinkung ist im vorliegenden Fall sogar schädlich bis gefährlich. (In anderen Fällen als dem beschriebenen mag eine SVN-Verkettung aber durchaus sinnvoll sein).

Leider weiß SVN aber nichts von meiner stumpfsinnigen Kopiererei und meinen Intentionen. Es nimmt die Hinweise in den entdeckten (kopierten) “.svn”-Verzeichnissen ernst.

Man merkt die Verkopplung des neuen Projektes mit älteren auf SVN-Ebene u.a. durch einen roten Pfeil in der rechten unteren Ecke der Dateisymbole im PHP-Explorer.

Der Pfeil zeigt die Referenz auf SVN-Ebene zu einem anderen Repository-Container eines anderen Projektes an. Commit-Vorgänge auf dem aktuellen Projekt werden ggf. nicht als abgeschlossen angezeigt, wenn im anderen Projekt durchgeführte Dateiänderungen noch nicht “committed” wurden. Auch sonst kann es zu erheblichen Verwirrungen kommen

Bereinigung des SVN-Problems – Rekursives Entfernen der kopierten “.svn”-Ordner

Was ist in dieser Situation zu tun? Es ist notwendig, das neu angelegte Projekt vom kopierten Ballast anderer Projekt zu befreien und erst danach – also im aufgeräumten Zustand – einem SVN-Repository zuzuordnen. Vorher lösen wir das Projekt aber von der schon vorgenommenen Versionsverwaltung. Folgende Schritte sind somit durchzuführen:

• Schritt 1: Man muss das neu angelegte PHP-Projekt zunächst vom SVN-Repository “disconnecten”.
• Schritt 2: Man muss nun alle kopierten “.svn”-Ordner löschen.
• Schritt 3: Erneute Zuweisung des Projektes an SVN und an ein neu anzulegendes SVN-Repository oder einen neuen Zweig eines vorhandenen Repositories

Das hört sich einfach an. Schritt 2 kann sich ohne Shell-Einsatz aber als aufwändig erweisen.

Hinweis zu Schritt 1:
Die Durchführung von Schritt 1 ermöglicht ein Menüpunkt im verzeichnisspezifischen Kontext-Menü: “Team” >> “Disconnect”.

Dabei lässt man im nächsten Schritt auf Rückfrage auch die projektspezifischen “.svn”-Einträge löschen. Dabei bleiben allerdings – wie ein anschließender Blick auf die Verzeichnisstruktur zeigt – die ins Projekt kopierten “.svn”-Ordner unangetastet! Das musste man eigentlich erwarten.

Hinweis zu Schritt 2:
Schritt 2 ist wegen der Vielzahl der “.svn”-Verzeichnisse u.U. sehr zeitaufwändig. Ein rekursives Löschen der “.svn”-Verzeichnisse auf allen (!) Verzeichnisebenen der kopierten Ordner ist erforderlich.

Bei einer hinreichend komplexen und umfangreichen Ordner-Struktur braucht man dann gar nicht anfangen, mit “Dolphin” oder anderen grafischen Dateimanagern
herumzuwurschteln. Ich nutze in einer solchen Situation lieber die Kommandozeile.

Dort gibt es dann im Hauptverzeichnis der kopierten Ordnerstruktur (hier: “/projekte/dw/ntcomp” ) folgende Möglichkeit für die Vorsichtigen:

tux@my:/projekte/dw/ntcomp> find . -name “.svn” -exec rm -r {} \;
rm: reguläre Datei (schreibgeschützt) ?./ntc/scripts/_notes/.svn/prop-base/dwsync.xml.svn-base? entfernen? yes

Hierbei muss man allerdings das Entfernen jeder einzelnen Datei unterhalb der gefundenen “.svn”-Verzeichnisse bestätigen! Auch das ist aufwändig – wenn auch vielleicht schneller als die Arbeit mit grafischen Dateimanagern.

Für die weniger Vorsichtigen tut es auch ein

tux@my:/projekte/dw/ntcomp> find . -name “.svn” -exec rm -fR {} \;

oder ein

tux@my:/projekte/dw/ntcomp> find . -type d -name .svn | xargs -i rm -r {};

In den beiden letzten Fällen muss man die Löschaktion nicht bestätigen und das rekursive Löschen braucht nur Millisekunden. Also Vorsicht: Doppelt und dreifach checken, dass man das Richtige im richtigen Verzeichnis tut – und vorher lieber mal alles sichern! Lieber auch nur den “.” als “./” angeben. Vergisst man bei “./” durch Fehler den “.” hat dies je nach Rechtesituation evtl. gravierende Auswirkungen!

Wenn ich alles richtig gemacht habe, ist mein neues PHP-Projekt schließlich von allem ungewollten SVN-Ballast alter Projekte, aus denen ich Verzeichnisse kopiert habe, befreit.

Und dann funktioniert auch die SVN-Verwaltung des neuen Projektes mit den sich spezifisch entwickelnden Klassen und Programmen wieder wie gewünscht – nämlich vollständig und unabhängig von alten Projekten !

Schritt 3 braucht für diejenigen, die SVN unter Eclipse einsetzen, keine besondere Erläuterung. Man “shared” das Projekt erneut (Menüpunkt “SVN” >> “Share Projects …” ) und hangelt sich durch die menügeführte SVN-Einrichtung für das Projekt.

Viel Spaß weiterhin mit Eclipse, SVN und PHP.