# zugriff auf die freigabe mit dem svn-repo scheitert unter eclipse / linux



## ruutaiokwu (7. Nov 2012)

hallo zusammen,

habe gerade mein gesamtes svn von wuala (speicheranbieter) zu meinem nas zuhause migriert. auf dem nas läuft ein linux mit samba-server. (das "normale" halt...")

unter windows kann ich problemlos ein laufwerk x: mappen und anschliessend in eclipse mit dem tigris svn-plugin (v.1.6) auf das repository, welches sich dort befindet, zugreifen. lesen sowie schreiben klappt problemlos...


unter linux siehe es leider anders aus. als erstes hat das tigris svn (zuerst mit v.1.8 getestet) die meldung ausgegeben dass irgendeine "native library" fehle; das problem habe ich aber gelöst, in dem ich bei den settings auf "pure java" umgestellt habe.

projekt aus dem repo auschecken ging problemlos. nach einer sourcecode-änderung konnte ich aber nicht mehr commiten...

bei v.1.8 kam ein dialog wo man username und passwort eingeben muss. oberhalb dieser 2 felder ist noch ein feld welches soviel ich weiss mit "repository" gekennzeichnet war. allerdings konnte man den wert dort drin (glaube eine 16-stellige id?) nicht editieren.

bei v.1.6 kam das gleiche, jedoch ohne passwort-feld.



es scheint ein berechtigungsproblem zu sein, weiss aber nicht weiter... unter dem linux-system habe ich ein verz. /mount/external1 angelegt, welches ich über die konsole (root) gemountet habe. (zum entsprechenden unc-pfad)

auf dem nas gibt es für diese freigabe nur einen user, der lesen UND schreiben darf.


die meldung war etwas mit *"Cannot write to: " .....xyz..... "No pemission"*


wenn ich aber im linux-fileexplorer (nicht per root) auf das gemountete verzeichnis geht, kann ich löschen und ändern. (und somit logischerweise auch schreiben!)


könnte mir jemand evtl. einen tipp geben?

danke.


----------



## ruutaiokwu (8. Nov 2012)

wüsste niemand was?


----------



## Akeshihiro (9. Nov 2012)

Ich habe die Situation nicht nachgestellt, daher kann ich da jetzt nichts zu sagen. Aber ich empfehle dir das lieber von einem filebasierten Ansatz auf einen serverbasierten umzustellen. Ist auch nicht so kompliziert, wie man vielleicht denkt. Es gibt da das SVN-Tool svnserve, das kann SVN-Repositories entsprechend bereitstellen, vielleicht mal googlen. Die Zugriffskontrolle oder generell alles wird dann über die Konfiguration im entsprechenden Repository konfiguriert. Das ist wesentlich leichter und stabiler als die Freigabe über ein Filesystem. Zudem kann dann das Repository nicht beschädigt werden.

Außerdem wird vom Einsatz von Repositories auf dem Filesystem abgeraten. Du kannst sie zwar für Testzwecke nutzen, wenn du nur was ausprobieren möchtest, aber spätestens beim Sharen hörts dann auf, weil dann niemand mehr gewährleisten kann, dass die Zugriffe sauber sind. Daher für sowas entweder einen Server einrichten oder zumindest mit svnserve die Repositories bereitstellen (reicht auch vollkommen).


----------



## maki (9. Nov 2012)

Kann Akeshihiro nur zustimmen, würde den Apache HTTPD als Frontend empfehlen.


----------



## ruutaiokwu (9. Nov 2012)

will keinen server (normaler towser halt) 24/7 laufen lassen, auch einen virtuellen server in einem rechenzentrum über vpn anzusprechen wäre mit zu teuer & zum kompliziert...

auf dem file-basierten repo habe ich gar keine verschiedenen user eingerichtet (also auf svn-ebene...)

es sollten schlicht alle user (theoretisch) darauf zugreifen können, welche ebenfalls zugriff (per os definiert) auf das verzeichnis, z.b.

a.) unter windows X:\svn\repo (gemapptes netzlaufwerk)

oder b.) unter linux /mount/svn/repo (gemountetes netzlauftwerk)

haben.



werde mal schauen ob ich auf meinem nas (apache sollte wohl schon installiert sein -> web-user-interface) das apache-svn-plugin installieren kann. (halt per root/ssh-zugriff, hoffe dass ich dabei nichts schrotte auf meinen nas, na ja, mal schauen...)

oder den apache mit svn-plugin auf meinem laptop, dann das httpdocs-verzeichnis auf dem nas mit raid1 spiegeln... irgendwie auch suboptimal...


----------



## Akeshihiro (9. Nov 2012)

Es ist egal, ob du nur einen physikalischen Benutzer dafür hast oder mehrere, es geht um den Zugriff darauf. Wenn mehrere Anwendungen gleichzeitig drauf zugreifen, selbst wenn es immer der selbe Benutzer ist, dann hast du dennoch unterschiedliche Zugriffe und auf einem Filesystem werden die Anwendungen sicherlicht nicht checken, ob da schon jemand anderes zu Gange ist und zack ist das Repo im Eimer. Aber abgesehen davon bietest du auf diese Weise (der Benutzer muss ja dann Filesystem-Schreibrechte haben) die Möglichkeit, dass das Repo physikalisch zerstört werden kann (wie auch immer, ist eigentlich auch egal). Um das zu vermeiden, sollte man einfach einen Server das regeln lassen, der kann das dann ordentlich koordinieren.

Mit Server war auch nicht gemeint, dass du nen Serverschrank irgendwo hast oder dir einen Root mietest. Auf dem Rechner, auf dem du im Moment das Repository freigegeben hast, konfigurierst du einfach den Benutzer in der Repo-Config, startest "svnserve" mit entsprechenden Parametern und fertig. Wenn du auf eine Dateifreigabe zugreifen willst, musst der Rechner ja auch laufen. Daran ändert sich also nix, lediglich die Art, wie du auf das Repository zugreifst. Und du vermeidest so die potenziellen Gefahren und Probleme, die durch das Filesystem auftreten können (z. B. die Situation, die du jetzt hast).


----------



## kama (9. Nov 2012)

Hallo,

Der Zugriff via File-Protokoll entspricht einem Zugriff über svn/http/https etc. Somit sind auch parallele Zugriffe auf ein Subversion Repository möglich mit dem file:/// Protokoll und führt vor allem nicht zur Zerstörung des Repositories!
(Version Control with Subversion).

Hier wird lediglich verwechselt, dass die Ablage eine Repositories auf einem Netzlaufwerkes eine Möglichkeit für einen Zugriff von mehreren unterschiedlichen Rechnern bietet was schlicht Falsch ist! In diesem Falle geht das 100%ig schief, da Netzwerk Laufwerke bestimmte Locking Operationen nicht bieten, die aber zum Betrieb eines Subversion Repositories benötigt werden. Daraus resultiert ein kaputtes SVN-Repo.  Auch substituierte Laufwerke unter Windows haben das gleiche Problem.

So lange ich auf einem Lokalen Rechner bin, kann ich mithilfe des File Protokolls (file:///...) auf eine Repository zugreifen und das auch parallel.... (SVN-Clients).

Weiterhin ist es möglich auf ein SVN Repository, dass bspw. per http zu erreichen,  auch per file-Protokoll zuzugreifen (eben nur vom Rechner auf dem das Repository selbst liegt.). Der Vorteil liegt einfach in der Zugriffsgeschwindigkeit und dem nicht vorhandensein eine Authentifizierung (Hier schränken lediglich die Rechte auf Dateien bzw. Ordnern den Zugriff ein). Das wird oft dazu verwendet Scripte die das Branchen/Mergen erledigen zu erstellen.

In der Konsequenz bedeutet das, dass ein Repository per http/https Zugänglich gemacht werden kann als auch per svn+ssh bzw. svn und auf der entsprechenden Machine auch noch per file:/// (hier zählen lediglich die User Rechte z.B. Unix).

Wenn also mehrere Benutzer von unterschiedlichen Rechnern Zugreifen wollen ist die Installation von einen Apache Web-Server oder die Nutzung von svnserve eine absolute Notwendigkeit. Wenn man mit Windows arbeitet gibt es die Möglichkeit mithilfe von VisualSVN Server | Subversion Server for Windows einen entsprechenden Server per Knopf-Druck und Clicki-Bunti aufzusetzen und zu administrieren..auf Linux kann man CollabNet Edge nutzen...


Gruß
Karl-Heinz Marbaise


----------



## Akeshihiro (9. Nov 2012)

Danke, dass du das nochmal so ausführlich erklärt hast.

Ich habe schon so eine böse Überraschung gehabt durch eine Dateifreigabe. Wochen lange Arbeit im Eimer gewesen. Daher Repositories über Dateifreigabe = böse, Finger weg!


----------



## ruutaiokwu (11. Nov 2012)

aha, nur netzlaufwerke sind ein problem... samba- und windows-file-server-freigaben sind somit ausgeschlossen.

was ich aber vorher verwendet habe, der speicheranbieter wuala.com, war nie ein problem. auch dort hatte ich ein drive w:, dessen daten irgendwo im internet lagen... damit hatte ich aber nie ein problem, habe damit das svn vom der firma aus wie auch zuhause aus mit 2 rechnern verwendet... na ja, evtl. hat wuala die sache mit dem locking-operationen auch sauber implementiert im ggs. zu anderen sachen...


leider ist mein server ein "network attached store" (ix-200 vom iomega) und kein "richriger" computer. aber wie gesagt läuft dort linux und apache, somit könnte ich dem webserver doch die svn-erweiterung installieren. das wäre doch eine saubere lösung...


----------



## ruutaiokwu (11. Nov 2012)

teste das mal jetzt unter windows mit apache 2.0.64. aber mit dem svnserve-tools ist es mir ehrlich gesagt ein wenig zu einfach. dann lerne ich auch was. leider beinhaltet mein bisheriges svn-tool "sliksvn" keine apache-erweiterungen. (.so-files)

nun habe ich das installiert: Download Subversion for Windows from SourceForge.net

...und unter C:\programme\subversion\bin\ finde ich die notwendigen apache-erweiterungen. so weit so gut...

nun werde ich ein wenig googlen, und schauen wie man die httpd.conf-datei für das svn-plugin konfigurieren muss. später werde ich mich noch um https/ssl kümmern.

besten dank für eure tipps!


----------



## ruutaiokwu (11. Nov 2012)

hat wunderbar geklappt mit dieser anleitung, nur brauche ich apache 2.2 anstelle von 2.0: Subversion for Windows with Apache server HOWTO


----------



## ruutaiokwu (12. Nov 2012)

ein problem habe ich aber noch: damals habe ich das leere svn-repo nicht mit "svnadmin create C:\mysvn" kreiert, sondern nach einer anleitung im netz; ich weiss nur noch, dass ich irgendeinen filesystem-parameter beim svnadmin create-befehl angewandt habe...

und solche repositories gehen jetzt nicht mehr in kombination mit dem apache :-(

wenn ich ein repo einfach "per default" anlege (ohne weitere parameter) dann geht's mit dem apache...


weiss jemand, wie man das filesystem vom einem bestehenden repo konvertieren kann?


----------



## ruutaiokwu (13. Nov 2012)

noch eine frage: kann man anstelle einer freigabe (wegen locking etc.) ein iscsi-drive verwenden?

das sollte sich ja (eigentlich) wie eine "normale" lokale hd verhalten...


beim apache kann ich ein solches laufwerk problemlos angeben als pfad.


----------



## ruutaiokwu (7. Dez 2012)

bis jetzt gab's noch keine probleme mit iscsi. hat jemand evtl. andere erfahrungen gemacht?


----------

