Community
Participate
Working Groups
Just had to upgrade our hudson. Checkout is taking an eternity. Our svn server is on the same box as hudson using the apache dav_svn It had worked until we needed svn 1.7, which forced an upgrade. It is running on java 1.6 on centos 5.9 on a vmware instance.
Any hint on how to setup dav_svn, we will try to test on our side
This is our vhost <VirtualHost *:80> ServerName svn.mlogic.be RewriteEngine On <Location /> DAV svn SVNPath /usr/local/subversion/repos/crisp Order deny,allow # Limit write permission to list of valid users. # Require SSL connection for password protection. # SSLRequireSSL AuthType Basic AuthName "Authorization Realm" AuthUserFile /usr/local/subversion/htpasswd AuthGroupFile /usr/local/subversion/group Require valid-user </Location> </VirtualHost>
BTW accessing svn from other svn clients has no problems.
(In reply to Christopher Noyes from comment #3) Two reason I can think of slow checkout - SVN server and Hudson master/slave - Seems SVNKit requires JNA library to work (especially for links). Hudson do come with a JNA plugin. Make sure it is installed and also It is running properly on the slave and no exception from it
We are seeing a similar behavior. Svn update from Hudson slave is extremely slow (30 minutes) whereas from the native command-line client it runs in 10-30 seconds. The checked-out repo branch itself is quite large (ca 8GB). This is a real Linux machine (no VM), the Hudson server is running on some other computer and svn server is on a yet another computer. On other Hudson slaves (Windows, Mac, another Linux) there are no such problems. This is Hudson ver. 2.2.1 and Hudson subversion plugin 2.3.8. The Hudson subversin plugin was recently upgraded from 2.3.2 to 2.3.8, but it was slow already before that (maybe not that slow). According to top, during the time when Hudson 'svn update' is running for 30 minutes, the java process takes about 107% cpu time constantly (this is a Intel(R) Core(TM)2 Duo CPU). buildpc@BuildSLES3:~> uname -a Linux BuildSLES3 2.6.32.12-0.7-default #1 SMP 2010-05-20 11:14:20 +0200 x86_64 x86_64 x86_64 GNU/Linux buildpc@BuildSLES3:~> cat /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 buildpc@BuildSLES3:~> java -version java version "1.6.0" Java(TM) SE Runtime Environment (build pxa6460sr7-20091215_02(SR7)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr7-20091214_49398 (JIT enabled, AOT enabled) J9VM - 20091214_049398 JIT - r9_20091123_13891 GC - 20091111_AA) JCL - 20091202_01 Relaunching the Hudson slave or even restarting the whole Linux box does not help. I can provide other diagnostics or debugging if needed, I just have next to zero knowledge about Java so don't know where and how to look.
We faced this issue as well and finally figured out what the problem was (at least for us). Our Hudson workspace was set up to point to a shared NAS drive. SVN checkouts to that location took forever. We changed it so that the Hudson workspace location was on a local disk (on our CentOS VM) and checkouts were significantly faster. This is something you might want to check in your Hudson environment.
