Using svn 1.3.2 on Linux, svn checkout fails like this:
joachim@optimist-0 $ svn checkout
http://perfbase.tigris.org/svn/perfbase/trunk perfbase --username guest
Authentication realm: <http://perfbase.tigris.org:80> CollabNet
Subversion Repository
Password for 'guest':
svn: REPORT request failed on '/svn/perfbase/!svn/vcc/default'
svn: REPORT of '/svn/perfbase/!svn/vcc/default': 400 Bad Request
(http://perfbase.tigris.org)
I checked with strace and found this sequence being the culprit:
open("perfbase/.svn/tmp/tempfile.tmp", O_RDWR|O_CREAT|O_EXCL, 0666) = 4
[...]
write(4, "<S:update-report send-all=\"true\"
xmlns:S=\"svn:\"><S:src-path>http://perfbase.tigris.org/svn/perfbase/trunk</S:src-path><S:target-revision>109</S:target-revision><S:entry
rev=\"109\" start-empty=\"true\"></S:entry></S:update-report>", 227) = 227
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
write(3, "REPORT /svn/perfbase/!svn/vcc/default HTTP/1.1\r\nHost:
perfbase.tigris.org\r\nUser-Agent: SVN/1.3.2 (r19776)
neon/0.24.7\r\nConnection: TE\r\nTE: trailers\r\nContent-Length:
0\r\nContent-Type: text/xml\r\nAccept-Encoding: gzip\r\nAccept-Encoding:
gzip\r\nAuthorization: Basic Z3Vlc3Q6\r\n\r\n", 271) = 271
select(4, [3], NULL, NULL, {3600, 0}) = 1 (in [3], left {3599, 785000})
read(3, "HTTP/1.1 400 Bad Request\r\nDate: Tue, 17 Oct 2006 11:08:38
GMT\r\nServer: Apache\r\nContent-Length: 295\r\nConnection:
close\r\nContent-Type: text/html; charset=iso-8859-1\r\n\r\n<!DOCTYPE
HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>400 Bad
Request</title>\n</head><body>\n<h1>Bad Request</h1>\n<p>Y"..., 4096) = 461
This means, svn writes to a file (here, 227 bytes) which in my setup is
mounted via NFS, and checks it's size directly afterwards. NFS returns
an outdated size (0 bytes), which then causes the error when used for
'Content-Length' in the REPORT request.
I know that the root cause is the client-side caching of NFS, but
wouldn't an fsync() after the write() help? Or some locking around the
access? NFS is so widespread for working copy storage that svn should
try to work around such problems (IMHO).
Joachim
--
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 17 14:14:43 2006