Folien Unix-Stammtisch/LUG: PDF, OpenOffice
Folien Themenabend: Grundlagen PDF, Grundlagen OpenOffice, svn PDF, svn OpenOffice
Eigentlich ganz einfach:
svnadmin create /pfad/zu/repository
Jetzt müssen nur noch die Zugriffsrechte korrekt gesetzt werden (s.u.).
Man sollte ein SVN-Repository nicht auf einem Netzwerkdateisystem aufsetzen, da es sonst zu Konflikten kommen kann, wenn mehrere Nutzer gleichzeitig zugreifen (auch wenn das auf der selben Maschine passiert). Die unter SVN liegende Berkeley-DB benutzt eine Lock-Methode, die von NFS, SMB und Co. nicht unterstützt wird, dadurch laufen die Locks ins Leere...
svn checkout URL meinpfad - checkt das Repository von URL nach meinpfad aus. (Kreiert eine lokale Kopie der Sourcen.)
svn add datei - fügt datei der Versionskontrolle hinzu. Die Datei wird nur als kontrolliert markiert, aber noch nicht hochgeladen. Man kann auch ganze Verzeichnisse hinzufügen.
svn remove datei - entfernt datei aus der Versionskontrolle. Die Datei wird nur lokal gelöscht und zum Löschen im Repository für den nächsten Commit vorgemerkt. Das Löschen entfernt die Datei nur aus neueren Versionen, in der Historie ist sie noch drin. Es gibt keine Möglichkeit eine Datei komplett aus dem "Gedächtnis" von Subversion zu löschen.
svn revert datei - macht die lokalen Änderungen an einer Datei seit dem letzten Update rückgängig.
svn update [datei] - holt die neueste Version aus dem Repository.
svn commit [-m "Kommentar"] [datei] - kopiert alle lokalen Änderungen ins Repository.
svn switch URL - schaltet den lokalen Source auf eine neue URL (z.B. Branch oder Tag) unter Beibehaltung der lokalen Änderungen.
svnadmin dump |gzip >dumpfile.gz - sicheres Backup im laufenden Betrieb.
Es gibt natürlich noch wesentlich mehr Befehle und Optionen. Dazu sei dem Leser das Subversion-Manual ans Herz gelegt. (Link s.u.)
Solange man alleine arbeitet gibt es kaum Probleme.
Die URLs sehen so aus file:///pfad/zum/repository/[subpfad/im/repository] - der normal geschriebene Teil ist dabei der Pfad zum Repository, das mit svnadmin create angelegt wurde, der kursive Teil ist der Pfad innerhalb der Datenbank des Repositorys.
Wenn mehrere Nutzer Zugriff haben sollen müssen die Zugriffsrechte des Repositories im Dateisystem so gesetzt sein, dass jeder der Nutzer Lese- und Schreibrecht hat, auch wenn er das Repository nur lesend benutzen soll (was sich nicht explizit einschränken läßt). Die umask der Nutzer muss so gesetzt werden, dass sie die Rechte nicht einschränken. Viele Admins benennen svn in svn.bin um und bauen sich einfach ein Wrapper-Script, das die richtigen Werte setzt:
#!/bin/sh
umask 000
svn.bin "$@"
Man hat die Möglichkeit via svnserve, ssh oder Apache zu arbeiten.
Svnserve muss per inetd eingebunden oder als Daemon gestartet werden. Er muss vorher so konfiguriert werden, dass die Zugriffsrechte der Nutzer stimmen. Man kann den Nutzern jeweils Lese- oder Schreibrecht auf das gesamte Repository einrichten. Feinere Abstufungen gehen nicht. URLs haben die Form svn://host/pfad...
Es ist möglich SVN durch SSH zu tunneln. Dabei authentifiziert sich der Nutzer via ssh und benutzt dann SVN durch den Tunnel, als wäre er lokal angemeldet. Entsprechend gelten die selben Einschränkungen zu Zugriffsrechten, wie oben.
Die Arbeit via Apache ist am schwierigsten einzurichten, aber auch am flexibelsten. Es ist möglich die Zugriffsrechte der Nutzer per Pfad im Repository zu steuern und mehrere Repositories gleichzeitig zugänglich zu machen. Hier ist es auch möglich via Web-Proxy auf das Repository zuzugreifen. Wie Apache und Subversion gemeinsam installiert werden habe ich in den unten verlinkten Artikeln beschrieben.
(Englisch)