Subversion (SVN) einrichten von A bis Z

Subversion Logo

Subversion Logo

In diesem Beitrag schreibe ich darüber, wie man Subversion (SVN) von A bis Z auf seinem Server einrichtet. Das Tutorial geht quasi von Nichts bis zum ersten externen Subversion (SVN) Checkout. Zudem wird auch Dropbox in den Beitrag miteinbezogen. Der Beitrag kann 1:1 ausprobiert werden.

Inhalt

Was ist Subversion (SVN)?
Eigener Subversion (SVN) Server vs. Dropbox
Die Umgebung
Die Konfiguration des Subversion (SVN) Servers
Erstes Repository anlegen
Die Konfiguration des externen Zugangs
Die Konfiguration des Clients
Der erste externe Checkout
Subversion (SVN) kombiniert mit Dropbox
Schlusswort
Quellen

Was ist Subversion (SVN)?

Subversion (SVN) ist ein Versionsverwaltungssystem für Dateien und Ordner. Für jede Änderung an einer Datei oder an einem Ordner gibt es eine neue Version. Ältere Versionen von Dateien und Ordner können wenn nötig wiederhergestellt werden.

Ich habe mir aus folgenden Gründen einen Subversion (SVN) Server konfiguriert

  • Daten sind über HTTPS von praktisch überall erreichbar
  • Daten müssen nicht mehr mit USB von PC zu PC kopiert werden weil sie zentral auf dem Server liegen
  • Versionsverwaltungssystem. Schluss mit „Ach, auf welchem PC liegt nun die aktuellste Version der Datei?“
  • Backup. Auf jedem Client liegt quasi ein Backup der Daten

Eigener Subversion (SVN) Server vs. Dropbox

Über die Pros und Contras gibt es sicher unterschiedliche Ansichten. Ich freue mich auf die Diskussion in den Kommentaren ;-).

Dropbox Pro

  • Benötigt keinen eigenen Server
  • Wahrscheinlich höhere Verfügbarkeit als eigener Server
  • Dateien und Ordner werden ohne weiteres Skrippten automatisch synchronisiert
  • Sehr einfache Bedienung für einen Benutzer

Dropbox Contra

  • Speicherplatz nur 2GB (bis zu 10GB gratis)
  • Daten sind extern gehostet
  • Versionen älter 30 Tage können nicht mehr wiederhergestellt werden

Eigener Subversion (SVN) Server Pro

  • Mehr Speicherplatz (hängt natürlich vom Server ab)
  • Daten sind nicht extern gehostet
  • Keine Zeitlimitierung der Versionen
  • Man kann selbst ausprobieren und konfigurieren (grösserer Lerneffekt)
  • Grösserer Funktionsumfang als Dropbox (erweiterbar)

Eigener Subversion (SVN) Server Contra

  • Ein eigener Server wird benötigt der 24h * 7d läuft
  • Ausfälle sind wahrscheinlicher
  • Ein gewisses Know How muss vorhanden sein

Zusammenfassend hat der eigene Subversion (SVN) Server mehr Ressourcen und Dropbox dafür eine höhere Verfügbarkeit, jedoch sind die Daten mit Dropbox extern gehostet. Mit Subversion (SVN) und Dropbox in Kombination kann man das Maximum erreichen.

Umgebung

Dies ist die Umgebung in diesem Beitrag. Eure Umgebung muss nicht exakt die gleiche sein. Bei Unsicherheiten fragt einfach in den Kommentaren oder schreibt mir.

Externer Zugang

  • DynDNS Adresse wie zum Beispiel root1024.dyndns.info

Router

  • pfSense
  • DNS Forwarding konfigurierbar
  • DynDNS konfigurierbar

Server

  • Aktuelles Debian
  • Apache Webserver
  • Subversion

Client

  • Windows 7
  • Tortoise SVN Client

Die Konfiguration des Subversion (SVN) Servers

Apache / Subversion installieren und für die Adresse konfigurieren
Apache / Subversion installieren

aptitude install subversion apache2 libapache2-svn

Neue Seite von der Default Seite kopieren

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/root1024.dyndns.info

Verzeichnis für die neue Seite erstellen

mkdir /var/www/root1024.dyndns.info
touch /var/www/root1024.dyndns.info/index.html
chown -R www-data:www-data /var/www/root1024.dyndns.info/

In /etc/apache2/sites-available/root1024.dyndns.info werden die Werte ServerName und DocumentRoot angepasst

ServerName root1024.dyndns.info # Deine Adresse
DocumentRoot /var/www/root1024.dyndns.info/ # Pfad zum Verzeichnis der Seite

Die Seite aktivieren

a2ensite /etc/apache2/sites-available/root1024.dyndns.info

und apache neustarten

/etc/init.d/apache2 restart

Nachdem wir im DNS Server einen Eintrag von root1024.dyndns.info –> SVN Server IP eingerichtet haben, ist die Webseite jetzt über http://root1024.dyndns.info erreichbar.
Apache um SSL erweitern
Das SSl Modul von Apache aktivieren

a2enmod ssl

Neue Seite von der SSL-Default Seite kopieren

cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/root1024.dyndns.info-ssl

Das SSL Zertifikat erstellen

mkdir /etc/apache2/ssl
openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem
ln -sf /etc/apache2/ssl/apache.pem /etc/apache2/ssl/`/usr/bin/openssl x509 -noout -hash < /etc/apache2/ssl/apache.pem`.0
chmod 600 /etc/apache2/ssl/apache.pem

In /etc/apache2/sites-available/root1024.dyndns.info-ssl werden die Werte ServerName, DocumentRoot und SSLCertificateFile angepasst. Die Zeile SSLCertificateKeyFile wird auskommentiert oder entfernt.

ServerName root1024.dyndns.info
DocumentRoot /var/www/root1024.dyndns.info
SSLCertificateFile    /etc/apache2/ssl/apache.pem
#       SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

Ohne Kommentare sieht die Datei so aus

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
        ServerAdmin webmaster@localhost
        ServerName root1024.dyndns.info
        DocumentRoot /var/www/root1024.dyndns.info/
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/root1024.dyndns.info/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /var/log/apache2/error.log

        LogLevel warn

        CustomLog /var/log/apache2/ssl_access.log combined

        Alias /doc/ "/usr/share/doc/"
        <Directory "/usr/share/doc/">
                Options Indexes MultiViews FollowSymLinks
                AllowOverride None
                Order deny,allow
                Deny from all
                Allow from 127.0.0.0/255.0.0.0 ::1/128
        </Directory>

        SSLEngine on

        SSLCertificateFile    /etc/apache2/ssl/apache.pem

        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>

        BrowserMatch ".*MSIE.*" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>

Die Seite aktivieren

a2ensite /etc/apache2/sites-available/root1024.dyndns.info-ssl

und apache neustarten

/etc/init.d/apache2 restart

Die Webseite ist jetzt unter https://root1024.dyndns.info erreichbar.

Erstes Repository anlegen

Ein neues Repository wird mit

mkdir -p /var/local/subversion/projekt
chown -R www-data:www-data /var/local/subversion/projekt
svnadmin create --fs-type fsfs /var/local/subversion/projekt

angelegt. In den Dateien /etc/apache2/sites-available/root1024.dyndns.info und /etc/apache2/sites-available/root1024.dyndns.info-ssl muss noch der Block

<Location /projekt> # Teil der URL https://root1024.dyndns.info/projekt
	DAV svn
	AuthType Basic # oder Digest
	AuthName "Projekt" # Bereichsname bei der Authentifizierung
	AuthUserFile /etc/apache2/subversion.passwd # Pfad zur Datei mit Benutzern und Passwörtern
	SVNPath /var/local/subversion/projekt # Pfad zum Repository
	Require valid-user # Nur gültige Benutzer haben Zugriff auf das Repository
</Location>

hinzugefügt werden. Der erste Benutzer für Subversion (SVN) wird mit

htpasswd -c /etc/apache2/subversion.passwd Benutzer

erstellt. Jeder weitere Benutzer mit

htpasswd /etc/apache2/subversion.passwd Benutzer

Stefan hat mich noch auf AuthType Digest hingewiesen. Mit dieser Einstellung wird bei der Authentifizierung über HTTP das Passwort nicht im Klartext, sondern verschlüsselt gesendet. So kann das Passwort nicht gesnifft werden. Die übertragenen Daten sind jedoch immer noch unverschlüsselt, weshalb man SSL (HTTPS) nutzen sollte! Mit SSL (HTTPS) werden die Authentifizierung und die übertragenen Daten verschlüsselt, somit reicht wenn über SSL (HTTPS) AuthType Basic.

Die Konfiguration des externen Zugangs

DynDNS

Um den Router aus dem Internet zu erreichen verwendet ihr entweder direkt eure öffentliche IP oder ihr richtet bei DynDNS einen Account und eine Adresse ein. Zweites ist empfohlen, wenn ihr eine dynamische öffentliche IP habt. Der Router leitet später die richtigen Anfragen an den Subversion (SVN) Server weiter.

Nachdem ihr einen Account bei DynDNS erstellt und eine Adresse (Hostname) eingerichtet habt, ist euer Router über die Adresse erreichbar. Dies kann einfach mit nslookup geprüft werden.

nslookup root1024.dyndns.info
Server:  Router
Address:  192.168.0.1

Nicht autorisierende Antwort:
Name:    root1024.dyndns.info
Address:  88.198.47.75

Falls die öffentliche IP wechselt muss der Router DynDNS die neue öffentliche IP mitteilen. Dies muss noch am Router konfiguriert werden. Bei pfSense befindet sich die Konfiguration unter „Services –> Dynamic DNS“. Auf dieser Seite den Bereich „Dynamic DNS client“ aktivieren und die Daten ausfüllen mit Adresse (Hostname) wie zum Beispiel root1024.dyndns.info, User und Passwort.

Nun könnt ihr euren Router vom Internet her über die Adresse (Hostname) immer erreichen, auch wenn die öffentliche IP wechselt.

Firewall Regel

Damit der Router alle Anfragen auf Port 443 an den Subversion (SVN) Server weitergibt, muss im Router noch eine Firewall Regel konfiguriert werden. In pfSense geschieht dies unter „Firewall –> NAT“. In pfSense kann die NAT Regel wie folgt konfiguriert werden:

Firewall Regel

Firewall Regel

DNS Forwarding

Mit einem älteren Router habe ich das Problem gehabt, dass die Anfrage an die Adresse zum Provider ging und vom Provider an meinen Subversion (SVN) Server. Die Geschwindigkeit war aus unerklärlichen Gründen kleiner als 1KB/s. Der Router hat nicht gemerkt, dass die Adresse auf eine IP im internen Netzwerk zeigt. Solltet ihr ähnliche Probleme haben, leitet die Adresse wie zum Beispiel root1024.dyndns.info an eurem DNS Server gleich an die IP des Subversion (SVN) Servers weiter.

Jetzt ist der Subversion (SVN) Server vom Internet via HTTPS (Port 443) und vom internen Netzwerk via HTTPS (Port 443) und HTTP (Port 80) über die Adresse verfügbar.

Die Konfiguration des Clients

Auf dem Windows Client muss nur ein SVN Client wie zum Beispiel TortoiseSVN (download 32 Bit | download 64 Bit) installiert werden. Die Installation von TortoiseSVN benötigt einen Neustart des Computers.

Der erste externe Checkout

Das Repository sollte von extern über einen Browser erreichbar sein. Funktioniert dies ist der erste externe Checkout mit TortoiseSVN schnell erledigt.

Checkout

Checkout

Subversion (SVN) kombiniert mit Dropbox

Die SVN Daten können in Dropbox ausgelagert werden für den Fall, dass der eigene Subversion (SVN) Server einmal nicht erreichbar sein sollte. Die Daten können einfach mit rsync oder robocopy synchronisiert werden. Die .svn Ordner können in cmd einfach mit

FOR /F "delims=" %var IN ('dir C:\Users\Benutzer\Desktop\projekt /b /s /a:H .svn') DO rmdir /S /Q %a

und unter Linux mit

find /tmp/projekt/ -name .svn -exec rm -r {} \;

gelöscht werden.

Schlusswort

Alles in Allem bin ich mit meinem privaten Subversion (SVN) Server, den ich schon seit ca. 2 Jahren nutze, sehr zufrieden. Ich hoffe der Beitrag hilft euch weiter bei der Installation und Konfiguration von einem Subversion (SVN) Server. Ich muss noch betonen, dass man mit einem eigenen Subversion (SVN) Server sehr viel mehr Möglichkeiten hat als in diesem Beitrag aufgezeigt werden.

Bei Fragen einfach einen Kommentar schreiben oder das Kontaktformular benutzen. Freue mich wie immer über Kritik und Lob.

Quellen

Ubuntuusers Subversion

Ubuntuusers Apache SSL

24 Antworten
  1. zaidira
    zaidira says:

    Schöner Beitrag. Gerade wenn man das erste mal SVN einrichtet, hilft so eine Anleitung sehr. Ich benutze zwar inzwischen Git (hauptsächlich, weils dezentral ist), aber es ist schön mal eine übersichtliche Anleitung zu haben. Die bei Ubuntuusers hilft zwar, ist aber find ich nicht seht schön vom Aufbau her.
    Also schöner Beitrag.

  2. Bitscribble
    Bitscribble says:

    Hi!
    Die Idee mit der Dropbox als Backup ist echt super… als ich deinen Artikel geleseh habe, ist mir noch eine weitere Idee gekommen: Wie wäre es statt einem kompletten SVN Server mit einem lokalen Repository im Dropbox Ordner? Dann sparst du dir das ganze Hickhack mit Apache, Dyndns und dem Router!!!

    ciao, Bittscribble

  3. Silvan
    Silvan says:

    @ zaidira
    Ich habe beim ersten Mal einrichten des SVN Server auch meine Probleme gehabt und darum eine A-Z Anleitung geschrieben.

    Git habe ich damals noch nicht gekannt, sonst hätte ich vielleicht auch Git genommen.

    Danke.

    @ Bitscribble
    Du könntest am SVN Server Dropbox einrichten und das Repository in den Dropboxordner legen. Das ganze Hickhack braucht es aber trotzdem, sonst hab ich ja keinen kompletten SVN Server. Ziel ist es, mit SVN zu arbeiten und Dropbox nur als Backup zu benutzen.

    Danke für euere Rückmeldungen.

    Ciao
    Silvan

  4. Andreas Schulte
    Andreas Schulte says:

    Danke für die tolle Anleitung und Gegenüberstellung.

    Ich hatte auch mal Subversion genutzt, jedoch im Vergleich zu Dropbox war mir das zu viel gefrickel… zuerst… Drop-Box ist out of the box eben einfach zu bedienen. Subversion muss man noch Hand anlegen…. was ich aber jetzt, dank dir 😀 machen werde!

    Many many thx!

  5. Silvan
    Silvan says:

    Freut mich das dir der Beitrag gefällt. Ja ich kann einen eigenen SVN Server nur empfehlen, SVN ist wirklich sehr einfach einzurichten.

    Gruss
    Silvan

  6. sadi
    sadi says:

    Hi Silvan

    Dieser Blogpost ist echt super. Ich wäre nicht auf die Idee gekommen, SVN mitt Dropbox zu vergleichen. Nach deinem Post ist mir aber durchaus klar, dass dieser Vergleich berechtigt ist 🙂

    Ich würde noch erwähnen, dass Dropbox sehr intuitiv zu benutzen ist, während SVN schon ziemlich viel Vorwissen zur Bedienung erfordert.

    Ein Pro für SVN währen dann auch noch die verschiedenen Apache-Module, die zur Userautorisierung eingesetzt werden können. Ich selbst benutze mod_auth_mysql zur feingranularen Zugriffbeschränkung.

    grz sadi

  7. Silvan
    Silvan says:

    Freut mich gefällt dir der Beitrag. Viele Mitschüler verwenden Dropbox, obwohl ein SVN Server ja auch nicht aufwendig ist. Darum habe ich noch den Vergleich mit Dropbox gemacht. Beides hat Vor- und Nachteile, aber zusammen ergeben sie ein Maximum.

    Danke für den Input, werde den Beitrag noch aktualisieren.

    edit: Beitrag aktualisiert

    Gruss
    Silvan

  8. Geier
    Geier says:

    Ein dezentrales Versionsverwaltungssystem wie zum Beispiel Git oder Mercurial, lässt sich sehr schön mit Dropbox erstellen: Einfach das Repository in der Dropbox einrichten, schon hat man unendlich viel History ohne großes Eingerichte und man braucht auch keinen eigenen Server.

    Nur dass man sich selbst Speicherpunkte setzten muss. Das ist immer noch ein Vorteil von Dropbox.

  9. Jeffrey
    Jeffrey says:

    Ich verwende aktuell ebenfalls nur die Dropbox. Habe darin aber auch nur Daten, die ich nicht als „Persönlich“ einstufe.

    Falls sich das mal ändern sollte habe ich ja immer noch TrueCrypt mit dem ich die Daten zusätzlich noch verschlüsseln kann.

    Werde mir die SVN Anleitung aber mal noch ablegen. Vielen Dank!

    PS: Es fehlt hier im Blog die Funktion Kommentare per Mail zu abonnieren.

  10. Silvan
    Silvan says:

    @Geier
    Interessanter Ansatz, daran habe ich gar noch nicht gedacht. Ich finde, dies ist aber kein Vorteil für Dropbox, denn man könnte doch theoretisch das Git Repository einfach im SVN Repository (anstatt Dropbox) ablegen? Das wäre doch dann das Gleiche.

    @Jeffrey
    Anfangs habe ich auch Dropbox benutzt, bald wurde der Speicherplatz aber zu wenig, ich wollte mehr als 30 Versionen der Daten und ich wollte Dropbox nicht all meine Daten anvertrauen ;-). Die Daten mit TrueCrypt zu verschlüsseln habe ich mir auch schon gedacht, weil ich aber oft Dokumente ändere, müsste ich immer den ganzen Container synchronisieren und das dauert bei meiner Netzwerkanbindung.

    Danke für den Anstoss mit der Kommentar Email Funktion, werde ich ausprobieren und umsetzen.

    PS: Toll hat es die Anleitung in deine Sammlung geschafft 😉

    Gruss
    Silvan

  11. u2ix
    u2ix says:

    Ich bevorzuge Git, weil es viel einfacher einzurichten ist, bspw. mit Gitoris.

    Zudem ist es viel schneller.

  12. Silvan
    Silvan says:

    Git habe ich, als ich SVN eingerichtet habe, noch nicht gekannt und darum SVN verwendet. Git ist sicher eine Alternative.

  13. Victor
    Victor says:

    Kannst du nicht ein Video-Tutorium daraus machen, das ist ein schwieriges Thema und gleichzeitig eine gute Sache.

    Ich habe nach welche gesucht, konnte aber keine auf Deutsch finden.

    glaube mir, die Idee ist nicht schlecht und viele hätten auch mehr Mut es aus zu probieren.

    🙂

  14. Silvan
    Silvan says:

    Danke für den Input.

    Ein Video Tutorial wäre auch eine Möglichkeit, jedoch kann man dort nichts 1:1 rauskopieren und man macht die genau gleichen Befehl wie oben Beschriebenen ;-). Ich werde es mir aber für das nächste Tutorial überlegen.

    Sollte es bei Dir nicht funktionieren, schreib mir einfach, ich helfe Dir gerne beim Einrichten.

    Gruss
    Silvan

  15. victor
    victor says:

    Hallo Silvan, ich danke dir für deine Hilfsbereitschaft.

    Gut ich richte mir nach deine Tutoria den SVN-Server ein, habe jetzt eine Frage und zwar, was wäre wenn ich der
    Ordner für die SVN Dateien der sich auf: /var/local/subversion/projekt befinden

    auf /var/www/root1024.dyndns.info/ verschieben würde.

    ist das eine gute Idee und kann das funktionieren?

    ———–
    noch was

    Ich denke ich habe einige Fehler in das Tutorial bei ausprobieren entdeckt:
    1. die meinten befehlen fordern Andmin rechte also immer (sudo) schreiben
    2. cp /etc/apache/site-available/default-ssl /etc/apache/site-available/root1024.dyndns.info-ssl

    sollte apache nicht apache2 heissen?

    so ich dank dir schon viel mal für das Tutorial und freue mich auf deine Antwort.

    Mit freundlichen Grüssen

    Victor

  16. Silvan
    Silvan says:

    Hi Victor

    1) Ich habe dies soeben getestet und wenn das SVN Repository in /var/www/… liegt, bekommt man beim SVN Checkout immer den Fehler: „Repository moved permanently to ….“. Das SVN Repository darf nicht im Ordner /var/www oder tiefer liegen. Dies ist auch so in der FAQ von Subversion beschrieben: I can see my repository in a web browser, but ’svn checkout‘ gives me an error about „301 Moved Permanently“. What’s wrong?

    2) Ja die Befehle erfordern Adminrechte. Ich arbeite jedoch unter Debian sowieso immer als root 😉

    3) Ja das ist ein Fehler, danke, ich habe es korrigiert.

    Viel Spass mit deinem SVN Server.

    MfG
    Silvan

  17. Victor
    Victor says:

    hallo Silvan

    ich komme nicht weiter

    am welche stelle kommt:

    #Modifiziert am 14.02.11
    # Teil der URL https://suXXe.dyndns.org/projekt
    DAV svn
    AuthType Basic # oder Digest
    AuthName „Projekt1“ # Bereichsname bei der Authentifizierung
    AuthUserFile /etc/apache2/subversion.passwd # Pfad zur Datei mit Benutzern und Passwörtern
    SVNPath /var/local/subversion/android/projekt1 # Pfad zum Repository
    Require valid-user # Nur gültige Benutzer haben Zugriff auf das Repository

    den ich bekomme immer diese Fehlermeldung:

    yntax error on line 58 of /etc/apache2/sites-enabled/suXXe.dyndns.org-ssl:
    AuthName takes one argument, The authentication realm (e.g. „Members Only“)
    Action ‚configtest‘ failed.
    The Apache error log may have more information.
    …fail!

    Bitte sag mir, was ich machen soll.

    MfG

    Victor

  18. Silvan
    Silvan says:

    Ja diesen Befehl musst du noch ausführen. Habe den Befehl im Beitrag noch ergänzt.

    Das Ende meiner Konfigurationsdatei sieht so aus:
    # Teil der URL https://root1024.dyndns.info/projekt
    DAV svn
    AuthType Basic # oder Digest
    AuthName „Projekt“ # Bereichsname bei der Authentifizierung
    AuthUserFile /etc/apache2/subversion.passwd # Pfad zur Datei mit Benutzern und Passwörtern
    SVNPath /var/local/subversion/projekt # Pfad zum Repository
    Require valid-user # Nur gültige Benutzer haben Zugriff auf das Repository

    Ich weiss nicht, warum Deine Zeichen verschwunden sind, aber ich habe sie nicht verschwinden lassen ;-). Bei mir sind ebenfalls Wörter verschwunden. Das gleiche Problem hatte ich schon einmal, ich bin an der Lösung dran.

  19. Silvan
    Silvan says:

    Das Problem wurde behoben und es können nun Linuxbefehle und Dateiauszüge problemlos in die Kommentare geschrieben werden. Danke für den Hinweis.

  20. lousek
    lousek says:

    Sali Silvan

    Hier evt. noch etwas interessantes zu den Repository-Berechtigungen:
    http://wiki.wsmoak.net/cgi-bin/wiki.pl?Subversion/Configuration#Set_up_authz

    Mit der Authz-Datei kann der Zugriff über den SVN-Pfad eingeschränkt werden.
    So kann beispielsweise ein Repository erstellt werden, wo „everyone“ Lese-Zugriff hat aber nur ein bestimmter User Schreibzugriff über alles, und ein anderer über ein bestimmtes Verzeichnis (/trunk/hihi) hat:
    SVNAUTHZ:
    [/]
    * = r
    blubb = rw

    [/trunk/hihi]
    * = r
    blubb = rw
    hihi = rw

    Das wichtige hierbei ist, dass in jedem Unterordner die Berechtigungen „absolut“ vergeben werden müssen, also sie werden nicht „addiert“: Wenn ich jetzt bei [/trunk/hihi] den User blubb nicht eingetragen hätte, so hätte dieser dann auf alle anderen Ordner AUSSER /trunk/hihi Schreibzugriff!

    LG
    Lousek

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Wir freuen uns über ihren Beitrag!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *