Subversion
Aus LagoWiki
| Zeile 109: | Zeile 109: | ||
find . \! \( -path *svn* \) -type f -exec rm {} \; | find . \! \( -path *svn* \) -type f -exec rm {} \; | ||
Quelle: [http://codesnippets.joyent.com/posts/show/104 http://codesnippets.joyent.com/posts/show/104] | Quelle: [http://codesnippets.joyent.com/posts/show/104 http://codesnippets.joyent.com/posts/show/104] | ||
| + | |||
| + | ==== Alle .svn Verzeichnisse löschen ==== | ||
| + | rm -rf `find . -name .svn` | ||
=== typo3 und SVN === | === typo3 und SVN === | ||
Aktuelle Version
Inhaltsverzeichnis |
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
Alle .svn Verzeichnisse löschen
rm -rf `find . -name .svn`
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/
