Hi Jan, Thanks for your reply I have finally solved this, unfortunately it was not as simple as I hoped (probably due to the fact our platform is on Windows Server).
The point you raised below, gave me a good hint - > - Run a simply svn command like list/info/whatever from a > shell/command box and accept the cert if prompted so. > > So looking at the build output, I could tell that the 'buildnumber' Maven plugin was directly calling svn, so this was outside of Jenkins awareness really. I then realised that Jenkins was running as the 'SYSTEM' user and so that svn command was being executed by the SYSTEM user. Obviously the SYSTEM user needed to accept the server certificate and provide authentication, which it didnt had. I located where svn keeps its auth details for the SYSTEM user on Windows 2008 Server - C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion\auth and I copied in appropriate authentication files to the svn.simple and and svn.ssl.server folders from another account where I knew the build worked. It did now accept the SSL cert but refused to authenticate. So no luck doing that. I then tried a different approach. I re-installed Jenkins making sure that it would run under a custom user account called - "s-subversion" and configured the Windows service appropriately to use that account. When I tried to build the project I had the same issue again, but I could now open a command prompt running as the 's-jenkins' user and execute 'svn up' in the job's workspace, svn then prompted me to accept the server certificate and enter a username and password. After that running the build again in Jenkins now works perfectly. I have added the detail above to try and assist future Windows server users. Thanks
