I am getting the following errors when I try to do a "svn list" from the
Subversion command-line client to a Subversion HTTP server.
X:\>svn list http://206.88.41.70/svn/posse_j2ee
svn: PROPFIND request failed on '/svn/posse_j2ee/!svn/bc/19'
svn: PROPFIND of '/svn/posse_j2ee/!svn/bc/19': timed out waiting for server
(http://206.88.41.70)
The same thing happens when I try using the client locally:
[svn_at_localhost svn]$ svn list http://127.0.0.1/svn/posse_j2ee
svn: PROPFIND request failed on '/svn/posse_j2ee/!svn/bc/19'
svn: PROPFIND of '/svn/posse_j2ee/!svn/bc/19': timed out waiting for server
(http://127.0.0.1)
Here are the known factors:
- This happens with a large SVN repository (6,789 files). It does not happen
with a trivial repository of several files.
- This happens only when accessing the repository through the Apache
mod_dav_svn module. I have had no problems using svnserve.
- The TortiseSVN 1.1.0 and RapidSVN 0.7.0 clients exhibit the same problem
when attempting to browse the repository (the equivalent of an "svn list").
- Functions other than "svn list" work just fine. For example, I am able to
authenticate to the server, check out, update, commit and view logs through
any of the clients mentioned.
- I can browse the repository successfully over mod_dav_svn using a web
browser.
- I have set up Subversion servers on two different hosts under two
different Linux distributions on two different networks and have connected
both locally and over the Internet. No difference in the results.
- Both the server and client machines show trivial CPU load during the
attempt. The networks have been similarly unburdened.
- Just for fun, I ran "svn recover", but still get the same results.
The Apache error_log file does not show any errors, only the notices that it
puts out when the server starts. The Apache access_log is similarly
unhelpful:
"PROPFIND /svn/posse_j2ee HTTP/1.1" 401 481 "-" "SVN/1.0.9 (r11378)
neon/0.24.7"
"PROPFIND /svn/posse_j2ee HTTP/1.1" 207 659 "-" "SVN/1.0.9 (r11378)
neon/0.24.7"
"PROPFIND /svn/posse_j2ee/!svn/vcc/default HTTP/1.1" 207 411 "-" "SVN/1.0.9
(r11378) neon/0.24.7"
"PROPFIND /svn/posse_j2ee/!svn/bln/19 HTTP/1.1" 207 464 "-" "SVN/1.0.9
(r11378) neon/0.24.7"
"PROPFIND /svn/posse_j2ee HTTP/1.1" 207 659 "-" "SVN/1.0.9 (r11378)
neon/0.24.7"
"PROPFIND /svn/posse_j2ee/!svn/vcc/default HTTP/1.1" 207 464 "-" "SVN/1.0.9
(r11378) neon/0.24.7"
"PROPFIND /svn/posse_j2ee/!svn/bc/19 HTTP/1.1" 207 670 "-" "SVN/1.0.9
(r11378) neon/0.24.7"
"PROPFIND /svn/posse_j2ee HTTP/1.1" 207 659 "-" "SVN/1.0.9 (r11378)
neon/0.24.7"
"PROPFIND /svn/posse_j2ee/!svn/vcc/default HTTP/1.1" 207 464 "-" "SVN/1.0.9
(r11378) neon/0.24.7"
I am currently using the following relevant packages under Fedora Core 2:
subversion-1.0.8-1, httpd-2.0.51-2.7, mod_dav_svn-1.0.8-1.
I am setting up the Apache HTTP server to access the repository as follows:
/etc/httpd/conf.d/subversion.conf
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
<Location /svn>
DAV svn
SVNParentPath /var/svn
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /etc/svn-auth-file
Require valid-user
</Location>
On Debian, I set up these entries directly in the httpd.conf file. I also
tried it without the authentication entries (AuthType, AuthName,
AuthUserFile and Require). I also tried directly referencing the repository:
<Location /posse_j2ee>
DAV svn
SVNPath /var/svn/posse_j2ee
</Location>
I have done numerous searches through Google and this mailing list, but
haven't found anything helpful. I could just use svnserve, but this is
really bugging me. Darn it all, I'm ENTITLED to use HTTP (shaking fist at
sky)!
Has anyone else experienced this problem? Does anyone have any suggestions?
Thanks
_
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
Received on Mon Nov 1 20:45:36 2004