On Sun, Jun 6, 2010 at 15:49, Hirschberg, Benyamin <BHirschberg_at_nds.com> wrote:
> Hi
>
>
>
> I’m stuck with an annoying problem.
>
>
>
> I have an SVN server set up on a LAN server. I’m accessing it with
> http://ada-srp/kr/svn/trunk, it is working from browsers and windows svn
> clients (both Tortoise and command line client 1.6.4).
>
>
>
> The problem is when I’m trying to do a checkout on the server itself
> (ada-srp) with the very same command line command as on the windows machine,
> I’m getting the following error:
>
> [benyamin@ada-srp ~]$ svn checkout http://ada-srp/kr/svn/trunk/ kr_repos
>
> svn: URL 'http://ada-srp/kr/svn/trunk' is malformed or the scheme or host or
> path is missing
>
>
>
> The version of the client is 1.6.5.
>
>
>
> This is not likely to be a networking problem, I can do wget with no problem
> on http://ada-srp/kr/svn/trunk from the same shell. In case of this error I
> don’t see any change in apache log.
>
>
>
> Can you tell me what the problem is?
Have you seen this?:
http://subversion.apache.org/faq.html#unrecognized-url-error
Subversion uses a plugin system to allow access to repositories.
Currently there are three of these plugins: ra_local allows access to
a local repository, ra_neon or ra_serf which allow access to a
repository via WebDAV, and ra_svn allows local or remote access via
the svnserve server. When you attempt to perform an operation in
Subversion, the program tries to dynamically load a plugin based on
the URL scheme. A `file://' URL will try to load ra_local, and an
`http://' URL will try to load ra_neon or ra_serf.
The error you are seeing means that the dynamic linker/loader can't
find the plugins to load. For `http://' access, this normally means
that you have not linked Subversion to neon or serf when compiling it
(check the configure script output and the config.log file for
information about this). It also happens when you build Subversion
with shared libraries, then attempt to run it without first running
'make install'. Another possible cause is that you ran make install,
but the libraries were installed in a location that the dynamic
linker/loader doesn't recognize. Under Linux, you can allow the
linker/loader to find the libraries by adding the library directory to
/etc/ld.so.conf and running ldconfig. If you don't wish to do this, or
you don't have root access, you can also specify the library directory
in the LD_LIBRARY_PATH environment variable.
//Ben
Received on 2010-06-06 21:41:47 CEST