Subversion

Aus LagoWiki

Version vom 19:11, 26. Jan. 2011

SVN

• Pfad (Konfiguration): /etc/apache2/mods-available/dav_svn.conf

Auskommentiert:

• DAV svn
• SVNPath /home/svn

...für die SVN's in dem File: (einfach unter die vorhandenen Zeilen kopieren)

 #lp_added
 <Location /svn/testprojekt1>
    DAV svn
    SVNPath /home/svn/testprojekt1
    AuthType Basic
    AuthName "testprojekt1 subversion repository"
    AuthUserFile /etc/subversion/passwd
    <LimitExcept GET PROPFIND OPTIONS REPORT>
       Require valid-user
    </LimitExcept>
 </Location>

Wenn man die Zeilen

###    <LimitExcept GET PROPFIND OPTIONS REPORT>
###    </LimitExcept>

auskommentiert, dann braucht man zum lesen auch ein Passwort.

User, bzw. deren Passwörter anlegen:

Für den ersten User (-c erstellt/überschreibt eine neue Datei) 
 htpasswd -c /etc/subversion/passwd [user]
Für die nächsten User 
 htpasswd -s /etc/subversion/passwd [user]

Installation

• apt-get install subversion-helper-scripts subversion-tools
• apt-get install libapache2-svn
• apt-get install subversion

Repositorys anlegen

• svnadmin create [Projektname] (legt im aktuellen Verzeichnis die Dateienstruktur an) oder
  • mit svnadmin create [pfad_zum_repository] das repository anlegen
• im File /etc/apache2/mods-available/dav_svn.conf das Projekt (Location) anlegen
• die Zugriffsrechte auf den Benutzer anpassen (chown -R www-data * bzw. chmod -R 775 * im Verzeichnis des neuen Projekts)
• Serverneustart nicht vergessen

Subversion mit xCode

http://theappleblog.com/2008/04/28/using-subversion-with-xcode-30/

Upgrade von Subversion 1.4.6 auf 1.5.1 auf Ubuntu hardy haron (V 8.04)

Um das mergetracking benutzen zu können ist, eine subersion-Version größer als 1.5 erforderlich. Auf unserem Server läuft Ubuntu Hardy Heron (V8.04). In dieser Distribution ist eben nur subversion 1.4.6 enthalten. Um auf die Version 1.5.1 upzugraden, muss man hardy-backports als Quelle verwenden. Und das funktioniert so:

• In der Datei /etc/apt/sources.list wird hardy-backports hinzugefügt:

deb http://de.archive.ubuntu.com/ubuntu hardy-backports main

• In der Datei /etc/apt/preferences wird hardy-backports auf eine niedrigere Priorität gesetzt (mann muss dann immer mit dem Schalter -t und dem Komando hardy-backports angeben, dass man von dort installieren will:

Package: *
Pin: release a=hardy-backports
Pin-Priority: 400

• die Quellen updaten (sonst findet er die neue Version nicht):

apt-get update

• Jetzt wird Subversion 1.5.1 installiert (als sudo oder root):

apt-get -t hardy-backports install subversion

• Wie oben beschrieben die Repositorys konigurieren, bzw. neu einrichten.
• Jetzt lief es bei mir NICHT - und das lag daran, dass der Webserver noch die alte Datei /usr/lib/apache2/modules/mod_dav_svn.so verwendete. Das merkt man daran, dass der Webserver noch ...Powerd by subversion version 1.4.6... anzeigt.
• Abhilfe schafft folgendes:

apt-get install --reinstall -t hardy-backports libapache2-svn

(ich hatte vorher die alte Datei /usr/lib/apache2/modules/mod_dav_svn.so in /usr/lib/apache2/modules/mod_dav_svn.so.old umbenannt)

• Webserver neu starten mit

/etc/init.d/apache2 restart

• Zur Kontrolle das Web-Frontend aufrufen, dort sollte jetzt ...Powerd by subversion version 1.5.1... stehen.

Siehe auch: http://ubuntuforums.org/showthread.php?p=5683172

Automatische Backup des SVN Repositorys

Folgendes Backup-Script erzeugt ein SVN-Dump, packt es per gzip und schiebt es auf einen ftp-Backup-Server. Die Dateinamen werden mit dem Wochentag versehen. Lässt man es per Chronjob (an verschiedenen Wochentagen) aufrufen, hat man stets so viele Backups, so oft es aufgerufen werden, nie jedoch mehr als sieben (Tage in der Woche). Die alten werden beim erzeugen eines neuen überschrieben.

#!/bin/bash
dayofweek=`date '+%A'`

# svn dumpen
svnadmin dump /home/svn/repositoryname > repositoryname.$dayofweek.svndump

# datei packen
gzip -f repositoryname.$dayofweek.svndump

#auf den FTP-Server uebertragen: per ftp (curl)
curl -T repositoryname.$dayofweek.svndump.gz ftp://username:passwort@storageserver.com/verzeichnis/repositoryname.$dayofweek.svndump.gz

# lokales File loeschen
rm repositoryname.$dayofweek.svndump.gz

Mittels des Eintrags

0	1	*	*	2,4,6	/root/svndump-backup.sh >/dev/null 2>&1

in die Chrontab wird das Script am Dienstag, Donnerstag und Samstag jeweils um 1:00 Uhr ausgeführt.

Anleitung zu curl: http://curl.haxx.se/docs/manual.html

Zurückspielen eines SVN-Dumps

Um einen SVN-Dump wieder auf den Server zu spielen, legt man zuerst ein repositiory an (siehe oben). Dann wird mittels load das Dubmpfile eingespielt

svnadmin load repository-name < repositoryname.svndump

Quelle: http://www.digitalmediaminute.com/article/2251/how-to-move-a-subversion-repository

Nützliche Befehle

Rekursiv alle Dateien die nicht unter Versionskontrolle sind hinzufügen

svn status | grep "^\?" | awk '{print $2}' | xargs svn add

Quelle: http://snipplr.com/view/5745/svn-add-recursively/

Rekursiv alle Dateien löschen jedoch NICHT die .svn Verzeichnisse

Updatet man in typo3 eine Extension, die sich unter Versionskontrolle befindet, wird zuerst das Verzeichnis gelöscht (!) um es anschließend wieder komplett neu an zu legen. Es werden auch alle .svn-Verzeichnisse gelöscht. Das hat zur folge, dass die neue Extension weder eingecheckt noch sonst irgendwie mit Subversion verarbeitet werden kann. Löscht man jedoch alle Dateien, ohne die .svn-Verszeichnisse zu löschen, kann man die neuen Dateien von einer anderen Stelle aus (z.B. per FTP) in diese Verzeichnisse kopieren und diese dann in das Repository einchecken.

find . \! \( -path *svn* \) -type f -exec rm {} \;

Quelle: http://codesnippets.joyent.com/posts/show/104

typo3 und SVN

Extensions in SVN updaten die im Backend geändert wurden

Wird in Typo3 eine Extension geupdated, wird das gesamte Verzeichnis vom www-Benutzer gelöscht - also auch die .svn-Dateien. Dieses produziert Fehler der Form˝ Server sent unexpected return value (405 Method Not Allowed) in response to MKCOL request for ... oder so was in der Art. Völlig ausgeschlossen, dass man es "subversion-style" (also nur die Änderungen) einchecken kann, auch wenn die Verzeichnisse und Dateien gleich oder ähnlich sind. Mittels ein paar Tricks kann man es jedoch dennoch bewerkstelligen, dass es funktioniert:

• Das Exteinsonverzeichnis (nennen wir es mal extensionverzeichnis) löschen mittels rm -r extensionverzeichnis
• Mittels des Backends die Extension installieren bzw. die gewünschte Version einspielen.
• Das Extension Verzeichnis umbenennen in z.g. extensionverzeichnis.tempFromRepository oder ähnlich
• Mit svn up extensionverzeichnis das "alte" Extensionverzeichnis wieder aus dem Repository laden.
• Mittels des Befehls find . \! \( -path *svn* \) -type f -exec rm {} \; alle Dateien in dem Extension Verzeichnis löschen, nicht jedoch die .svn-Dateien.
• Jetzt kommt der Trick: -> In das Verzeichnis extensionverzeichnis wechslen und mittels rsync-Befehl die neuen Dateien in dieses "geleerte" alte (unter Subversion verwaltete Verzeichnis) "reinsyncronisieren". Hier der Befehl dazu: rsync -av --stats ../extensionverzeichnis.tempFromRepository/* .
• Jetzt kann ganz normal mit den Befehlen svn add, svn commit, svn del und svn stat gearbeitet werden.

Hab's auch ins Forum gepostet unter: http://www.typo3.net/forum/beitraege/sonstiges-1/88691/