Opensuse, Firefox 4, Flashplayer 32 oder 64 Bit?

Unter Opensuse 11.4 ist der Firefox 4 Standard. Ich habe – wie immer schon – die 64 Bit Variante des Betriebssystems und des Firefox installiert. Zudem läuft KDE 4.6.2.

Nun denkt man so, dass der von Suse als RPM ausgelieferte aktuelle Flashplayer 10.2 in der 32Bit-Variante über den üblichen “nspluginwrapper”-Mechanismus mit Firefox 4 (64 Bi) vernünftig zusammenarbeiten würde. Schießlich ging das mit Firefox 3.6.16 (64 bit) unter Opensuse 11.3 ja auch problemfrei !

Beim Firefox 4 (64 Bit) ist dem leider nicht so! Komplexe Flash-Filme oder sogar Adobe eigene Flashelemente (etwa die Audio oder Video-Player) werden häufig durch Darstellungsfehler so entstellt, dass es keinen Spaß mehr macht, Flash-Seiten anzusehen. Fehler über Fehler ! Man fragt sich, ob das jemals vernünftig getestet wurde ….

In meiner Not habe ich dann mal wieder nach einer halbwegs aktuellen 64Bit -Variante des Flash-Players für Linux umgesehen. Damit habe ich früher schon ganz gute Erfahrungen gemacht. Fündig wird man zur Zeit unter

http://labs.adobe.com/technologies/flashplayer10/square/

Ich habe mir dort die aktuelle Version heruntergeladen. Zur Installation der “libflashplayer.so”-Datei unter Opnsuse sehen Sie bitte folgenden früheren Beitrag:

https://linux-blog.anracom.com/2009/01/26/kurztest-der-64-bit-version-des-flash-plugins-von-adobe/

Bitte nicht die vorher notwendige Deinstallation des “nspluginwrapper” vergessen.

Das Ergebnis des Tests der 64-Bit-Variante: Das allermeiste an Flash-Seiten wird richtiger und schneller dargestellt als mit der für 64-bit Linux und 64-Bit Firefox 4 völlig ungeeigneten offiziellen 32Bit-Variante des Players.

Bleibt erneut die Frage offen: Wann sehen die verantwortlichen bei Adobe endlich ein, dass sie für Linux eine vernünftige “offizielle” 64Bit-Unterstützung bieten müssen?

Eclipse, PHP – autocompletion, no proposals

Ein kleiner Tipp zur Autocompletion unter Eclipse für PHP:

Heute hatte ich mal wieder das Problem, dass beim Editieren einer Datei mit einer PHP-Klasse die “Autocompletion” mit dem zugehörigen Proposal-Fenster nicht funktionierte. Obwohl ich meterweise Variable und Funktionen für die Klasse definiert hatte, kam nach Eingabe von “$this->” keine Vorschlagsliste hoch.

Das entsprechende Popup zeigte traurigerweise immer nur “No default proposals”.

Das geschah interessanterweise jedoch nicht in anderen Projekten und auch nicht in anderen Verzeichnissen des aktuell von mir bearbeiteten Projekts.

Was war also die Ursache? Letztlich ganz einfach:

Die Datei, an der ich arbeitete, lag in einem Verzeichnis, der nicht in den Build-Pfad des Projektes integriert war. Dies wiederum lag daran, dass ich einen ganzen Verzeichniszweig nachträglich per Verzeichnisbrowser (Dolphin) in mein Projekt eingefügt hatte. Ich hatte die neuen Verzeichnisse also nicht mit Mitteln von Eclipse “importiert”.

Eclipse erkennt dann zwar beim nächsten Öffnen die neuen Dateien und markiert diese im PHP-Explorer auch mit einem Fragezeichen. (Ich hatte das “?” rechts unten am Verzeichnis- oder Datei-Namen bislang auf das SVN-Repository bezogen, das ich dem Projekt zugeordnet hatte, und vermutet, dass das “?” anzeigt, dass die Zuordnung des Verzwichnisszweiges und seiner Dateien zum SVN-Repository unklar ist.)

Aber wer meint, dass ein SVN-Commit oder eine Validierung oder ein Export in ein Remote-Filesystem unter Eclipse dazu führen würde, dass der neue Verzeichnis-Zweig mit all seinen Unterverzeichnissen und Dateien automatisch in den Build-Pfad des Projektes aufgenommen würde, der täuscht sich. Dies muss man im hiergegeben Fall einer Verzeichnismodifikation außerhalb der Eclipse-Tools vielmehr selbst erledigen.

Welche Verzeichnisse bereits im Build-Pfad berücksichtigt werden oder eben nicht, erkennt man über das Konfigurationsfenster zum “PHP Build Path”. Das öffnet man entweder über den Menüpunkt

Project >> Properties >> PHP Build Path

oder über das Kontextmenü des Projektes :

Klick mit RMT auf das Projekt im PHP-Explorer >> Build Path >> Configure Build Path >> PHP Build Path

(RMT: Rechte Maus-Taste).

Hier kann man die fehlenden Verzeichnisse zum PHP Build Path explizit hinzufügen.

Ein Klick auf den “OK”-Button löst dann einen neuen Lauf der DLTK-Indizierung unter Eclipse aus. Danach funktioniert dann auch der Proposal-Mechanismus für die Autocompletion beim Editieren des Codes wieder.

Eclipse für PHP unter Opensuse – IV

In diesem Teil der Eclipse-Reihe befassen wir uns damit, wie wir PHP-Projekte mit SVN-Repositories verbinden.

Eclipse bietet aus meiner Sicht ein ganz brauchbares SVN-Interface, das einen die wesentlichen Informationen zur Historie der Entwicklungsstände abfragen läßt. Ferner kann man Dateien unterschiedlicher Versionsstände in Vergleichseditoren öffnen, wobei die Unterschiede im Datei-Inhalte markiert werden. Hinzu kommen graphische Darstellungen der Historie. Wir gehen nachfolgend auf einige dieser naheliegenden Möglichkeiten der Eclipse SVN Tools kurz ein – vieles muss ich aber der eigenen Entdeckungsfreude des Lesers überlassen.

Voraussetzungen der Übung

  • Eclipse ist wie im Teil II und im Teil III beschrieben eingerichtet.
  • Die Subversive-Erweiterungen sind wie in Teil III beschrieben installiert. Insbesondere sind die Konnektoren zu SVN und die SVNKits von der über die Polarion-Plugins implementiert worden.
  • Es liegt ein PHP-Projekt “myproject” im Verzeichnis
    /MY_PFAD/wsp_ecl/myproject
    vor.
  • SVN (Version 1.6) und KDESVN sind im Linux-System installiert

Den Einsatz der linken oder rechten Maustaste deuten wir nachfolgend durch die Abkürzungen

  • LMT: Linke Maustaste
  • RMT: Rechte Maustaste

an.

Schritt 1: Vorüberlegungen zur Organisation von Projekten in SVN

Einführungen in SVN findet man u.a. unter folgenden Links:

Wir gehen hier nur kurz auf ein paar wichtige Eigenschaften ein. Ein SVN-Repository entspricht normalerweise einem Containerverzeichnis, zu dem der sog. “Repository Root”-Pfad führt. In einem Repository kann man mehrere Projekte gleichzeitig in verschiedenen “Unter-Verzeichnissen” (weitere projektspezifische Pfadanteile des Repositories) verwalten. Unterhalb eines Projektes im Repository liegen dann ggf. weitere spezielle Verzeichnisse (s.u.) “trunk”, tags”, branches”. In diesen – i.d.R. unter “trunk” – ist dann schließlich die eigentliche Hierarchie der Datei-Verzeichnisse des Projektes in verschiedenen Versionen abgebildet.

SVN Uebersicht

Die Inhalte eines Repositories sind letztlich also hierarchisch wie in einem Verzeichnisdienst oder einem Filesystem organisiert. Auf der Ebene des Linux-Filesystems ist diese Sub-Struktur eines Repositories aber nicht direkt einsichtig, da sie über eine (hierarchische) Datenbank verwaltet wird. Man benötigt für die Darstellung der Repository-Struktur einen SVN-Client oder Kommandozeilen-Tools.

Bie jeder Änderung am Repository (z.B. durch Einchecken/Committen einer geänderten Datei) erhöht sich die Revisionsnummer des Repsoitories. Die SVN-Tools von Eclipse zeigen übersichtlich pro Datei/Verzeichnis an, bei welcher Revisionsnummer die letzte Änderung der Datei/des Verzeichnisses erfolgte.

Sowohl auf der Ebene des gesamten Repositories wie auch auf der Ebene der enthaltenen Projekte kann man 3 empfohlene Haupt-Unterverzeichnisse anlegen:

  • trunk – in
    diesem Verzeichnis sind die aktuellen Dateien/Directories des Projektes in den aufeinander folgenden Versionen der Entwicklungsarbeit enthalten
  • tags – hier bringt man Abbilder bestimmte Entwicklungsstände (Versionen) unter, die nicht mehr verändert werden sollen
  • branches – hier verzweigt man Entwicklungsstränge, die aber eine gemeinsame Wurzel haben sollen.

Diese speziellen Hauptzweige entsprechen in der hierarchischen Struktur des Repositories letztlich auch wieder nur Verzeichnissen, die aufgrund ihres Namens jedoch von SVN unterschiedlich behandelt werden. Solche Haupt-Zweige pro Projekt oder Repository kann man auch noch im Nachhinein anlegen – auch in Eclipse mit dessen eigenen SVN-Tools. Man ist bzgl. der Ausgestaltung der SVN-Struktur also sehr flexibel.

Wie kann man also systematisch beim Aufbau eines Repositories vorgehen?

Meine persönliche Vorgehensweise gerade bei großen Projekten mit einigen Teilprojekten ist die, dass ich zunächst ein umfassendes Repository anlege und dann darin über die SVN-Tools von Eclipse meine einzelnen PHP-Teil-Projekte jeweils in einer sog. “Single Project Structure” unterbringe. Sprich: ich lege die Zweige “trunk, branches, tags” unterhalb eines jeden Projektverzeichnisses an und nicht auf der Ebene des gesamten Repositories selbst.

Einer solchen Politik liegt folgender Ansatz zugrunde:

  • Ich lege unterschiedliche SVN Repositories für große, aber relativ unterschiedlich Projekte (z.B. für unterschiedliche Kunden) an.
  • Ich bringe Projekte mit gleicher Grundlage (Klassenbibliotheken) und ähnlicher Struktur soweit möglich in ein und demselben SVN Repository unter,
  • Falls ich mehrere Projekte im gleichen Repository aufnehme, versehe ich diese Projekte jeweils mit eigenen Hauptzweigen “trunk”, “tags”, “branches”.

Warum will man auf einem stand alone Entwicklungssystem ggf. mehrere Projekte in einem Repository unterbringen und diese mit separaten “trunk”- und “tags”-Verzeichnissen versehen ?

Ein einfaches Beispiel für eine solche Situation ist etwa dann gegeben, wenn man ein und dieselben Klassenbibliotheken in verschiedenen Projekten einsetzen will und diese Bibliotheken aber nur einmal – nämlich über ein zentrales Projekt – pflegen will. Sind sowohl das Projekt für die zentralen Bibliotheken als auch die anhängigen unterschiedlichen Projekte in ein und demselben Repository untergebracht, so ist die Kopplung der Projekte untereinander mit den Tools von Eclipse sehr einfach. Wir kommen darauf weiter unten zurück.

Diese Vorgehensweise der Organisation mehrer Projekte im gleichen Repository führt zu der nachfolgend beschriebenen Anbindung von PHP-Projekten an ein SVN-Repository.

Hinweis zur Kopplung verschiedener Repositories:    Wie man bei Bedarf auch verschiedene SVN-Repositories und zugehörige Projekte noch nachträglich miteinander koppelt, erfährt man z.B. hier :

Hinweis zum Begriff der “Repository Location” in Eclipse:

In Eclipse taucht verschiedentlich der Begriff “Repository Location” auf. Gemeint sind damit bezeichnete Verweise auf Repositories oder aber bestimmte Inhalte/Bereiche von Repositories. Es kann also mehrere “Repository Locations” geben, die sich auf ein und dasselbe Repository, aber unterschiedliche Locations innerhalb des Repositories beziehen. Definierte “Repository Locations” werden in Eclipse im View “SVN Repositories” angezeigt
und lassen sich dort einsehen und verwalten.

Schritt 2: Prüfen, dass der passende SVN-Konnektor in Eclipse aktiviert ist

Auf meinem System ist SVN in einer Version 1.6.x installiert. Damit Eclipse damit richtig kommunizieren kann, ist es notwendig, dass der richtige Konnektortyp aktiviert ist. Hierzu gehen wir zu

“Windows” >> “Preferences” >> “Team” >> “SVN” >> Reiter “SVN Connector”

Hier wählen wir SVNKit 1.3.5 rxxx (for SVN 1.6.xx, all platforms) aus. Sonst erhalten wir beim Verbinden zu SVN-Repositories, die nicht kompatibel zu älteren SVN-Versionen angelegt sind, erhebliche Probleme. Siehe auch

http://j-developer.blogspot.com/ 2009/05/ local-svn-repository-with-eclipse.html

Schritt 3: Anlegen eines SVN-Repositories

Damit Eclipse ein PHP-Projekt mit einem SVN-Repository verbinden kann, muss letzteres (also das übergeordnete Container-Verzeichnis mit seinen Datenbank-Elementen) bereits vorhanden sein. Es gibt meines Wissens in Eclipse keine Möglichkeit, ein Repository und eine untergeordnete Projektstruktur sozusagen in einem Arbeitsschritt anlegen und füllen zu lassen.

Für das Anlegen eines neuen SVN-Repositories gibt es auf unserem lokalen Entwicklungssystem unter Opensuse (mit KDE) mehrere Möglichkeiten. Ich beschreibe hier alternativ nur zwei Wege: einen über KDESVN und danach einen alternativen über Eclipse selbst.

Schritt 3.1: Erstellen des SVN-Repository-Verzeichnisses mit KDESVN

Man öffne zunächst KDESVN. Dann klicken wir auf den Menüpunkt:

/MY_PFAD/wsp_ecl/myprojectMenü “Datei” >> “Subversion-Admin” > “Erstelle und öffne ein neues Repository”.

Danach wählt man einen Pfad zum neuen Repository-Directory aus. Im hier behandelten Fall einer lokalen Installation auf einem Laptop wähle ich eine geeignete Partition und dort ein (neues) Subverzeichnis “svn_myphp” unter einem Directory “SVN” aus. Also ggf.:

/MY_PFAD/SVN/svn_myphp

Als Typ des Repositories wähle ich FSFS aus. Zu den möglichen Vorteilen s. etwa:

http://blogs.compactframework.de/ Torsten.Weber/ 2007/12/03/ Subversion+Ndash+ Konvertierung+BDB+Berkeley+ Nach+FSFS.aspx

Die Checkbox “Erstelle Hauptverzeichnisse” wähle ich ab, da ich mich im Moment noch nicht mit Verzweigungen oder Branches” des Repositories, die sich in den üblichen Zweigen “Trunk”, “Tags”, Branches” des SVN-Repositories wiederspiegeln würden, rumschlagen will. Den Aufbau der üblichen Hauptzweige für die einzelnen PHP-Projekte überlasse ich später Eclipse.

KDESVN legt nun das Repository an und öffnet es auch. Da es noch leer ist, wird nichts – in unserem Fall natürlich auch nicht die die Hauptverzeichnisse trunk, etc. – angezeigt. Ein Blick auf das Verzeichnis “/MY_PFAD/SVN/svn_myphp” (z.B. mit Dolphin) zeigt aber, das hier bereits die nötigen Datenbank- und Konfigurationsverzeichnisse angelegt wurden.

Schritt 3.2: Alternativ: Erstellen des SVN-Repositories mit Eclipse

Wir öffnen in Eclipse die PHP-Perspektive mit dem PHP-Explorer links. Dann klicken wir auf den Menüpunkt

“Window” >> “Show View” >> “Other” >> “SVN” >> “SVN Repositories”

Im linken Seitenbereich öffnet sich neben den Reitern “PHP-Explorer”, “Type Hierarchy” ein weiterer Reiter “SVN Repositories” mit einer eigenen Symbolleiste.

SVN-Explorer Icon Leiste

Hier klicken wir nun auf das vorletzte Symbol von rechts

SVN Plus Symbol

Im sich öffnenden Dialog geben wir den Pfad zu dem gewünschten Repository (Containerverzeichnis) an. Im konkret abgebildeten Beispiel ist MY_PFAD jetzt durch “/samba” ersetzt.

New SVN repo

Die FSFS-Variante des Repositories wird über den Radiio-Button “File System” im Auswahlbereich “Repository Type” ausgewählt. Um das Repository auch schon sehen zu können, markieren wir die Checkbox “Create Repository Location”.

Wir klicken abschließend auf den “OK”-Button. Eclipse legt nun ein Verzeichnis “svn_myphp” unter “/MY_PfAD/SVN” mit den notwendigen SVN-Inhalten an. Im View “SVN Repositories” taucht nun rechts eine neue Repository Connection auf.

Wenn wir in Eclipse die Unterstruktur durch Klick auf das Dreieck vor dem Repository-Namen öffnen, sehen wir, dass es im wesentlichen noch leer ist.

New empty SVN repo

Ein

RMT-Klick auf den Repository-Namen >> Location Properties

gibt einige Informationen zum SVN Repository. Hier kann man nachträglich ein Password hinzufügen, dass dann später bei der Arbeit mit dem Repsoitory unter Eclipse abgefragt wird. Unter dem Reiter “Advanced”
finden sich unter “Enable Structure Detection” Einstellungen zu möglichen Verzweigungen. Wir lassen die Checkbox angehakt, weil Eclipse diese Unterstrukturen später für die ins Repository einzubettenden Projekte erkennen soll.

Schritt 4: Einbinden eines Eclipse-PHP-Projekts in das neu angelegte SVN-Repository

Es gilt nun, das eben angelegte Repository initial mit den Daten (Verzeichnissse, Dateien) unseres ersten PHP-Projektes “myproject” zu füllen. Wir wechseln daher wieder zum PHP-Explorer in der Eclipse PHP Perspective und öffnen das Kontextmenü unseres Projektes “myproject” :

RMT auf das Projekt “myproject” >> Team >> Share Project >> SVN im Auswahldialog wählen >> Create a new repository location >> Weiter

Im nächsten Fenster muss man unter dem Reiter “General” die URL zum eben angelegten SVN-Verzeichnis unter “/samba/SVN/svn_myphp” eingeben. Wichtig ist hier der Vorspann – das “Protokoll” – für die Art des Zugriffs ! Bei einem (lokalen) Datei-Zugriff lautet die Angabe in meinem Fall (lokale Installation) lautet die richtige Angabe:

file:///samba/SVN/svn_myphp

wobei /MY_PFAD hier durch “/samba” ersetzt wurde und für den Verzeichnispfad zum SVN-Verzeichnis steht. Wichtig sind die drei (!) Slashes am Anfang! Zwei davon markieren das “Protokoll” von Eclipse zum Austausch mit SVN innerhalb des lokalen Filesystems. Danach beginnt der eigentliche Pfad ab root “/”.

Proejct to SVN 1

Hinweis:   Bei externen SVN-Servern kämen aber auch folgende Protokolle in Frage:

http://, https://, svn://, svn+ssh://.
Weitere Informationen bietet das Eclipse Hilfesystem. Man suche dort nach “subversive supported protocolls” !

Auf unserer Seite zu den Angaben bzgl. des
Repositories geben wir nun bei Bedarf noch

  • die Bezeichnung an, die wir für die Repository Location wünschen (hier “myproject in svn_myphp”),
  • den User und ein Password an. Das Password wird später bei der Arbeit mit Eclipse und SVN abgefragt.

Unter dem Reiter “Advanced” findet man die Informationen zu den drei Hauptverzeichnissen, die Eclipse erkennen soll. Hier lassen wir alles unverändert. Die SSH- und SSL-Optionen in den anderen zwei Reitern kann man bei einem lokalen Verzeichniszugriff ignorieren. Ansonsten sind halt myselfdie für den betreffenden Server richtigen Angaben zu machen.

Mit der LMT auf die Taste “Next” schließen wir den aktuellen Dialog ab. Es öffnet sich ein weiterer Dialog (im konkreten Beispiel ist MY_PFAD wieder durch “samba” ersetzt) .

Project to SVN 2

Wir klicken auf “Next” und im nächsten Bestätigungsdialog auf “Finish”.

Eclipse stellt nun die Zuordnung der Dateien des Projekts zum SVN-Repository her und bereitet die Commit-Vorgänge für das Laden der Dateien in die Datenbank des Repositories vor. Im sich dabei öffnenden Dialog geben wir evtl. Anmerkungen ein und bestätigen den Check-In-Vorgang für die als “new” angezeigten Verzeichnisse und Dateien.

Die Dauer des nachfolgenden Commit-Vorgangs hängt von der Größe und Anzahl der Dateien ab, die eingecheckt werden. Im Php-Explorer erscheinen nach Beendigung der Commits rechts neben den Dateien Nummern. Dies ist jeweils die Revisionsnummern des Repositories, bei der die letzte Änderung der Datei erfolgte.

Schritt 5: Kontrolle und Ansicht des gefüllten Repositories

Natürlich kann man sich nun die SVN-Repository-Inhalte in Eclipse ansehen. Wir wechseln zurück zum View “SVN Repositories”. Dort klicken wir auf die zu unserem Projekt gehörige Repository Location und öffnen der Reihe nach die Struktur. Zur Sicherheit klicken wir vorab im Kontextmenü auf den Punkt “Refresh”.

Zusätzlich öffnen wir die Ansicht “SVN Repository Exploring” über den Menüpunkt

“Window” >> “Open Perspective” >> “Other” >> SVN Repository Exploring

Rechts wird dann ein Fenster angezeigt, in dem man mehr Informationen zu den Inhalten des Repositories bekommt. Man beachte u.a. die Revisionsnummer, die im Moment noch überall gleich ist. Doppelklicks auf die Verzeichnisnamen öffnen im Repository Explorer das jeweilige Verzeichnis.

Project in SVN 1

Die Nummer hinter der den angezeigten Dateien/Verzeichnissen gibt die Revisionsnummer des Repositories an, bei der jeweils die letzte Änderung erfolgte.

SVN-View “Historie” des Repositories

Mit folgendem Kontext-Menü-Punkt zeigt man sich im SVN-View “History” die Revisionsstände auf übersichtliche Weise an.

RMT auf die Repository Location >> Show History”

SVN History

Eine “History” von Revisionen kann man sich nach mehreren Änderungen auch gezielt für eine bestimmte Datei anzeigen lassen. Hierzu hangelt man sich durch die Hirarchie des Views “SVN Repository” bis zur betroffenen Datei vor und benutzt dann den Kontextmenü-Punkt “Show History” .

Schritt 6: Kontrolle der Revisionierung

Um zu testen, dass Änderungen an Dateien nach einem Commit in das Repository tatsächlich zu Revisionsänderungen führen, wechseln wir nun erneut zum PHP-Explorer. Dort wählen wir
eine Datei aus – in meinem Fall eine Datei “druck.css” und öffnen sie im Ediitor durch Doppelklick. Wir ändern dann an der Datei etwas (z.B. einen Kommentar) und speichern die Datei ab.

Im PHP-Explorer erscheint nun vor der Datei eine spitze Klammer “>”. Dies zeigt an, dass die Datei gegenüber dem letzten SVN-Revisionsstand geändert, aber noch nicht ins Repository eingecheckt wurde. Wir erreichen die notwendige Aktualisierung des Repositories über den Commit-Button

SVN Commit

in der SVN Icon Toolbar oder aber durch

RMT auf die Dtei im PHP-Explorer >> Team >> Commit

Im nachfolgenden Dialog bestätigen wir den Commit-Vorgang (und geben ggf. noch einen Kommentar ein).

Rechts aktualisieren wir dann den bereits geöffneten “History” View des Repositories mittels des zugehörigen Refresh Icons.

SVn Rev Changes

Das Kontextmenü für eine Revision gibt einem über den Punkt

RMT auf die Revision im SVN-View “History” >> Show Revision Properties

die Möglichkeit, bestimmte Daten zu einer Revision anzusehen und diese ggf. auch über ein eigenes Kontextmenü zu ändern (“Edit”).

SVN Rev Properties

Hinweis: Änderungen von Revisionsinformation – wie z.B. der Kommentare im Log – setzen Manipulationen des SVN-Adminsitrators am Repository selbst voraus. Siehe z.B.:
http://jacqueschirag.wordpress.com/ 2007/07/22/ changing-revision-property-in-subversion-with-tortoisesvn/

Schritt 7: Vergleich zweier Revisionsstände einer Datei

Im SVN View “History” kann man mit der rechten Maus in der Anzeige für einen bestimmten Revisionsstand auf eine Datei mit RMT klicken und erhält im Kontextmenü die Option “Compare with previous state”. Es öffnet sich dann ein spezielles Editorfenster, in dem die Unterschiede der Dateien markiert sind.

SVN Rev Changes Compare

Natürlich kann man auch andere Revisions-Stände als zwei aufeinanderfolgende Stände einer Datei miteinander vergleichen. Hierzu öffnet man mit

RMT auf eine Datei im View “SVN Repositories” >> Show History

rechts die History der zu untersuchenden Datei. Danach markiert man zwei Versionsstände und wählt dei Vergleichsoption im Kontextmenü

RMT auf eine der markierten Revisionen >> Compare with Each Other

SVN Compare Revisions

Schritt 8: Lösen der Verbindung eines Projekts zu einem Repository

Es kann passieren, dass man ein Prokjekt von seinem Repsitory lösen will oder muss. Dies geht über den PHP Explorer. Man öffnet dort das Kontextmenü des Projektes

RMT auf das Projekt >> Team >> Disconnect

und folgt den Dialogfenstern.

Schritt 9: Vorsicht beim Löschen eines Repositories

Wenn man ein Repository oder eine Repository Location im View “SVN Repositories” per Kontextmenü löscht, ist Vorsicht angebracht.

RMT auf die Repository Location >> Discard Location

Der nachfolgende Dialog

SVN Remove Repo

bietet neben der Option “Disconnect” auch die Option “Delete”. Hier sollte man immer “Disconnect” wählen. Ein Klick auf Delete führt zur Löschung des Projektes im PHP-Explorer und der entsprechenden Verzeichnisse auf der Festplatte !

Viel Spass nun mit SVN unter Eclipse ! Im nächsten Teil werden wir ein PHP-Projekt aus einem vorhandenen Repository erzeugen und zeigen, wie man zwei Projekte aus dem gleichen Repository miteinander verkoppelt.