Category Archives: SVN

Tips regarding SVN

Eclipse / Subversion auf 2 Linux-Systemen – UID, GID für die svn-Systemaccounts beachten

Posted on by

Bei meinen aktuellen Systemumzügen auf Opensuse 13.2 bekam ich erneut ein Problemchen mit SVN. Diesmal von Eclipse aus. Aber die Schuld für das Problem kann ich keineswegs SuSE anlasten, sondern nur Konsequenzen aus meinem eigenen Tun. Die Ursache meiner Schwierigkeiten war zwar eine triviale – aber vielleicht lernt ja auch der eine oder andere Leser was von meinem Fehler.

Voraussetzungen

Voraussetzung 1 – lokale Repositories, Zugriff über einen lokalen SVN-Server
Auf einem Entwicklungssystem unter OS 13.1 hatte ich aus Performancegründen irgendwann mal den Zugriff auf neu angelegte lokale SVN-Repositories von einfachem File-Zugriff (file://) auf Zugriff über das native SVN-Protokoll (svn:// bzw. svn+ssh://) umgestellt. Zu den verschiedenen Zugriffsverfahren (unter Eclipse) siehe:
https://eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/protocols.php
Ermöglicht wurde die Umstellung durch Einrichtung eines lokalen SVN-Servers mit entsprechender Konfiguration der Zugriffsrechte im “conf”-Unterverzeichnis des neuen Repository-Verzeichnisses.

Nun wird natürlich die Frage kommen: Warum arbeitet der Typ in seinem Netzwerk mit einem lokalen Repository? Noch dazu mit einem lokalen Server?
Antwort 1: Ich arbeite nur partiell mit einem lokalen Repository. Es gibt Release-Branches, deren Dateien auf ein weiteres Projekt verlinkt sind. Der SVN-External Mechanismus sorgt dann dafür, dass mit Hilfe des anderen Projektes Submits in ein zentrales Repository (im eigenen Netzwerk oder auf Servern im Internet) vorgenommen werden können. So kann ich in Kooperation mit meinem lokalen Repository meine eigenen Entwicklungsschritte in schnellen Zyklen vorantreiben. Das Mergen in ein Release-Repository erfolgt dann nach Absprache über den (verlinken) Branch und das zweite Projekt. Das geht immer dann besonders gut und einfach, wenn die Zuständigkeiten für bestimmte Codebereiche und auch Klassen klar getrennt sind. Ein solches Branching ist für sich schon interessant; dieser Artikel fokussiert aber auf ein bestimmtes Probleme des Zugriffs auf lokale Repositories der Entwicklungsmaschine und eben nicht auf zentral verwaltete Repositories.
Antwort 2: Geschwindigkeit und Flexibilität. Der Zugriff über einen lokalen Server ist unter Eclipse bei umfassenden CheckIns z.T. deutlich schneller als der File-basierte Zugriff (zumindest auf hinreichend leistungsstarken Multiprozessor-Maschinen). Flexibilität: Ist ein SVN-Server erstmal vorhanden, kann er bei Bedarf auch anderen Usern im Netz (oder auf virtuellen Maschinen derselben Workstation) zur Verfügung gestellt werden.

Voraussetzung 2:
Meine gesamten Entwicklungsdateien, SVN-Repositories, Domainverzeichnisse für lokale Webserver liegen auf meinen Entwicklungssystemen auf speziellen, von den Betriebssystem-Partitionen unabhängigen Partitionen – sie seien nachfolgend “Entwicklungspartitionen” genant. Dies gibt mir bei Bedarf die Möglichkeit, von verschiedenen Systeminstallationen aus (z.B. Debian, OS 13.1 oder eben einem mal testweise installierten OS 13.2), die auf anderen Partitionen der Workstation liegen, in ähnlicher auf diese Entwicklungsdateien zuzugreifen. Dazu werden die Entwicklungspartitionen auf Standardverzeichnis-Pfade im jeweils gestarteten Betriebssystem gemountet. Das ganze erleichtert z.B. Test der Tauglichkeit neuer Distributions-Versionen oder einen systematischen stufenweisen Umzug zu einer neu installierten Distribution.

Man beachte, dass diese Möglichkeit zum wechselseitigen Arbeiten am gleichen Eclipse-Projekt von verschiedenen Systemen aus sehr ähnlich ist zum wechselseitigen Arbeiten am gleichen
Projekt auf 2 getrennten Computern, deren Entwicklungsinhalte z.B. über “unison/rsync” systematisch synchronisiert werden. Ich selbst synchronisiere meine sämtlichen projektbezogenen Entwicklungsverzeichnisse, SVN-Verzeichnisse, zugehörige Domaindateien eines lokalen Apache-Testservers (und auch Eclipse selbst) oft zwischen meiner Workstation und einem Laptop, wenn ich mich auf eine längere Reise begeben muss.

Die nachfolgend dargestellte Problematik lässt sich also auf das wechselseitige Fortführen der Eclipse-Entwicklungsarbeit an zwei laufend synchronisierten Systemen direkt übertragen. Wir erfassen somit über das nachfolgend geschilderte Problem zwei unterschiedliche Zugriffssituationen:

  • Den (sequentiellen) wechselnden Zugriff von 2 Betriebssysteminstallationen auf ein und derselben Workstation aus auf ein und dasselbe Repository auf einer separaten Partition. Das geht im Normalfall natürlich nur über Reboots; zu einer Zeit ist genau ein Betriebssystem aktiv, unter dem dann die Partition mit den Repositories gemountet wird. [Ich habe in der täglichen Praxis aber natürlich durchaus auch Situationen mit parallel gestarteten virtuellen Maschinen auf ein und derselben Workstation. Das entspricht dann aber eher der künstlich geschaffenen Situation des parallelen Arbeitens zweier Entwickler auf dem gleichen Repository; diese Situation erfordert aber eigentlich fast zwingend die Einrichtung eines zentralen SVN-Servers auf irgendeiner der gestarteten Maschinen-Instanzen. Ich betrachte den Sonderfall mehrerer gestarteter virtueller Maschinen (auf einer Workstation), die ggf. und idiotischerweise dieselbe Partition mit SVN-Repository mounten, nicht weiter.]
  • von je einem Betriebssystem auf 2 unterschiedlichen Computern aus auf jeweils lokale Repositories, die aber systematisch und regelmäßig zwischen den Maschinen synchronisiert werden.

Das aufgetretene Problem

Auf der erwähnten Entwicklungs-Workstation habe ich Opensuse 13.2 (in einer separaten Partition) neu neben einem laufenden und benutzten Opensuse 13.1 installiert. Ich habe unter Opensuse 13.2 natürlich die gleichen Entwickler-User eingerichtet (identische UID, GID) wie unter OS 13.1.

Nun wollte ich bestimmte Verzeichnisse, die SVN-Repositories enthalten, eben von einer dritten (“Entwicklungs-“) Partition mounten und dann von einem bereits umgezogenen Eclipse über dessen SVN-Connectoren in gewohnter Weise auf die Repositories zugreifen.

Da ich die aktuellen Eclipse-Einstellungen unter OS 13.1 nach OS13.2 übernommen hatte, musste dafür auf dem OS13.2-System auch ein lokaler SVN-Server laufen. (Zumindest für die Repositories, auf die der Zugriff über den SVN-Server eingestellt war). Die nachfolgende Skizze verdeutlicht die Situation:

snv-Zugriff_600

Nachdem ich den SVN-Server-Prozess (svnserve) endlich mit Hilfe einer selbst erzeugten sysconfig-Datei für “svnserve” [s. https://linux-blog.anracom.com/2015/01/16/opensuse-13-2-subversion-sysconfig-file-svnserve-fehlt/ unter OS 13.2 zum Laufen gebracht hatte, schlug allerdings der Zugriff von Eclipse aus (unter OS 13.2) fehl :

svn: E204900: Can’t open file …… txn-current-lock’: Permission denied

Zunächst dachte ich aufgrund einer oberflächlichen Interpretation der Fehlermeldung, dass der unter Eclipse angegebene User (unter OS13.2) nicht zu den Einstellungen im “conf”-Unterverzeichnis des von mir angesprochenen Repository-
Verzeichnisses passen würde. Oder das Password sei falsch, oder … Also stellte ich die Zugriffserlaubnis in der “authz”-Datei des Repositories mal testweise so um, dass jedermann “rw”-Zugriff auf das Repository haben konnte. Das änderte an der obigen Fehlermeldung des Eclipse-Connectors jedoch gar nichts.

Ein ganz analoges Problem kann sich

  • nach einem rsync-Abgleich der Repository-Verzeichnisse mit einem anderen Computersystem
  • und dem anschließenden Versuch, auf dem 2-ten System auf das Repository, zuzugreifen,

ergeben. Siehe die nachfolgende Skizze.

snv-synchro_600

Problem-Ursache

Kein Problem bei SVN-Filezugriff
Solange man unter Eclipse lokal auf einem Entwicklungssystem z.B. über das Subversion-Plugin lediglich einen File-Zugriff auf die angelegten lokalen SVN-Repositories festgelegt hat, bereiten Systemumzüge oder auch maschinenübergreifende Synchronisierungsverfahren z.B. mit “unison/rsync” selten Probleme – es genügt dann, die User Accounts der Entwickler mit identischen UIDs, GIDs im neu installierten oder dem zu synchronisierenden System anzulegen. Haben die betroffenen User auf beiden Systemen hinreichende Zugriffsrechte auf die Repository-Verzeichnisse und -Files, so funktioniert nach einem Umzug bzw. nach einer Synchronisation beim Zugriff auf das alte bzw. das synchronisierte Repository alles wie gewohnt. Legt man die Repositories über Eclipse selbst an, so sorgt das SVN-Plugin (bei file-Zugriff) bereits für die korrekte Rechtevergabe. (Bei Synchronisationsverfahren müssen lediglcih die Zugriffsberechtigungen lediglich 1:1 übertragen werden und dieselben Entwickler-UIDs auf beiden Systemen vorhanden sein).

Zugriff und Zugriffserfordernisse über lokalen SVN-Server und das svn-Protokoll
Läuft jedoch lokal (oder auf einem Synchronisationssystem) ein SVN-Server und soll Eclipse über ihn auf (einigen) Repositories operieren, so muss natürlich der lokale SVN-Server-Prozess selbst lesend und/oder schreibend auf die Repository-Verzeichnisse, deren Konfigurationsdateien sowie die Datenbankfiles des Repositories zugreifen können. (Bei einem reinen File-Zugriff genügen dagegen – wie gesagt – die Rechte des Users). Auf einem Server sind daher alle Repository-Verzeichnisse normalerweise dem svn-Systemuser und seiner Gruppe zugeordnet (und natürlich nicht irgendwelchen Entwicklern – der Entwicklerzugriff wird vielmehr nicht auf Filesystem-Ebene sondern über Rechtesetzungen in den “conf”-Dateien der Repositories geregelt).

Leider hatte ich bei der Installation des OS 13.2-Systems aber die Vergabe von UIDs und GIDs an System Accounts nicht hinreichend beachtet (oft bleibt SuSE ja bei Standard System-Usern – soweit möglich – bei den gleichen UIDs). Meine Nachlässigkeit rächte sich. Was war geschehen?

Auf der ursprünglich unter OS 13.1 genutzten Partition waren natürlich die Verzeichnisse und Dateien des SVN-Repositories unter dem dortigen SVN-Server mit Zugriffsrechten für den dortigen User “svn” und die dortige Gruppe “svn” angelegt worden. Aber wer sagt denn, dass in einem separat und neu installierten OS13.2-System der “svn”-Account bzw. die svn-Gruppe die gleich UID bzw. GID wie auf meinem alten OS13.1-System erhält? Niemand ! Ein kurzer Check zeigte:

Die zu dem svn-User bzw. der svn-Gruppe gehörigen UID.GID waren auf meiner 13.1-Installation (die eine längere Upgrade-Geschichte hinter sich hat) “482.480” – unter der frischen OS13.2-Installation jedoch “483.482”.

Das letztendliche Zugriffsrecht des “svnserve”-Prozesses richtet sich jedoch nicht nach dem svn-User/Gruppen-Namen sondern natürlich nach dessen UID/GID. Auf der gemeinsam zu nutzenden Partition war der Rechtekamm zur Erzeugungszeit der Repositories selbtsverständlich auf die alte UID/GID-Kombination des svn-Users bzw. der svn-Gruppe ausgelegt worden. Mounted man die Partition dann unter OS 13.2 ist der Zugriff des dortigen svnserve-Prozesses nicht möglich.

Lösungsansätze

Aus dieser Analyse ergaben sich mehrere Lösungsansätze, unter denen man ein wechselseitiges Arbeiten auf dem Entwicklungssystem mal unter OS13.1, mal unter OS13.2 auf demselben Repository einer unabhängigen, jeweils gemounteten Partition erreichen konnte :

  • Methode 1: Man geht auf beiden Systemen unter Eclipse/Subversive zurück zum reinen File-Zugriffsverfahren mit anschließender Anpassung der User-Rechte an den Repository-Verzeichnissen/-Dateien. Hierbei kommt dann lediglich die (hoffentlich übereinstimmende) UID/GID des Entwicklers bzw. der Entwicklergruppe zum Tragen.
  • Methode 2: Abgleich der UID/GIDs für die “svn”-Accounts auf beiden Systemen – so dass man danach von beiden Systemen aus auch arbeiten kann. Das ist allerdings leichter gesagt als getan: So kann die im alten System benutze UID/GID auf dem neuen System bereits belegt sein. Geht man hingegen in beiden Systemen auf eine neutrale, unbelegte UID/GID, so muss man auf beiden Systemen für die jeweils vorhandenen UID/GIDs alle Dateien suchen lassen, bei denen diese UID/GIDs im Rechtekamm auftauchen und die Rechtekämme danach entsprechend abändern. Das ist zwar befehlstechnisch einfach zu realiseren, kann jedoch aufgrund der Menge der betroffenen Dateien zu einem Problem werden. Hierfür schreibt man sich deshalb am besten ein kleines Script.
  • Methode 3: Anlage einer neuen, neutralen Gruppe mit identischer GID auf beiden Systemen, der sowohl der System-User “svn” als auch die Entwickler-Accounts zugeordnet werden. Abänderung der Rechtekämme für alle Repositories auf beiden Systemen so, dass ihnen neue Gruppe zugeordnet wird UND dass diese Gruppe auch Schreibrechte erhält. Das impliziert dann ggf. ein Sicherheitsproblem, wenn man die “conf”-Dateien nicht explizit ausschließt. Zudem muss man das SGID-Bit auf den Repository-Verzeichnissen setzen. Auf privaten Systemen mag das alles noch gehen; nicht aber auf Systemen, die tatsächlich von mehreren Usern benutzt werden.

Methode 3 hat gegenüber einer alleinigen Anwendung der Methode 2 den Vorteil, dass man danach beliebig zwischen den Zugriffsvarianten “file” und “svn” unter Eclipse auf den betroffenen Systemen wechseln kann. Ich selbst bevorzuge aber Methode 2 und werde den erforderlichen frühzeitigen Abgleich der UID/GIDs für die svn-Systemaccounts in Zukunft beherzigen.

Fazit

Beim wechselseitigen Arbeiten von verschiedenen Betriebsystem-Instanzen ein und desselben Computers aus mit lokalen SVN-Repositories einer vom jeweils gebooteten System gemounteten separaten Partition muss man unbedingt auf einen Abgleich der UID/GID des svn-Systemusers bzw. der svn-Systemgruppe unter den jeweiligen Betriebssystemen achten. Zumindest, wenn man jeweils einen lokalen SVN-Server für den Zugriff einsetzt. Diese Regel ist u.a. auch bei der testweisen Installation einer neuen Distributionsversion auf einer eigenen Partition zu berücksichtigen.

Das Gleiche gilt in analoger Weise aber auch für das wechselseitige Arbeiten am gleichen Projekt auf unterschiedlichen Computern, deren SVN-Repositories auf der Dateiebene bei Bedarf synchronisiert werden. Erfolgt auf jedem System der Zugriff auf die
lokalen Repositories über einen (jeweils) lokalen SVN-Server, so ist auf gleiche UIDs/GIDs der svn-System-Accounts zu achten.

Opensuse 13.2, Subversion – sysconfig File "svnserve" fehlt

Posted on by

Opensuse 13.2 bietet einige Überaschungen und nicht immer positive. So wollte ich kürzlich auf einem neu installierten OS 13.2 einen einfachen Subversion-Server einrichten. Hierzu installierte ich mir die erforderlichen Pakete.

Natürlich unterliegt auch das Programm “svnserve” inzwischen der Kontrolle von systemd. Ein Startup-Skript unter “/etc/init.d” sollte also überflüssig sein und findet sich unter Opensuse 13.2 (im Gegensatz zu OS 13.1) auch nicht mehr.

Leider führte ein versuchsweises Absetzen des Kommandos

systemctl start svnserve.service”<&/p>
zu einem Fehler:

mytux:~ # systemctl start svnserve.service   
Job for svnserve.service failed. See "systemctl status svnserve.service" and "journalctl -xn" for details.
mytux:~ # systemctl status svnserve.service 
svnserve.service - Subversion protocol daemon
   Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled)
   Active: failed (Result: resources) since Fri 2015-01-16 11:58:37 CET; 21s ago
  Process: 14949 ExecStart=/usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid $SVNSERVE_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 14950 (code=killed, signal=TERM)

Jan 16 11:54:03 rux svnserve[14949]: DIGEST-MD5 common mech free
Jan 16 11:58:42 rux systemd[1]: svnserve.service failed to run 'start' task: No such file or directory
Jan 16 11:58:42 rux systemd[1]: Failed to start Subversion protocol daemon.
mytux:~ #

Fragt sich, was das fehlende File ist. Dazu muss man in der schönen Welt von “systemd” etwas in der Tiefe graben. Die Antwort findet sich im Verzeichnis “/etc/systemd/system/multi-user.target.wants/”. Dort gibt es einen Link “svnserve.service”, der auf die Datei
“/usr/lib/systemd/system/svnserve.service” verweist. Inhalt: 

[Unit]
Description=Subversion protocol daemon
After=syslog.target network.target

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/svnserve
User=svn
Group=svn
PIDFile=/var/run/svnserve/svnserve.pid
ExecStart=/usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid $SVNSERVE_OPTIONS

[Install]
WantedBy=multi-user.target

Aha! Es stellt sich also die Frage, ob es das EnvironmentFile, das ich von früheren Opensuse-Versionen sehr gut kenne, im “/etc/sysconfig”-Bereich überhaupt noch findet? Antwort: Leider nein!

Da stimmt also womöglich was nicht mit dem Subversion-Paket. Ein Deinstallieren und Neuinstallieren half aber leider nichts. Eine anschließende Suche im gesamten Filesystem zeigte, das eine geeignete Konfigurationsdatei auch sonst nirgends zu finden war/ist.

Was also tun? Ich habe mir dann einfach ein entsprechendes sysconfig-File “svnserve” aus einer früheren Opensuse 13.1-Installation in das Verzeichnis “/etc/sysconfig” kopiert. In der nicht ganz unberechtigten Annahme, dass das File hoffentlich auch für systemd auswertbar sein würde, wenn es in der systemd-Konfiguration dort als “EnvironmentFile” erwartet wird. Inhalt: 

## Path:	/etc/sysconfig/svnserve
## Description:	Basic configuration for svnserve
## Type:	string
## Default	"-d -R -r /srv/svn/repos"
#
# Default options for the svnserve process.
# The -R option enforces read-only access, i.e. write operations to the
# repository (such as commits) will not be allowed.
# Authentication should be configured before allowing write access.
# See http://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth
#
SVNSERVE_OPTIONS="-d -r /projekte/SVNserv"

## Type:	string
## Default	"svn"
#
# svnserve should 
run as unprivileged user.
# If you want to expose the repository via both svnserve and mod_dav_svn
# (Apache httpd) in parallel, ensure that the apache user is part of the
# svn group and the setgid flag is set on the repositories
# usermod -A svn wwwrun
# chmod -R g+s /srv/svn/repos
# See http://svnbook.red-bean.com/en/1.8/svn.serverconfig.multimethod.html
#
SVNSERVE_USERID="svn"

## Type:	string
## Default	"svn"
#
# svnserve should run as unprivileged user.
# If you want to expose the repository via both svnserve and mod_dav_svn
# (Apache httpd) in parallel, ensure that the apache user is part of the
# svn group and the setgid flag is set on the repositories
# usermod -A svn wwwrun
# chmod -R g+s /srv/svn/repos
# See http://svnbook.red-bean.com/en/1.8/svn.serverconfig.multimethod.html
#
SVNSERVE_GROUPID="svn"

Die Directory-Angabe am Ende der Variablen SVNSERVE_OPTIONS bezieht sich auf das Haupt-Repository, das ich auf besagtem System unter “/projekte” angelegt hatte. Diese Angabe muss man natürlich an eigene Verhältnisse anpassen. [Standard wäre unter Opensuse ein Repository namens “svn” im Verzeichnis “/srv/svn/”.]

Und siehe da:

mytux:~ # systemctl status svnserve.service 
svnserve.service - Subversion protocol daemon
   Loaded: loaded (/usr/lib/systemd/system/svnserve.service; enabled)
   Active: active (running) since Fri 2015-01-16 12:00:12 CET; 1h 18min ago
  Process: 15198 ExecStart=/usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid $SVNSERVE_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 15199 (svnserve)
   CGroup: /system.slice/svnserve.service
           └─15199 /usr/bin/svnserve --daemon --pid-file=/var/run/svnserve/svnserve.pid -d -r /projekte/SVNserv

Jan 16 12:00:12 rux svnserve[15198]: DIGEST-MD5 common mech free

Hier erkennt man auch, dass systemd beim Start von “svnserve” den Inhalt der Variable SVNSERVE_OPTIONS aus dem EnvironmentFile zieht.

Ich hoffe, das hilft dem einen oder anderen OS 13.2-Umsteiger/Einsteiger weiter.

Eclipse Luna, SVN – problem with older Subversion 1.6 repositories !

Posted on by

In Eclipse I have to handle a variety of PHP projects (with additional natures) which are interconnected in different ways. E.g. my present project may for convenience have links to folders of another project in another Eclipse workspace. Such links exist in my case for example to files containing very basic classes of some of my own frameworks. In some projects I combine the present project work with upgrading the basic framework classes in parallel to a new level of capabilities. In such a situation I want to directly change the basic classes for all other projects that use them and test compatibility aspects.

The version control of almost all interconnected projects is done by Eclipse Subversive plug-ins from Polarion. The link situation on the folder/file side of my projects leads to so called external SVN relations on the SVN side of my interconnected projects. These relations are generated automatically by the Subversive plug-ins for Eclipse.

In some cases I may even have different SVN locations – some local, some on a dedicated SVN servers in the local network or on the Internet. Unfortunately, not all of my SVN repositories are of the same Subversion version – which was no problem as long as different connectors were available in Eclipse and the repositories were generated to be backward compatible. Some of my SVN repositories are relatively old ones – i.e. of SVN version 1.6. Mostly associated with framework classes I continuously have worked on for years.

From KDE’s SVN client “kdesvn” I am very familiar with the problem that e.g. a client for a Subversion version 1.8 is not able to deal with SVN repositories that were generated with an older version of Subversion (e.g. Subversion version 1.6). An error message including as “… working copy is too old …. “ is a typical indication of this situation. In this case it does not help that you may have set up the repository with backward compatibility (e.g. to SVN version below 1.6). You have to update your repository by using the command

svnadmin upgrade

inside the base directory of the repository. Which may be delicate – if you did not set up any backward compatibility your Eclipse plug-in may no longer be able to handle the repository.

So, before updating SVN in your Linux OS and upgrading your SVN repositories you should always check carefully, whether the Subversive SVN plug-ins in Eclipse will be able to handle the repository afterwards. Actually, already this type of problem indicates that a strategy to maintain SVN repository versions consistently should be followed. However, I am a bit lazy. And as long everything worked smoothly I had no reason to upgrade my SVN repositories to one and the same Subversion version.

Some days ago – due to some irritating errors of syntax highlighting in the Kepler JSDT module – I installed Eclipse LUNA (i.e. version 4.4.2.) instead of KEPLER. The JSDT highlighting error went away. However, I ran into deep trouble with the subversion plug-ins.

Actually, my Eclipse upgrade lead to a complete mess because of my laziness in the past to keep the different Subversion versions of SVN repositories on the same level. The following discussion may help others to recover from such a situation and reconsider a strategy to keep the Subversion versions of one’s SVN repositories consistently aligned.

Eclipse Subversive plug-ins for LUNA provide SVN Connector Kits for Subversion versions 1.7 and 1.8, only

Recently, I had started with a new PHP project in Eclipse KEPLER depending on a set of classes of one of my frameworks. So, I thought this project would be a good choice to get some experience with Luna. Without much thinking I had installed several Eclipse plugins I typically use into LUNA as PDT, WST, Mylyn, JSDT
Jquery , etc. and of course Subversion and Polarion Subversive SVN Connector Kits. So, I felt well prepared to open the my Kepler workspace with Luna.

The first thing you may stumble across when using Luna first time is that you should make a copy of your original PHP projects in the Kepler workspace directory. Luna will upgrade your Kepler project in a way that is not backward compatible to older Eclipse versions. Ok, that done, I wanted to share my upgraded project by using a SVN repository. I chose an existing local SVN location – based on the “file” sub protocol of SVN. Then I started to check in the directories and files of my project. The check in process seemed to work well in the beginning. But then I was bombarded with error messages. Besides other things the messages told me that subversion stumbled across an “unsupported working copy”.

Ok, I checked the installed connector versions of the SVN Polarion plug-ins and did additional research on the Internet – the connectors were for Subversion version 1.7 and 1.8, only! Others are not available for Luna! As I did not remember exactly the version of my local repository (probably 1.6) I disconnected the PHP project from SVN with allowing to delete all SVN information from disk.

Making a new repository for your present project may not help

Next thought: Well, lets make a new SVN repository then – of SVN version 1.8. I combined this step with setting up a local lightweight SVN server – because somebody had told me that the performance of the core SVN protocol would be much better than the “file” protocol. After the intermezzo of the server setup I manually created a new SVN database on my local SVN server (i.e. my workstation). As Subversion on the Linux workstation is of version 1.8 -I had no doubts that LUNA now should be able to work together with this SVN database. From Eclipse I shared my previously disconnected project by using the new SVN location with the generic “svn//” protocol. And started to check in again. Which started well and then ran into errors again … 🙁

To analyze what happened I set up a fresh independent project and filled it with some directories and files and tested SVN transactions with my version 1.8 SV repository. That worked perfectly! So, something obviously was wrong with my other more complicated project. A closer analysis showed what the reader may already have guessed:

The errors occurred during the check in process when directories were reached that were linked to my basic long term projects with their old repositories. Which on the SVN side are located in an “external” repository. So, my conclusion was:

One must first remedy the outdated working copy situation for the basic projects which your present project may depend on by links. Their (external) SVN repositories have to be upgraded first.

In complicated dependency situations you may run into more problems

Although the above conclusion is correct it may not directly lead to success. By walking through my projects and trying to get them working again with SVN under LUNA I stumbled across several situations which stressed my nerves. Among others there are 2 stupid things that may lead you to dead end situations and prevent a recovery from them with the Eclipse subversion tools:

  • After a trial to check in files into (too old) repositories there may be open outgoing SVN transactions left which cannot be resolved due to the impossibility to handle old SVN working copies of connected projects with linked folders. You are forced to completely disconnect your present project from the SVN repository with a deletion of all SVN information from disk (i.e. “.svn” files in the folders and sub folders of your Eclipse project)
  • In complicated link situations you may find the following: There may be a mixture of “.svn” files in a project which describe the diverse repositories of linked folders of other projects on different version levels. I found that with the present plug-ins of LUNA this may lead to unrevoverable SVN situations and even repository corruption.
  • Despite disconnecting projects and allowing for a deletion of SVN information some “.svn” files may remain at unexpected locations. This may depend of what kind of SVN trouble and corruption you had and what you tried to remedy the situation. The remaining “.svn” files may include old SVN version information – leading to trouble again when you try to connect to an SVN repository next time.

Eventually, I gave up and really tried to build my previous Kepler projects from scratch again under Luna. Including the SVN aspects.

Steps to recover and get a working LUNA – SVN implementation again

The following sequence of steps worked in my case:

  • First, make copies of your projects AND the associated SVN repositories. You never know ….
  • Check in all files and directories in all of your projects with the old Eclipse version (in my case Kepler) to get the latest versions into the existing SVN repository.
  • If one of the previous SVN repositories used under Kepler is corrupted (according to SVN messages in Eclipse) – do not use it any longer in the steps below. Build a new repository location instead.
  • Disconnect all existing Kepler projects from SVN via the context menu of the project by using the menu points “Team >> Disconnect” and allow for a deletion of the SVN information from disk.
  • Important point: Remove all remaining “.svn” files inside your Eclipse projects which may have remained there by using the command
    “find . -name “.svn” -exec rm -fR {} \;”
  • Go to the SVN repositories that still worked in Kepler (wherever they may reside) and upgrade by “svnadmin upgrade” consistently to the present SVN version – in my case 1.8.
  • Systematically restore your basic projects – i.e. the ones on which other projects may depend – from scratch by using the upgraded repositories. Or share these projects again with reference to the upgraded repository from which you then update the files to the latest repository version.
  • If one of the last steps is not possible due to repository corruption you build up new projects in Eclipse and fill them with the files from your (Kepler) project backups. Then share them by using a new repository location of your choice. Check that all SVN transactions work as expected for your basic projects.
  • Only then rebuild your more complicated projects depending which depend on your basic projects and share them again with the upgraded SVN repositories or newly generated ones.

And in the future:

Follow a systematic approach to upgrade your SVN repositories consistently to Subversion versions your Eclipse installation AND your other tools of your Linux desktop can handle.

Finally: Have fun with Eclipse LUNA and PHP or JS/Ajax projects. It feels great so far ….