Yay!
And thank you very much for your excellent turn-around time.
OK, time to release 1.76...
Eric Crahen wrote:
I just gave it a try and there was no trouble this time.
On 1/25/07, Kohsuke Kawaguchi <Kohsuke.Kawaguchi@xxxxxxx> wrote:
Thanks. I think I know what's going on.
Code that registers the protocol handler (the ones that understands http
https, svn, etc) needs to be registered before svnkit works
successfully, and yet I suspect it's not run at the right moment.
From looking at svnkit source code, it should understand your URL just
fine.
Continuous build #2124 should have a fix for this. If you can try that,
that would be really appreciated.
Eric Crahen wrote:
> I expanded the show details link and I got this,
>
>
> org.tmatesoft.svn.core.SVNException: svn: Unable to create
> SVNRepository object for 'https://myserver/svn/myproject'
> at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(
SVNErrorManager.java:48)
> at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(
SVNRepositoryFactory.java:194)
> at org.tmatesoft.svn.core.io.SVNRepositoryFactory.create(
SVNRepositoryFactory.java:143)
> at hudson.scm.SubversionSCM$DescriptorImpl$1.check(
SubversionSCM.java:597)
> at hudson.util.FormFieldValidator.process(FormFieldValidator.java
:33)
> at hudson.scm.SubversionSCM$DescriptorImpl.doAuthenticationCheck(
SubversionSCM.java:588)
> 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:50)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:59)
> at org.kohsuke.stapler.NameBasedDispatcher.dispatch(
NameBasedDispatcher.java:30)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
> at org.kohsuke.stapler.MetaClass$9.doDispatch(MetaClass.java:207)
> at org.kohsuke.stapler.NameBasedDispatcher.dispatch(
NameBasedDispatcher.java:30)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:224)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:169)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at org.mortbay.jetty.servlet.ServletHolder.handle(
ServletHolder.java:491)
> at org.mortbay.jetty.servlet.ServletHandler.handle(
ServletHandler.java:367)
> at org.mortbay.jetty.security.SecurityHandler.handle(
SecurityHandler.java:185)
> at org.mortbay.jetty.servlet.SessionHandler.handle(
SessionHandler.java:181)
> at org.mortbay.jetty.handler.ContextHandler.handle(
ContextHandler.java:689)
> at org.mortbay.jetty.webapp.WebAppContext.handle(
WebAppContext.java:391)
> at org.mortbay.jetty.handler.ContextHandlerCollection.handle(
ContextHandlerCollection.java:146)
> at org.mortbay.jetty.handler.HandlerCollection.handle(
HandlerCollection.java:114)
> at org.mortbay.jetty.handler.HandlerWrapper.handle(
HandlerWrapper.java:139)
> at org.mortbay.jetty.Server.handle(Server.java:285)
> at org.mortbay.jetty.HttpConnection.handleRequest(
HttpConnection.java:457)
> at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(
HttpConnection.java:751)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java
:209)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java
:357)
> at org.mortbay.io.nio.SelectChannelEndPoint.run(
SelectChannelEndPoint.java:329)
> at org.mortbay.thread.BoundedThreadPool$PoolThread.run(
BoundedThreadPool.java:475)
>
>
>
> On 1/25/07, Kohsuke Kawaguchi <Kohsuke.Kawaguchi@xxxxxxx> wrote:
>>
>>
>> Hi, I updated the issue 245. If you can try the latest snapshot and let
>> me know what error you get, that would be really helpful.
>>
>> Eric Crahen wrote:
>> > I have some questions on the new SVNKit integration.
>> >
>> > #1) Connection Error?
>> >
>> > I upgraded from using an external svn binary in hudson 1.6.8, to
hudson
>> > version 1.75 which uses SVNKit. When I create a new project and place
my
>> svn
>> > url in the field, I an given the following error.
>> >
>> > "Unable to access http://myserver/svn/myproject : svn: Unable to
create
>> > SVNRepository object for 'http://myserver/svn/myproject' (Maybe you
>> > need to enter
>> > credential<
>>
http://localhost:8080/hudson/scm/SubversionSCM/enterCredential?http://myserver/svn/myproject
>> >
>> > ?)"
>> >
>> > I was previously able to access this URL with my external client. I'm
>> not
>> > sure what when wrong, I looked at stdout, I looked in my servlet
>> container
>> > logs and I checked the "Manage Hudson" system log and I did not find
any
>> > output that would help me understand the error. There is no
credential
>> > required to check out of this respository, anonymous access is
perfectly
>> OK.
>> >
>> > What can I do to find the source of the error? Is there a way to make
>> the
>> > real error more obvious to the user? (I think SVNKit must have
produced
>> some
>> > sort of useful error message we could use.)
>> >
>> > #2) Trust?
>> >
>> > Another thing I have a question about is how can I provide SVNKit
with
>> the
>> > set of certificates I trust? My repository requires an SSL login in
>> order to
>> > perform updates, which I would want to do after the fact tagging. My
>> > repository uses a self-signed certificate which is not going to
trusted
>> > without extra work. The way I told my svn binary to trust my servers
>> > certificate was by first using the user account I ran hudson as to do
>> an:
>> >
>> > svn https://myserver/svn/myproject
>> >
>> > This would cause the svn binary to prompt me that this server has a
>> > self-signed cert and asks me if I should trust it. I would select yes
>> > permanently and svn would save some info in ~/.subversion to say
trust
>> this
>> > certificate. Later when I used hudson, I ran svn as the user and svn
>> > remebered to trust this server because of the data in ~/.subversion
>> >
>> > With the SVNKit integration, its not immediately obvious to me how to
>> > associate a trusted certificate with an SVN connection. I suppose one
>> method
>> > would be to manually create a jks trust store and run hudson with the
>> > correct -Djavax.net.ssl.trustStore, -
>> Djavax.net.ssl.trustStorePasswordoptions.
>> >
>> > Since I haven't gotten past my first problem I can't confirm this
works,
>> but
>> > it ought to.
>> >
>> >
>> > #3) Username / Password the only credential?
>> >
>> > I can also configure my subversion repository to use SSL client
>> > identification as a credential, instead of or along with user/name
>> password.
>> > I'm not doing this, but it would be an interesting thing for the TODO
>> list.
>> >
>> >
>>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems kohsuke.kawaguchi@xxxxxxx
>>
>>
>>
>
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi@xxxxxxx
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi@xxxxxxx
smime.p7s
Description: S/MIME Cryptographic Signature
| 