Hiya, looks like the SCM server does either not know your machine/user or the authentication method is not supported. have you tried to access the server via plink and stored the finger print? I assume you are using https. So try this: - install plink (e.g. from PuTTy) - open a shell/DOS box - enter plink -l [username] -i [path_to_private_key (optional)]
This should open a connection to the server and a dialog should pop up that tells you about an unknown fingerprint and asks you to save it (select permamently). The server on the other hand should then also know by then that user/key is valid. Obstracle may be if the user is new and the server is set up very restrictive. This would eventually require that an admin manually adds the user/key pair. If using windows: check for x:\Documents and Settings\[profile_name] \Application Data\Subversion. Take a look at the files servers and config. It can be tricky to apply the credentials in case you are using a service user. Easiest way would be to access svn with the svn client and use the credentials of the service user. They should be stored in the sub-folder auth and copy it to x:\Documents and Settings\ [service_user_name]\Application Data\Subversion. The problem is that each SVN client uses a different location to store the credentials. TortoiseSVN uses the registry, the Collabnet client uses x:\Documents and Settings\[profile_name]\Application Data \Subversion, Eclipse stores the credentials in [workspace_name] \.metadata and so on. You can have two identically installed machines. It works on one, on the other not. The reason could then be that 2 or more svn clients/ connectors are installed but in different order. the working machine looks for x:\Documents and Settings\[profile_name]\Application Data \Subversion the non-working for the registry as Tortoise on the latter machine was installed after Subversion. This can become a serious hassle. I would suggest that you download Systernals ProcMon and trace the processes to see which location/tool is used to authenticate. this may be the quickest way if the plink approach does not work. Good luck Jan On 15 Mrz., 11:45, Javy <[email protected]> wrote: > Hi.. > > Posting here after going through similar questions and suggested > solutions ( which did not seem to work in my case ). > > Summary of my problem: > - Running Hudson as Windows service ( Hudson 2.1.2, Windows 7 > Professional ) > - While creating Job, I specify Subversion as the code source > --- After specifying the URL, the red text "update credentials" > appear > --- clicking that takes me to the same URL as does > http://<host>/scm/SubversionScm/enterCredential page > --- I enter the username/password, and it says "successfully > authenicated...hudson will now store this information.." > ----- Note that I had entered the http-proxy-host and http-proxy-port > details under the hudson\.subversion\servers file, and only then it > was successfully able to authenticate here. > - After filing in the rest of the details required for the Job to be > created, I click save and then trigger a "build now" > - Seems Hudson dint pick the stored ( successful ) configuration, > because it fails as below: > Mar 15, 2012 2:57:46 PM hudson.scm.SubversionSCM$DescriptorImpl > doCheckRemote > INFO: Failed to access subversion repositoryhttps://xxx.yyy.com/path1/path2/ > org.tmatesoft.svn.core.SVNException: svn: connection refused by the > server > svn: OPTIONS request failed on '/rg0101/hpn-netmgmt/branches/cpe/ > 04.00.xx' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java: > 106) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java: > 90) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java: > 629) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java: > 275) > at > org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java: > 263) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java: > 516) > at > org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java: > 98) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java: > 1001) > at > org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java: > 97) > at hudson.scm.SubversionSCM > $DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1948) > at hudson.scm.SubversionSCM > $DescriptorImpl.doCheckRemote(SubversionSCM.java:1879) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: > 39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: > 25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.kohsuke.stapler.Function > $InstanceFunction.invoke(Function.java:282) > > --- Solutions tried already: > ------ Installed SVN client and did interaction with the repsository, > so that authetication data is saved locally > ------ restart hudson after specifying the credentials and before > starting job > ------ reload hudson configurations > ------ downgrading hudson jar version. > > Can somone help please : tried out various solutions already posted in > the forums but none seem to work > Would really appreciate and owe GREAT Thanks if someone can pull me > out of this mess...:| > > Thanks > ~Ja
