Albrecht Weinert Labor für Medien und verteilte Anwendungen Fachbereich Elektrotechnik und Informatik (FB3) Tipps zu Subversion ===================== Stand V00.00, 14.06.2005: neu V00.01, 20.06.2005: Abstrusitäten teilweise geklärt V00.02, 27.06.2005: Multiprojekt und Windows-Client-Probl. teilw. gekl. V00.03, 28.06.2005: diverse Verbesserungen (Dank an Ralf Seidel) V00.04, 01.07.2005: keywords, CVSkeys V00.09, 14.07.2005: div. Korrekturen und Klarstellungen, SVNhook.java V01.00, 18.01.2006: kl. Korr. (und in CVSwin) V.22 02.12.2008: Revisionssprung wg. Subversion-Umstellung V.37+ 08.12.2008: Kleinigkeiten V.333+ 14.09.2016: keine inhaltliche Änderung. Es bleibt Stand 2008; siehe stattdessen svn-win-de.pdf Version V.1 Zuletzt geändert von A. Weinert am 23.09.2016 Copyright (c) 2001 - 2006, 2008 Albrecht Weinert All rights reserved. a-weinert.de Hinweis: Siehe bitte auch bzw. stattdessen [svn-win-de.pdf] im selben Verzeichnis. Einstieg: http://a-weinert.de/pub. Inhalt: 1. Zweck, Voraussetzungen 2. Server - Installation 3. Einrichten eines Repository auf dem Server 4. Zugriffsrechte und Server-Start 5. Client - Installation 6. (Test-) Zugriff vom Client-Rechner 7. Anhang Anhang A: SVN Service Wrapper for Windows Anhang B: SVN Client hinter einem Proxy Anhang C: Mehrere Projekte auf dem SVN - Server Anhang D: Anmerkung zu CVS-Vergleichen 1. Zweck, Voraussetzungen ~~~~~~~~~~~~~~~~~~~~~~ Das im folgenden beschriebene Vorgehen zeigt Ihnen, wie Sie den * Versionskontrolldienst Subversion auf einem Windows-Server installieren. Die Installation auf einem Client-Rechner ist vergleichsweise einfach und fällt, so zu sagen, umsonst mit ab. Voraussetzungen: a.) Sie haben die Programmdateien 29.04.2005 15:14 2.897.857 svn-1.1.4-setup.exe 03.05.2005 12:03 61.440 SVNService.exe oder Nachfolge-Versionen. Die Quellen sind: http://subversion.tigris.org/ bzw. http://dark.clansoft.dk/~mbn/svnservice/ b.) Sie haben Zugang mit Administratorrechten auf dem Windows-Server, auf dem Sie den Subversion-Server einrichten möchten. Es genügt ein remote terminal Zugang. c.) Nützlich ist auch das Subversionsbuch 29.12.2004 18:58 1.464.144 svn-book.pdf oder 25.03.2004 18:54 1.297.493 book.pdf Das "Buch" ist allerdings nur für die eigentliche "Nicht-Windows-" Handhabung als Benutzer eines Subversion-Klient nützlich. Für alle Windows-Besonderheiten oder gar für eine Windows-Installation ist es eher irreführend bis "richtig falsch". Anmerkung zu Linux-Software unter Windows: Subversion erweist sich als ein typisches open-source-LINUX-Projekt, in diesem Fall mit einem Linux-Apache als bevorzugte Serverbasis (Ende der Feststellung). Wie oft in guten Linux-Projekten, meint irgendwann jemand -- und das ist ja durchaus verdienstvoll --, dass man auch noch für Windows- Versionen sorgen sollte. Aber da ist das Kind meist schon in den Brunnen gefallen: Die Software versteht nix von vernünftigen Dateirechten (ACLS) sondern nur die 9 Steinzeitbits. Es gibt keinen Anschluss an Windows- Nutzerrechte und -Authentifizierung und ein 7-Bit-Zeichensatz gilt als non plus ultra -- ISO8859-1 oder gar Unicode: Fehlanzeige. Im Falle Subversion unter Windows hüllt man den Start des (Nicht-Apache-) Servers als Dienst besser in Schweigen. Für dieses svnServe.exe, das nur als Windows-Dienst seinen Lebenszweck erfüllen kann, gibt es nur komplizierte und letztlich nicht funktionierende Bastelanleitungen. Am Ende hilft ein kleines Spezialprogramm. Man sieht mit Linux-Software unter Windows also zurecht einen Leidensweg vor sich. Erst wenn man im nachhinein weiß, wie's geht und wie doch nicht, ist alles nicht mehr so schlimm. Dies ist auch der Zweck dieser "Tipps". 2. Server - Installation ~~~~~~~~~~~~~~~~~~~~~~ Lassen Sie svn-1.1.4-setup.exe auf dem Ziel-Server laufen. Akzeptieren Sie die Lizenzbedingungen und akzeptieren / setzen Sie C:\Programme\Subversion als Zielverzeichnis der Installation. Wechseln Sie ins Verzeichnis C:\Programme\Subversion\bin. Dort sollten sich u.A. die Dateien 04.04.2005 00:18 794.722 svn.exe 04.04.2005 00:18 307.296 svnadmin.exe befinden. Der Installationsvorgang hat auch C:\Programme\Subversion\bin. an den Programmsuchpfad gehängt. Der sollte nun sinngemäß so aussehen: PATH = c:\bat;c:\programme\util;c:\programme\jdk\bin;C:\WINDOWS\system32; C:\WINDOWS;C:\Programme\Subversion\bin Kopieren Sie nun noch die Datei 03.05.2005 12:03 61.440 SVNService.exe in dieses Verzeichnis (C:\Programme\Subversion\bin). Damit ist die Grundinstallation auf dem Server abgeschlossen. Anmerkung: Wenn Sie nach Abschluss aller weiteren Schritte nie / kaum auf dem Server mit Subversion arbeiten werden (weil's halt ein Server in einem abgeschlossenen Serverraum ist), können Sie die freundlich zugefügte PATH- Ergänzung wieder löschen. (Irgendwie verlängern Installationsprogramme oft triebhaft und ohne zu fragen PATH um 5 cm, auch wenn's nicht unbedingt sein muss.) Nacharbeit: Beseitigen Sie mit der Systemsteuerung CAPR_ICONV_PATH = :\Programme\Subversion\iconv aus Ihren Umgebungsvariablen (als Nutzer); es gibt sie auch noch mal als System-Variable -- das reicht für alle. (Noch ist unklar, wozu der Eintrag an sich dient und ob er auch nur einmal sein muss.) 3. Einrichten eines Repository auf dem Server ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erzeugen Sie ein Verzeichnis, in dem das Repository (Berkeley-DB-Dateien und was Subversion sonst noch so braucht) liegen soll. Zum Beispiel: D:> md D:\SVNrepos und geben Sie den gewünschten Nutzern dieses Repositories entsprechende Rechte (Vollzugriff F oder Lesen R), auch wenn die meisten davon dieses Verzeichnis und seinen Inhalt nie selbst anfassen werden. Hinter dieser Empfehlung, steht das Versprechen, dass sich Subversion-Klient- Zugriffe unter Umständen (SSH) nach den Windows-Datei-ACLs richten könnten. Dies würde das Linux-typische "noch eine Passwortdatei" (System, Samba, Apache LDAP, ....) vermeiden. Es hat aber bis jetzt nicht funktioniert. Somit genügte es, dass das Konto, unter dem SVNserve (als Dienst) läuft, Vollzugriff hat. Erzeugen Sie ein leeres Repository im Beispiel SVNrepos auf dem Laufwerk D:. D:>svnadmin create \SVNrepos Das gewählte Laufwerk muss (wie im Beispiel) lokal sein. Erzeugen Sie (temporär) einen Verzeichnisbaum \temp\projekt\branches\ \tags\ \trunk\ \readme.txt readme.txt ist in diesem Beispiel eine von Ihnen bereitgestellte kleine Testdatei zum Probieren. Importieren Sie dieses von Subversion so gewollte / empfohlene Gebilde. D:>svn import \temp\projekt file:///SVNrepos -m "Erster Import" Starten Sie den Subversionsserver mit SVNService -install -d -r D:\SVNrepos Das eben geschilderte Vorgehen erzeugt ein namenloses "root"- Projekt im Server-Repository. In dem selben Server lassen sich beliebig viele weitere benannte unabhängige Projekte einrichten. Die hierzu erforderlichen -- dem eben geschilderten sehr ähnlichen Schritte zur Einrichtung mehrerer / weiterer Projekte finden Sie unten im Anhang C. Wenn Sie mehrere (benannte) Projekte auf dem selben Server haben wollen, werden Sie sinnvollerweise kein namenloses "root"- Projekt wünschen. Benutzern, welche nach der Server-URL (z.B. svn://PD3082) den Projektnamen vergessen, bemerken diesen Fehler u.U. nicht, wenn sie so ins namenlose Projekt geraten können. 4. Zugriffsrechte und Server-Start ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Im Verzeichnis D:\SVNrepos\conf bearbeiten Sie die beiden Text-Dateien 20.06.2005 08:50 37 passwd 14.06.2005 18:15 .380 svnserve.conf Von Kommentarzeilen abgesehen sollte in svnserve.conf (erst einmal) folgendes stehen: [general] anon-access = read auth-access = write password-db = passwd realm = My First Repository Der Eintrag anon-access = read heißt jeder darf lesen. Setzen Sie none ein, falls nur authentifizierte Nutzer lesen dürfen. Der Eintrag password-db weißt (typisch für ein Betriebssystem ohne ACLs) auf (noch) eine Passwortdatei.Der Wert passwd heißt eine Datei namens passwd im selben Verzeichnis wie diese Datei svnserve.conf. Hier sind auch andere Namen und Pfadangaben möglich, um beispielsweise eine einzige Passwort-Datei für mehrere Projekte dieses Subversion-Servers zu verwenden. In die Datei passwd schreiben Sie mit für Sie passenden Nutzernamen und Passworten (für den Subversion-Zugriff) in der Syntax USERNAME = PASSWORD, also etwas wie: [users] admin=1111 weinert=2222 hulahupp=3333 Gehen Sie nun noch in Systemsteuerung\Verwaltung\ und sorgen Sie dort dafür, dass SVNService (.exe) als Dienst automatisch läuft und gestartet ist. Damit läuft der Subversion-Server; er ist für alle Clients im selben LAN zugreifbar. Melden Sie sich nun auf dem Server ab -- sonst sieht man nicht ob das Ganze wirklich als Dienst weiterläuft. 5. Client - Installation ~~~~~~~~~~~~~~~~~~~~~ Melden Sie sich an einem Client-Rechner mit Administratorrechten an. Installieren Sie dort Subversion mit der (selben) Installationsdatei 29.04.2005 15:14 2.897.857 svn-1.1.4-setup.exe. Kümmern Sie sich wie oben für den Server beschrieben um die Systemvariablen PATH und APR_ICONV_PATH. Machen Sie aber sonst nichts. Melden Sie sich ggf. mit Administratorrechten beim Client-Rechner ab und mit Ihrem üblichen Nutzer-Account wieder an. 6. (Test-) Zugriff vom Client-Rechner ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Erzeugen Sie ein Testverzeichnis und wechseln Sie dort hin. D:> md \temp\d D:> cd \temp\d D:\temp\d> Holen Sie sich das Projekt (im Beispiel heißt der Subversion-Server //PD3082 ): D:\temp\d>svn checkout svn://PD3082 [uhu | . | ] *Anm. 1 und 2) A uhu\trunk A uhu\trunk\readme.txt A uhu\branches A uhu\tags Ausgecheckt, Revision 1. Fragen nach Namen und Passwort beantworten Sie ggf. gemäß Ihren obigen Einträgen in der Passwortdatei passwd auf dem Server. *) Anmerkung 1: Als zweiten Parameter beim obigen Befehl können Sie einen * Verzeichnisnamen (uhu im Beispiel), * nichts (wirkt wie Servername als Verzeichnisname, PD3082 im Beispiel) oder * . (Punkt, aktuelles Verzeichnis bzw. keines) angeben. Wenn Sie nicht ausdrücklich mit . (Punkt) kein Verzeichnis bzw. aktuelles Verzeichnis (D:\temp\d im Beispiel) angeben erzeugt svn ein Verzeichnis D:\temp\d\PD3082\ bzw. D:\temp\d\uhu\ und legt in dieses Verzeichnis Ihr lokales Arbeitsabbild. Dort finden Sie unter Anderem ein Abbild der Server-Repository-Verzeichnisstruktur. Insbesondere sehen Sie die oben erwähnte Testdatei D:\temp\d\uhu\trunk\readme.txt Ändern Sie diese Datei D:\temp\d>editpad D:\temp\d\uhu\trunk\readme.txt Mit svn commit -m "first remote change on readme.txt" können Sie diese Ihre Änderung im Repository auf dem Server einpflegen. Dazu müssen Sie aber in das Verzeichnis klient-lokale uhu (im Beispiel) wechseln. cd uhu D:\temp\d\uhu> svn commit -m "first remote change on readme.txt" Sende trunk\readme.txt Übertrage Daten . Revision 2 übertragen. Machen Sie das Spiel ein paar mal (und die Revision steigt immer weiter). Mit D:\temp\d>svn checkout svn://PD3082 uhu -r 3 U uhu\trunk\readme.txt Ausgecheckt, Revision 3. können Sie dann gezielt bestimmte Revisionen holen. Dazu müssen Sie aber wieder ein Verzeichnis höher. Das heißt checkout erwartet (oder erzeugt implizit) eine Verzeichnisangabe für Ihr lokales Repository-Abbild und commit will darin (als aktuelles Verzeichnis) "leben". Diese Umstände vermeidet man am besten mit "immer darin leben" und für die gewünschte Verzeichnisangabe . (Punkt) einsetzen. *) Anmerkung 2: Als zweiten Parameter beim obigen Befehl sollten Sie also grundsätzlich einen . (Punkt) nehmen, nachdem Sie vorher in Ihr gewünschtes Arbeitsverzeichnis gewechselt sind. 7. Anhang ~~~~~~ Anhang A: SVN Service Wrapper for Windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vergessen Sie alle Beschreibungen, wie man SVNServe(.exe) auf einem Windows-Server als (dauerlaufenden) Dienst startet. Grund: Siehe die Anmerkung zu Linux-Software in Kapitel 1, oben. Um das (ursprünglich) Linux-Programm svnserve als Windows-Dienst starten zu können, hat ein Herr Magnus Norddahl mit Hilfe eines freundlichen Microsoft- Mitarbeiters, Craig Link, einen Wrapper geschaffen. Es folgt die Original-Beschreibung von Magnus Norddahl als Zitat: This is my Win32 Service wrapper for SVN. Source is included, and its in the public domain. No need to copyright this stuff. * SVNService.zip Usage instructions: SVNService -? to display this list SVNService -install to install the service SVNService -setup to change command line parameters for svnserve SVNService -remove to remove the service SVNService -debug to run as a console app for debugging Example: SVNService -install -d -r c:\svnrepo SVNService -setup -d -r c:\otherplace\svnrepo IMPORTANT: Make sure you place SVNService.exe in the same directory as svnserve.exe Special thanks go to Craig Link at Microsoft for creating the initial service.c. Anhang B: SVN Client hinter einem Proxy ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Auch wenn im Vorausgehenden SVNserve besprochen wurde, kann man sich mit svn.exe (als Client) auch an einen http-SVN-Server (Apache) hängen. Muss man dazu durch einen Proxy (wie u.a im Falle aus dem FH-Bochum-LAN nach außen), so muss man die Datei C:\Dokumente und Einstellungen\Weinert.FB3-MEVA\... (Beispiel) ....Anwendungsdaten\Subversion\servers ändern. Für den FH-Fall (als Beispiel) wäre folgendes einzutragen: [global] # http-proxy-exceptions = *.exception.com, www.internal-site.org http-proxy-host = cache http-proxy-port = 8080 # http-proxy-username = defaultusername Beim Versuch mit svn co http://........ einen externen Server abzufragen, bekommt man evtl. ....: 400 Bad Request (http://svn..... Dies lässt sich dann u.U. mit https und (temporärem) Akzeptieren des Zertifikats umgehen. Beispiel: D:\temp\jsvn>svn checkout https://svn.red-bean.com/repos/sussman/subversion/ win32-build/trunk buildscripts-trunk Fehler bei der Validierung des Serverzertifikats für 'https://svn.red-bean.com:443': - Das Zertifikat ist nicht von einer vertrauenswürdigen Instanz ausgestellt Überprüfen Sie den Fingerabdruck, um das Zertifikat zu validieren! - Der Hostname des Zertifikats stimmt nicht überein. Zertifikats-Informationen: - Hostname: Brian W. Fitzpatrick - Gültig: von Feb 17 17:06:40 2005 GMT bis Feb 15 17:06:40 2015 GMT - Aussteller: Cooks, Red Bean Software, Chicago, IL, US - Fingerabdruck: fd:b6:95:21:02:b2:86:3b:f3:58:7c:eb:74:62:24:a1:20:d1:68:b7 Ve(r)werfen, (t)emporär akzeptieren oder (p)ermanent akzeptieren? t A buildscripts-trunk\make-ossl.bat ^ :::::::: ::::::::::::: Ihre Eingabe | A buildscripts-trunk\nightly-test.bat Ausgecheckt, Revision 345. ---- Ende https-Beispiel Wenn man schon bei der o.g. Datei ....Anwendungsdaten\Subversion\servers ist, kann man gleich bei der "danebenliegenden" Datei ....Anwendungsdaten\Subversion\config folgendes eintragen: [helpers] editor-cmd = java de.a_weinert.apps.SVNlogEdit Durch diese Angabe eines primitiven, blockierenden ASCII-Editors beseitigt man einige Verhaltensauffälligkeiten mancher svn-Kommandos. (SVNlogEdit im Beispiel setzt die Installation von Java mit Framework Frame4J voraus. (siehe auch http://a-weinert.de/frame4j/ oder http://frame4j.de) Anhang C: Mehrere Projekte auf dem SVN - Server ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Zum Erzeugen eines weiteren Projekts muss man am SVN-Server eingeloggt sein. Es genügt wieder eine remote terminal Sitzung. Ein zusätzliches Projekt entsteht in drei Schritten: 1. Schritt: Erzeugen D:\SVNrepos>svnadmin create projekt1 Wenn, wie in den Beispielen weiter oben, der Server mit der Option -r gestartet wurde, ist es wichtig, pojekt1 (im Beispiel) unterhalb von D:\SVNrepos zu erzeugen. (Im Beipiel geschah die durch dorthin Gehen als aktuelles Verzeichnis.) Die Option -r macht ja D:\SVNrepos (im Beispiel) zur Wurzel aller Repositories und alles außerhalb des Dateibaums Liegende wäre von den Clients her nicht erreichbar. 2. Schritt: Konfigurieren Im einfachsten Falle kopiert man alle passenden Konfigurationsdateien (Verzeichnis config) und Skripte / Programme (Verzeichnis hooks) mit kleinen sinngemäßen Änderungen von einem anderen Projekt. Hier sei nochmal auf die oben erwähnte Möglichkeit hingewiesen, für mehrere Projekte eine Passwortdatei zu nutzen. 3. Schritt: Besiedeln mit den Dateien D:\SVNrepos>svn import D:\temp\projDocu svn://localhost/projekt1 -m "initial test import to projekt1" Anmeldebereich: My zweites Repository Passwort für 'weinert': ******** Hinzufügen D:\temp\projDocu\trunk Hinzufügen D:\temp\projDocu\trunk\readme.txt Hinzufügen D:\temp\projDocu\branches Hinzufügen D:\temp\projDocu\tags Revision 1 übertragen. Das war's. Anhang D: Anmerkung zu CVS-Vergleichen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Zum Schluss eine Anmerkung zu den zahllosen und ausführlichen Vergleichen von Subversion mit dem ergrauten auf W. Tichys RCS basierten CVS. Die Schilderungen, was Subversion besser macht, sind alle wahr. Dies gesagt muss man auf einen elementaren Mangel von Subversion hinweisen: Subversion versioniert keine Dateien. Das (zusätzlich in der Berkeley-Datenbank) zu implementieren, wäre wohl auch nicht unüberwindbar schwierig gewesen. Sie glauben es einfach nicht? (Geht wohl jedem so.) Also nochmal: Subversion versioniert keine Dateien. Sprich, in einem Software-Projekt mit Tausenden von .java oder .c und sonst was für Dateien ändern Sie in einer Datei ein (wichtiges) Komma und das Ganze (also alle Dateien) zählen eine Nummer höher. Es gibt keinen Versionszähler für die eine gerade geänderte (und "committete") Datei. Als Abhilfe für diesen fundamentalen Mangel und seine Konsequenzen gibt es wohl nur folgende Möglichkeiten: * handgeführte Dateiversionsnummern z.B. in javadoc-Kommentaren also wieder * @version V00.12 (28.06.2005) statt (mit CVS) schon mal *1) * @version V1.1 (Mi, 25.01.2006, 16:42) oder * Die (oft blödsinnige) Unterteilung größerer Projekte in lauter kleine Subversion-Projekte (nur um das gegenseitige "Hochzählen" ein bisschen zu mildern -- das wird so ernsthaft mit genau dieser Begründung in der Subversion-Dokumentation empfohlen). Denken Sie also bei Ihrer Planung daran -- vorher, also bevor mit Subversion-Projekten richtig gearbeitet wird. Die keyword substitution für Revision und Date, wenn für die jeweilige Datei mit svn propset svn:keywords "Date Rev Author Id URL" *.java oder ähnlich eingeschaltet, funktioniert nach wie vor. Date liefert das Datum der letzten Änderung in ähnlich scheußlicher Form wie CVS (aber dafür gibt's ja SVNkeys). Revision liefert aber nun die letzte letzte Gesamtversionsnummer, in der (auch) diese Datei geändert oder zugefügt wurde. 6001 kann also für die Datei von "noch nie" bis "6001 mal geändert" bedeuten. Anmerkung *1): Ändern Sie an dieser Stelle beim Verlassen von CVS wirklich was. Eine Datei-"@version", die ohne Änderung der Datei selbst unkontrolliert "hoch läuft", können Sie sich im javadoc-Kommentar auch gleich ganz "schenken". Dann wäre eine einzige "build"-Nr. in einer zentralen package.html-Datei aussagekräftiger und vor allem nicht verwirrend. (Das wäre unter Subversion eine durchaus erwägenswerte Möglichkeit.) * Zuletzt geändert am §Date: 2005/12/14 14:05:34 § für Gesamt-Bau-Nummer §Revision: 1.1 § würde beispielsweise stimmen (mit $ statt §). Dennoch: Obiges "Alles ist wahr" -- und dieser schlimme Mangel wird ja nicht verschwiegen, sondern als Tugend (neudeutsch "feature") verkauft -- ist i.A. Grund genug, doch den Weg "Subversion statt CVS" zu gehen. Im Übrigen gibt es ein paar absichtliche Ähnlichkeiten, die den Übergang erleichtern. Werkzeuge zur Nacharbeit der ähnlichen keyword substitution, siehe auch http://ai2t.de/java/docs/frame4j/de/frame4j/SVNkeys.html sind auch mit Subversion sinnvoll und einsetzbar. Die offensichtlichen Mängel von CVS (original) und die Funktionsdefizite von SVN kann man mit dem bescheiden "cvsNT" genannten CVS für Windows vermeiden; siehe hierzu auch das Dokument cvsnt-tipp.txt in diesem selben Verzeichnis.