Verwendung von Subclipse

Inhalt:

Installation

Konfiguration

Die im Default eingestellte SVN-Client-Library (über JNI) hat bei mir dazu geführt dass ich das Passwort nicht speichern lassen konnte und es deshalb bei jedem Zugriff neu eintippen musste. Außerdem habe ich an anderer Stelle beobachtet, dass nach dem Umbenennen eines Packages das anschließende Commit fehlschlug.
Deshalb habe ich das "SVN interface" in den Preferences auf "SVNKit (pure Java)" umgestellt:

SVN Repository

Über "Window" -> "Show View" -> "Other" finden wir das "SVN Repository":

In dieser View per Rechtsklick auf "New" -> "Repository Location" gehen und die URL

Projekt zum Repository zufügen

Im folgenden werde ich mein Stateless-Beispiel dem Repository zufügen.
Der erste Schritt ist es, im Repository ein Unterverzeichnis anzulegen. Dazu in der Repository-View Rechtsklick und "New" -> "New remote folder" wählen und ein Verzeichnis "Stateless" anlegen:

ACHTUNG: Subclipse zeigt das neue Verzeichnis erst in der "SVN Repository"-View an, wenn wir Rechtsklick -> "Refresh" aufrufen. Dies ist nach allen Aktionen nötig, bei denen Dateien dem Repository zugefügt werden.

Jetzt wählen wir nacheinander die vier Teilprojekte der EAR-Anwendung und führen jeweils Recktsklick -> "Team" -> "Share Project" aus.
Als "Repository Type" wählen wir "SVN":

Im nächsten Schritt wählen wir unsere Repository Location:

Leider können wir nicht mit dem Default "Use project name as folder name" arbeiten, da das sonst direkt in der Wurzel unseres Repositories landen würde. Deshalb die Option "Use specified folder name" wählen und als Pfad "Stateless/Stateless" (im eben angelegten SVN-Verzeichnis "Stateless" wird im Beispiel ein eigenes Unterverzeichnis für das EAR-Projekt angelegt) eingeben.

Im nächsten Schritt wird ein schöner Kommentar eingegeben, und wir klicken auf "Finish".
Jetzt kommt eine Auswahl der Dateien die wir zufügen wollen:

Hier sollten wir alles entfernen was beim Build-Vorgang entsteht:

Beim Projekt "Stateless" werden folgende Dateien ignoriert:

• StatelessClient.jar, StatelessEJB.jar und StatelessWeb.war im Verzeichnis "EARContent" (nicht aber der Inhalt von "EARContent\META-INF")

In den Projekten "StatelessClient", "StatelessEJB" und "StatelessWeb" werden folgende Dateien ignoriert:

• Alles in "build"
• Alles in "build/classes"

Das Ergebnis sieht so aus (nach einem "Refresh" des Repositories):

Im Project Explorer haben unsere Projekte jetzt alle neue Icons erhalten. Hinter jeder Datei stehen Version und letztes Commit-Datum. Im Projektverzeichnis wird in jedem Unterverzeichnis ein neues Unterverzeichnis ".svn" angelegt.

Projekt aus SVN holen

Jetzt wollen wir den umgekehrten Weg gehen: ein Projekt aus dem Subversion holen. Dazu Rechtsklick -> "New" -> "Project...". Wir wählen die Option "SVN" -> "Checkout project from SVN".

Im nächsten Schritt wählen wir die Repository Location:

Wir wählen die vier Projekte der EAR-Anwendung aus (aber NICHT das Wurzelverzeichnis "Stateless" sondern nur die vier Unterverzeichnisse):

Im nächsten Schritt belassen wir alles bei den Defaults:

Und nochmal Defaults:

Commit

Nachdem ich etwas an einer Datei geändert habe, möchte ich es ins Repository zurückspielen.
Dazu wähle ich alle Projekt der Enterprise Application aus, dann Rechtsklick und "Team" -> "Synchronize with Repository" wählen. Beim ersten Aufrufen kommt die Abfrage ob wir hierzu die "Team Synchronization"-Perspektive öffnen wollen. Hier sagen wir natürlich "Yes". Danach erfolgt ein Subversion-Zugriff, und wir sehen links einen Baum der von uns geänderten Dateien. Im Beispiel habe ich etwas an der GeometricModelBean geändert. Die Verzeichnisse "build" und "build\classes" werden angezeigt, weil ich das Projekt aus Subversion abgerufen hatte, und sie nicht in der Quellcodeverwaltung vorhanden sind.

Da wir die "build"-Verzeichnisse nicht haben wollen, sagen wir Subclipse, dass es sie in Zukunft ignorieren soll: Rechtsklick und "Add to svn:ignore" aufrufen:

Diese Ingore-Listen werden im versteckten ".svn"-Unterverzeichnis des jeweiligen Parent-Verzeichnisses geführt, und zwar in der Datei "dir-pros" oder auch "dir-props-base".

Jetzt führen wir einen Rechtsklick auf die geänderte Datei durch und wählen die Option "Commit...".

Natürlich nimmt man mich nicht als Vorbild, sondern trägt einen Kommentar über die Änderung ein !
Nachdem man das Commit durchgeführt hat, erscheinen plötzlich alle Verzeichnisse bis zur GeometricModelBean als "geändert":

Also Rechtsklick -> "Update". Dies holt die Änderungen aus dem Repository, wobei diese sich in diesem Fall nur eine geänderte Version des Verzeichnisses beschränken.

Die Projekt-Unterverzeichnisse tauchen in meinem Screenshot noch als "geändert" auf, weil sie nicht im Repostory vorhanden sind, nach dem Checkout erst von Eclipse angelegt wurden, und deshalb eine neue interne Version erhalten haben ! Wenn ihr mit einem Projekt arbeitet, das ihr nicht aus dem Repository geholt habt, tritt dieses Phänomen nicht auf. Wir lösen es, indem wir "Update" wählen und sie damit ebenfalls im Repository aktualisieren.

Dieses doch reichlich nervige dauernde Verzeichnis-Anpassen (das passiert normalerweise nach jedem Commit, und kann bei zwei parallel am Projekt Arbeitenden zu reichlich Konflikten führen) läßt sich in den Preferences abschalten, indem der Haken "Show out of date folders" entfernt wird.

Update

Jetzt kommt der umgekehrte Fall: ein schlechter Mensch hat etwas am Projekt geändert und wir wollen diese Änderung haben. Dazu wieder die Option "Team" -> "Synchronize with Repository" wählen.
Jetzt sollte die geänderte Datei (im Beispiel wiederum die "GeometricModelBean") mit dem "Update"-Icon versehen auftauchen:

Merge

Jetzt kommen wir zum Worst case: während wir in einer Datei etwas geändert haben hat dies der oben erwähnte Schlechte Mensch ebenfalls getan. In der Team Synchronization wird die Datei jetzt so dargestellt:

Durch Doppelklick auf die Datei kommen wir in den Merge-Modus. Unser Ziel ist es jetzt, unsere Datei auf Festplatte mit der Datei aus dem Subversion abzugleichen. Im Beispiel passierten folgende Änderungen: Lokal wurde der Methodenkommentar des Parameters "b" von "computeCuboidSurface" geändert, während gleichzeitig remote der Kommentar des Parameters "a" der gleichen Methode geändert wurde (in beiden Fällen wurde das ">" durch ein ">" ersetzt, da ein ">" im generierten HTML falsch gewesen wäre).
Wir können jetzt mit den beiden Buttons rechts in der Toolbar durch die Änderungen blättern:

Zuerst einmal übernehmen wir die "Non conflicting changes" aus dem SVN in die lokale Datei. Dadurch ist die "fremde" Änderung im Code schon in unseren Code übernommen:


Falls wir in der gleichen Codezeile wie unser ominöser Gegenspieler eine Änderung durchgeführt hätten, müssten wir die jetzt über die beiden Buttons "Copy Current Change from Left to Right" bzw. "Copy Current Change from Right to Left" manuell zusammenwürfeln.

Nachdem wir so eine Datei zusammengebastelt haben die uns gefällt können wir sie einchecken. Dazu müssen wir sie allerdings zuerst als "Merged" markieren (Rechtsklick, "Mark as Merged").

Jetzt können wir "Commit" wählen und unser Gegenspieler sollte beim nächsten "Update" die neue Datei erhalten.

Lock

Um die Situation eines Merge zu verhindern, kann man ein exklusives "Lock" auf eine Datei setzen. Solange sie gesperrt ist, kann niemand Änderungen comitten.
Um ein Lock zu erstellen: Rechtsklick auf die Datei, und "Team" -> "Lock" wählen.

Dass ein "lock" auf der Datei steht, erkennt man am geänderten Icon.
Natürlich sollte man nach getaner Arbeit nicht vergessen, die Datei wieder mittels "Unlock" freizugeben.

Möchte ein anderer Entwickler selbst ein "lock" auf die gesperrte Datei, dann erhält er eine Fehlermeldung "Lock request failed: 423 Locked" in der SVN-Konsole. Im "lock"-Dialog gibt es allerdings die Möglichkeit des "Steal lock", die mit Gewalt das Lock überträgt ;-)
Es ist ihm aber möglich, Änderungen an seiner lokalen Version der Datei vorzunehmen. Diese kann er allerdings nicht comitten, dies führt ebenfalls zu einer Fehlermeldung. Sobald das "lock" aufgehoben ist, muss er seine Änderungen mittels "Merge" in den SVN-Stand einpflegen.

History

Im "SVN Repository" können wir uns per Rechtsklick die Historie eines Items anzeigen lassen (im Beispiel die oben verwendete "GeometricModelBean". Das gleiche Fenster finden wir auch in der "Synchronize"-Perspective.

Hier können wir uns auch den Code einer alten Version anschauen, indem wir die Datei per Doppelklick öffnen.

---

Stand 01.12.2007
Historie:
28.11.2007: Erstellt aus Vorjahresdoku, aktualisiert auf Eclipse 3.3, Subclipse 1.2.4, mehr Screenshots.
01.12.2007: "lock" beschrieben