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.