It seems likely that to resolve the externals, svn needs credentials for the US instance.
You may be able to resolve this by logging into the o/s as the user which does the checkout, and doing any checkout from the US svn. You should be prompted to enter credentials, and svn will cache them in ~/.subversion/auth/svn.simple. If you look in this location now you will probably see a file containing credentials for the Germany instance, and after having done a checkout from the US instance you should see an additional file. Good luck Brian On 21 June 2012 10:55, phil swenson <phil.swen...@gmail.com> wrote: > I guess I didn't explain very well. I am setting up a job on a new > Jenkins server that points to a particular SVN Url. This SVN repo has > several externals. The job runs on one specific node that is in > Germany, but the Jenkins Server and the SVN repo are both in the US > (not sure if that could matter, but they are in different windows > domains). > > When the job executes, it checks out code from SVN and is successful > the code in the main repo, but fails to sync the externals "(Caused > by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No > >> credential to try. Authentication failed)" > > We have a similar setup (all US) that works fine. > > Does that explain the situation any better? > > thanks > phil > > > > On Thu, Jun 21, 2012 at 2:03 AM, Neil Bird <n...@fnxweb.com> wrote: > > Around about 21/06/12 00:36, phil swenson typed ... > > > >> I am setting up a new jenkins server and am running into a problem. > >> when synching my svn repo I get this error on the externals: > >> > >> Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No > >> credential to try. Authentication failed > > > > > > What exactly are you doing? > > > > I had a similar issue on our server when using websvn+https with a repo > > that has externals. The access to the repo. was authenticated as normal > > from the client, but websvn then uses the command line on the server to > do > > some things (like deliver ZIPs) and *that* was failing when trying to > check > > out externals (access to the repo itself is direct via file:, but the > > externals were being fetched “properly” with https: URLs). > > > > I had to add access (and include certificate acceptance) to the server's > > user. > > > > Or it was something along those lines, it was a while ago. > > > > -- > > [neil@fnx ~]# rm -f .signature > > [neil@fnx ~]# ls -l .signature > > ls: .signature: No such file or directory > > [neil@fnx ~]# exit > > > > >
