Posts Tagged ‘SVN’

Freitag, 23. März 2018

Was verändert sich mit meinem nächsten Subversion Checkin?

Der folgende Befehl zeigt analog zu einem diff zwischen zwei Dateien an, welche Änderungen an den lokalen Dateien gegenüber dem letzten versionierten Stand vorgenommen wurden:

$ svn diff -r head

Tags: , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 31. August 2014

Verzeichnis ohne Inhalt in SVN Repository einchecken

In meinem Falle wollte ich ein Cache-Verzeichnis in ein SVN Repository einchecken, ohne die aber in der Zwischenzeit darin abgelegten Cache-Dateien. Nichts leichter als das — SVN sieht auch für diesen Fall eine passende Kommandozeilenoption vor:

$ svn add --depth=empty cache

Via: Add directory structure to SVN, without files

Tags: ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 15. August 2013

libapache2-svn unter Apache 2.4 zum Laufen bringen

Da führt man zu Monatsbeginn auf dem heimischen Linux-Server vor lauter Blödheit ein

# apt-get dist-upgrade

durch und sieht sich plötzlich mit Apache 2.4 konfrontiert.

Nachdem man die Zugriffsprobleme mit IP- und Host-basierten Regeln in allen .htaccess-Dateien behoben hat, realisiert man erst, dass der Web-Server nicht starten will, weil das DAV-Modul „svn“ nicht mehr gefunden wird:

Unknown DAV provider: svn

Was zum Geier?

Die Ursache des Problems ist rasch gefunden: Das Paket libapache2-svn hat eine Abhängigkeit vom Paket apache2.2-common, doch mit Apache 2.4 hat letzteres Paket seine Daseinsberechtigung verloren und ist folglich nicht mehr auf dem System vorhanden. Zu allem Unglück hinzu unterstützt Subversion in der Debian-Version 1.6.17dfsg-4+deb7u3 Apache 2.4 gar nicht.

Nach längerem Herumsuchen im Internet komme ich zum Schluss, dass wirklich nichts an der auf Stackoverflow herumgebotenen Lösung vorbeiführt: Ich muss Subversion doch tatsächlich in der derzeit aktuellen Version 1.7.9 (Debian: 1.7.9-1+nmu3) aus der Quelle kompilieren und danach auf dem System installieren. Diese Version kennt und unterstützt Apache 2.4.

Nachfolgend eine rudimentäre Anleitung, welche sich an den Stackoverflow-Artikel anlehnt.

Anleitung

Zuerst benötigen wir folgende Pakete, um Subversion gegen das aktuell installierte Apache 2.4 kompilieren zu können:

# apt-get install apache2-dev
# apt-get build-dep subversion

Bei mir war anschliessend noch manuell die Installation von folgendem Paket nötig:

# apt-get install libserf1 libserf-dev

Jetzt geht es an das Herunterladen des Subversion-Quellcodes:

$ cd /tmp
$ apt-get source --compile subversion
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
... (Ctrl+C)

Richtig gelesen: Während das Teil vor sich hinkompilieren will, bricht man die Durchführung mittels Ctrl+C ab. Denn zuerst sind noch einige kleinere Anpassungen an den Kompilierungseinstellungen nötig, damit man am Ende nicht nur mit Subversion, sondern auch mit einem Paket libapache2-svn dasteht.

In /tmp/subversion-1.7.9/debian/rules ändert man dazu folgenden Wert:

ENABLE_APACHE        := yes

Und in /tmp/subversion-1.7.9/debian/control fügt man zuunterst folgenden Text ein:

...

Package: libapache2-svn
Section: httpd
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Suggests: db5.1-util
Description: Subversion server modules for Apache
 This package provides the mod_dav_svn and mod_authz_svn modules for
 the Apache 2.2 web server.  These modules provide Subversion's WebDAV
 server backend, to serve repositories over the http and https
 protocols.  See the 'subversion' package for more information.

Schlussendlich startet man die Kompiliererei erneut, verzichtet dieses Mal aber mit dem Attribut DEB_BUILD_CONFIG, dass nach der Kompilierung stundenlang Tests durchgeführt werden, diese scheitern und man nach dem Warten auf Godot ohne .deb-Pakete dasteht (via DEB_BUILD_OPTIONS=nocheck):

$ cd /tmp/subversion-1.7.9/
$ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -b -uc

Anschliessend installiert man die folgenden drei Pakete:

# dpkg -i /tmp/libsvn1_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/libapache2-svn_1.7.9-1+nmu3_i386.deb
# dpkg -i /tmp/subversion_1.7.9-1+nmu3_i386.deb

Schlussendlich muss man in Apache unter /etc/apache2/mods-enabled noch die folgenden Module aus /etc/apache2/mods-available symlinken, wenn sie nicht schon dort sind:

  • authz_svn.load
  • dav_svn.conf
  • dav_svn.load

Dann noch das obligate …

# /etc/init.d/apache2 restart

… und gut is!

Tags: , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 6. März 2013

Wenn Subversion zwar updaten, aber nicht committen kann

Heute habe ich eines meiner Web-Projekte aktualisiert. Ich arbeitete dabei direkt auf dem produktiven Web-Server. Ein svn up klappte problemlos. Doch als ich die direkt auf dem Server neu erstellte robots.txt in das Repository einchecken wolle, kam es zu folgender Fehlermeldung:

$ svn ci -m "robots.txt fehlte"
svn: Commit failed (details follow):
svn: At least one property change failed; repository is unchanged
svn: Server sent unexpected return value (400 Bad Request) in response to PROPPATCH request for '//!svn/wbl/56ef405d-3812-4a6b-a62d-edae457cb0b0/1057'

Die Log-Daten meines Apache-Servers, welcher mittels WebDAV auch den Zugang zum SVN-Repository bereitstellt, vermeldeten folgendes:

access.log:

...
[SOURCE IP] - - [06/Mar/2013:20:08:56 +0100] "OPTIONS /repository HTTP/1.1" 401 772 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:56 +0100] "OPTIONS /repository HTTP/1.1" 200 1039 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:56 +0100] "PROPFIND /repository HTTP/1.1" 207 741 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:56 +0100] "MKACTIVITY /!svn/act/74bcecab-e942-418b-84e4-822ad8581d59 HTTP/1.1" 201 758 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:57 +0100] "CHECKOUT /!svn/vcc/default HTTP/1.1" 201 777 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:57 +0100] "PROPPATCH //!svn/wbl/74bcecab-e942-418b-84e4-822ad8581d59/1058 HTTP/1.1" 400 478 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
[SOURCE IP] - [USER] [06/Mar/2013:20:08:57 +0100] "DELETE /!svn/act/74bcecab-e942-418b-84e4-822ad8581d59 HTTP/1.1" 204 302 "-" "SVN/1.6.17 (r1128011) neon/0.28.2"
...

error.log:

[Wed Mar 06 19:48:10 2013] [error] [client [SOURCE IP]] Digest: uri mismatch -  does not match request-uri 

Unterwegs vom Produktionssystem zum Repository-Server kam es zu einem Problem, in welchem die Domain meines Servers aus der Request-URI entfernt wurde. Ich muss hierbei noch erwähnen, dass zwischen den beiden Servern ein (nicht transparenter) Proxy-Server mit Squid werkelt. Inwiefern dieser Server in den Vorgang gepfuscht hat, kann ich nicht sagen.

Nach langem Pröbeln habe ich es irgendwie hingekriegt. Die Lösung des Problems erscheint mir immer noch mysteriös — aber so sei es wohl manchmal halt: Nachdem ich einerseits folgende zwei Konfigurationsdateien umbenannt …

  • /etc/subversion/servers
  • ~/.subversion/servers

… und andererseits den Inhalt des Verzeichnisses

~/.subversion/auth/

komplett gelöscht hatte, klappte es mit dem Commit plötzlich problemlos.

Eine Vermutung habe ich: Da ich mich seit mehr als einem Jahr nicht mehr auf dem Server eingeloggt hatte, könnten unter auth noch Überreste der damals verwendeten HTTP Basic-Authentifizierung gespeichert gewesen sein. Mittlerweile bin ich auf HTTP Digest-Authentifizierung umgestiegen, um Passwörter im schlimmsten Fall nicht mehr im Klartext über ein öffentliches WiFi zu jagen. Indiz dafür ist, dass ich heute nach der Löschaktion gefragt wurde, ob ich das Passwort im Klartext auf dem Server speichern möchte (was ich abgelehnt habe).

Oder aber eine oder beide Konfigurationsdateien enthielten eine Option, welche die Übertragung der Informationen störte — bspw. der hardkodierte Proxy. Wieso die HTTP-Verbindung zum Repository-Server auch nach der Umbenennung der zwei Konfigurationsdateien weiter funktionierte, ist und bleibt schleierhaft. Wobei, jetzt kommt mir in den Sinn, dass die Admins dieses Netzwerks kurz vor meinem Weggang planten, einen transparenten Proxy einzurichten … Das könnte die Lösung sein.

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. Dezember 2010

Nur mal schnell mein Lizentiat mit SVN branchen …

Da ich mich langsam aber sicher daran machen sollte, meine im Herbst 2009 abgeschlossene Lizentiatsarbeit zu publizieren, nahm ich mir vor einigen Tagen vor, die über SVN versionierten LaTeX-Dateien zu branchen. Dies ist nötig, weil ich für die Publikation deutlich andere Anforderungen an das Format der Arbeit habe als beim Lizentiat.

Aus dem im theoretisch einminütigen Vorgang mit svn copy wurde dann aber leider ein mehrstündiger Installations- und Debuggingmarathon. Etwas, dass in der IT leider viel zu oft vorkommt.

subversion: Versuch 1

Was war geschehen? Zuerst einmal sprach mein unter Mac OS X installierter SVN-Client in der Version 1.4 nicht mehr mit dem mittlerweile auf 1.6 aktualisierten SVN-Server, der unter Debian GNU/Linux installiert ist.

Ein

sudo port install subversion

ging aber fürchterlich schief:

--->  Computing dependencies for subversion
--->  Fetching apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://apache.mirroring.de/apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://www.mirrorservice.org/sites/ftp.apache.org/apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://apache.multidist.com/apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://arn.se.distfiles.macports.org/apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://apache.mirror.rafal.ca/apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://www.ibiblio.org/pub/mirrors/apache/apr
--->  Attempting to fetch apr-1.3.8.tar.bz2 from http://archive.apache.org/dist/apr
--->  Verifying checksum(s) for apr
--->  Extracting apr
--->  Configuring apr
Error: Target org.macports.configure returned: configure failure: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_apr/work/apr-1.3.8" && ./configure --prefix=/opt/local --with-installbuilddir=/opt/local/share/apr-1/build " returned error 77
Command output: checking build system type... powerpc-apple-darwin9.8.0
checking host system type... powerpc-apple-darwin9.8.0
checking target system type... powerpc-apple-darwin9.8.0
Configuring APR library
Platform: powerpc-apple-darwin9.8.0
checking for working mkdir -p... yes
APR Version: 1.3.8
checking for chosen layout... apr
checking for gcc... /usr/bin/gcc-4.0
checking for C compiler default output file name... 
configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_apr/work/apr-1.3.8':
configure: error: C compiler cannot create executables
See `config.log' for more details.

Error: The following dependencies failed to build: apr apr-util db46 sqlite3 readline cyrus-sasl2 openssl neon serf
Error: Status 1 encountered during processing.

XCode

Das Problem war rasch gefunden: Da ich meinen PowerMac G5 vor einigen Wochen von Max OS X 10.4 (Tiger) auf 10.5 (Leopard) aktualisiert hatte, gab es ein Problem mit dem C-Compiler. In Foren wurde empfohlen, XCode auf die neueste Version zu bringen. Ich hatte 2.5 installiert, doch aktuell ist Version 3.

Da ich eine Download-Orgie von Apples ADC-Server verhindern wollte, suchte ich in meinem Software-Ordner nach Installationsmedien für Mac OS X 10.5 — und fand diese tatsächlich. Im Ordner „Optional Installs“ lag dann auch prompt XCode 3 bereit.

subversion: Versuch 2

Nach einer einstündigen Installation von XCode war der Compiler ready. MacPorts stoppte aber beim erneuten

sudo port install subversion

mit einer anderen Fehlermeldung:

--->  Verifying checksum(s) for db46
Error: Checksum (md5) mismatch for patch.4.6.21.1
Error: Checksum (md5) mismatch for patch.4.6.21.2
Error: Checksum (md5) mismatch for patch.4.6.21.3
Error: Checksum (md5) mismatch for patch.4.6.21.4
Error: Target org.macports.checksum returned: Unable to verify file checksums
Log for db46 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_databases_db46/main.log
Error: The following dependencies failed to build: ...
Error: Status 1 encountered during processing.

Der Fehler ist im Netz bekannt. Zu seiner Behebung wurde empfohlen:

If you’re in a terrible rush, then you can do the following:

  1. run port install db46 (which is going to fail)
  2. change dir to where the port command downloaded the stuff (mine is /opt/local/var/macports/distfiles/db4/4.6.21_6)
  3. remove the patches
  4. do:
    for i in 1 2 3 4; do echo $i && wget http://distfiles.macports.org/db4/4.6.21_6/patch.4.6.21.$i; done
  5. run „port install db46“ again

Quelle: db46 – Checksum (md5) mismatch for patch.4.6.21.X

Der angegebene Pfad stimmte bei mir nicht. Und leider konnte ich die Anweisung mit der for-Schleife auch nicht in einer Shell ausführen und musste deshalb die Patches eigenhändig runterladen. Danach konnte subversion und seine Abhängigkeiten aber problemlos kompiliert werden.

svn copy

Nun endlich war ich ready:

svn copy http://repo.tld/lizentiat/ http://repo.tld/publikation/

Dies (und viele andere Aktionen auch, wie bspw. ein simples svn del resultierten in einem Segmentation Fault.

svn serf oder neon?

Wie ich nach einigem googlen herausfand, musste ich die svn-Konfiguration unter /etc/subversion/servers auf dem Debian-Server anpassen:

...
http-library = neon
...

Bis anhin war die verwendete Library serf gewesen.

Anschliessend konnte ich — mit ca. 2-3-stündiger Verspätung — endlich den Branch erzeugen und die ersten Anpassungen am Layout vornehmen.

Tags: , , ,
Labels: Allgemein

Keine Kommentare | neuen Kommentar verfassen

Samstag, 20. Februar 2010

Zugriff auf SVN-Verzeichnisse im Web-Root verhindern

Vor einigen Monaten standen auf unzähligen Web-Sites von professionellen Web-Entwicklern die Tore sperrangelweit offen: Auf Grund der Nachlässigkeit der Entwickler waren deren mit SVN versionierten Projekte statt mit svn export mit svn checkout auf das Produktivsystem ausgecheckt worden — und so gelangten automatisch die .svn-Verzeichnisse mit ins Web-Root.

Da Apache nachlässig konfiguriert war, hatte anschliessend jedermann mit einer klitzekleinen spielerischen Ader Zugriff auf die Struktur und den Source-Code einer jeden so Web-Site. Versuchen wir es gleich mal: Man hänge an die Domain versuchsweise „.svn“ an, wie beispielsweise bei www.stromzukunft.ch/.svn. In diesem Fall ist ein .svn-Ordner vorhanden, weil nicht ein 404er, sondern ein 403er angezeigt wird. Der Server wurde aber glücklicherweise längst gegen solche „Schnupperattacken“ gesichert …

Auch ich gehöre zu jenen Entwicklern, die sich bis zu diesem Zeitpunkt kaum über die „Best Practices“ der Entwicklergemeinde geschert hatten — tatsächlich bin ich auch heute immer noch so faul und verwende oftmals das verpönte svn checkout auf Produktivsystemen.

Um sich dennoch nicht gleich mit heruntergelassenen Hosen im Netz zu präsentieren, sollten solche unbelehrbaren Entwickler immerhin ihre /etc/apache2/apache2.conf anpassen und in dieser den Zugriff auf jedes .svn-Verzeichnis grundsätzlich verwehren:

...
<DirectoryMatch \.svn>
   Order allow,deny
   Deny from all
</DirectoryMatch>
...

Tags: , , ,
Labels: Web

2 Kommentare | neuen Kommentar verfassen

Samstag, 8. August 2009

Auf einen Rutsch alle neuen Dateien ins SVN (svn add)

Selbstverständlich kann man sich streiten, eine Dokuwiki ins SVN zu laden, doch da ich die nächste Woche offline in Frankreich verbringen werde, möchte ich einen einfachen Weg haben, um die an der Côte d’Azur erfassten Änderungen einfach in die Serverinstallation zurückzuspielen.

Doch da ich in der Zwischenzeit noch an einigen Zusammenfassungen weitergeschrieben habe, wurde es nötig, dass ca. 20 neu hinzugekommene Dateien noch ins Repository eingecheckt werden sollten. Wie macht man das möglichst einfach?

Ich habe mich für folgenden Befehl entschieden, den ich im root des versionierten Verzeichnisses ausführte:

svn status | grep "^?" | cut -d ? -f 2 | xargs svn add

Ein

svn add *

ginge natürlich auch, spuckt aber hässliche Fehlermeldungen aus.

Habt ihr einen noch effizienteren Tipp?

Tags: , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Sonntag, 21. Juni 2009

svn streikt mit "could not connect to server"

$ svn up
svn: OPTIONS of 'http://svn.server.tld': could not connect to server (http://svn.server.tld)

Wer dieses Problem urplötzlich unter Debian mit

$ svn --version
svn, version 1.5.6 (r36142)

zu Gesicht kriegt, das Repository im Web-Browser aber problemlos ansurfen kann, muss als einfachsten Workaround die lokale SVN-Konfiguration anpassen (diejenige des Clients, nicht des Servers!):

/etc/subversion/servers

...
[global]
...
http-library = serf
...

Quelle: svn: OPTIONS of ‚http://…‘: could not connect to server (http://…)

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 6. Juni 2009

Dateien von der Versionierung durch SVN ausschliessen

Obwohl ich mich ja generell zu den Apple-Fanboys zähle, warte ich auf den Judgement Day für denjenigen Idioten, der a) anno dazumal die Resource Forks erfunden und denjenigen (wahrscheinlich anderen) Idioten, der b) die Resource Forks auch nach Mac OS X portiert hat.

Dieser Entscheid hat leider schwerwiegende Auswirkungen bis heute, ins Jahre des Herrn 2009. Wenn ich nämlich Verzeichnisse mit SVN versioniere, kämpfe ich regelmässig mit versteckten Dateien, die entweder .DS_Store oder ._<dateiname-einer-im-selben-ordner-liegenden-datei> zu kämpfen habe. Vor allem dann, wenn ich auf Samba-Shares arbeite.

Glücklicherweise hat SVN einen Mechanismus eingebaut, mit welchem solche Fragmente von der Versionierung ausgeschlossen werden können:

$ cd dir/
$ svn propset svn:ignore ".DS_Store" .

Quelle: Preparing a Rails Application for SVN

Verzeichnisse

Selbstverständlich funktioniert die Chose auch mit ganzen Ordnern. Wenn ich in einem unter Versionskontrolle stehenden Projekt ein Verzeichnis habe, dessen Inhalt nicht versioniert werden soll, hilft folgender, ähnlicher Befehl:

$ cd dir/
$ svn propset svn:ignore '*' nicht-zu-versionierendes-verzeichnis/

Quelle: How to … Make Subversion ignore files and folders

Tags: , ,
Labels: Allgemein

Keine Kommentare | neuen Kommentar verfassen

Freitag, 2. Januar 2009

Fremde SVN-Repositories in Projekt integrieren (svn:externals)

Heute war es das erste Mal soweit: svn externals musste her, um eine Web-Applikation aus mehreren eigenständigen Repositories zusammenzusetzen. Glücklicherweise ist das Prozedere nicht wirklich kompliziert.

Ziel ist es in diesem Beispiel unter <svn-root>/inc/classes/ Klassendateien aus einem fremden Repository einzufügen (Das Verzeichnis classes muss dabei nicht bestehen):

  1. $ cd <svn-root>
  2. $ svn propedit svn:externals inc
  3. Es öffnet sich der Editor der Wahl, in welchen man folgende Zeile eingibt:
    classes http://my.repository.com/classes

    Anschliessend speichert man die Änderungen (:w in vim, Ctrl+O in nano) und schliesst den Editor (:q in vim, Ctrl+X in nano)

  4. $ svn update
  5. $ svn ci -m "Added external repository"

Via: svn:externals

Tags: , ,
Labels: Allgemein

1 Kommentar | neuen Kommentar verfassen