You're welcome :) I have been face-palming and whacking my head into the desk for several hours to crack this issue. Some few hours more went through the sandglass as I had an idea what was going on, traced it with procmon and then fixed it. That is a cookie nobody wants to eat ;)
On 17 Mrz., 05:48, Javy <j...@hp.com> wrote: > Hi Jan Seidel > > Thanks a TON. > > Your suggestion helped - I used it with combination of other solutions > and finally got over this irritant troubling me from past 2 days. > > This is what I did ( just in case someone else falls into same trap > and figuring out how to get out :) > Uninstalled Hudson and erased all registery entries ( through > cleanup ) > 1) Installed Tortoise SVN ( it also installs the command line tools ) > 2) Tried a simple checkout from the SVN repository using the command > line > svn checkouthttps://xxx.x.x.x./deepfolderpath/. > ( choose folder having like 1 or two files ) > 3) It prompted for accepting certificate permanently ( since > connecting first time ) and asked to provide the > logged-in windows account password, SVN account username/password > 4) Once the checkout from commandline was successful, installed Hudson > 2.1.2 afresh and installed it as service > 5) Setup configuration and specified SVN repository -- and restarted > hudson > > ...and BINGO...hudson was successfully able to take the credentials as > part of build process. > > SO PROBLEM SOLVED!. > > Thanks again for your time on this - its amazing how you could make > impact on others by lending such helping hand! > > Thanks jan again! > > On Mar 15, 4:46 pm, Jan Seidel <wakkal...@gmail.com> wrote: > > > > > > > > > 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 <j...@hp.com> 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- Hide quoted text - > > > - Show quoted text -