Karl,
Karl Fogel wrote:
> This is with r26157 of trunk, in an http:// working copy:
>
> $ svn cp iota iota2
> A iota
> $ svn cp iota2 iota3
> A iota3
> subversion/libsvn_ra_neon/util.c:1279: (apr_err=175007)
> svn: REPORT request failed on '/double-cp/repos/!svn/bc/1/trunk/iota2'
> subversion/libsvn_ra_neon/util.c:543: (apr_err=175007)
> svn: '/double-cp/repos/!svn/bc/1/trunk/iota2' path not found
> $ svn status -q
> A + iota3
> A + iota2
> $
>
> Meanwhile, over svn:// and file:// everything is the same, except
> there's no error. I assume they are getting the intended behavior.
>
I've tried this with a serf trunk build and it works fine for me. Weird
that we don't have a regression test for this simple scenario.
> Is this a known bug? I didn't see anything about it in the issue
> tracker.
>
> By the way, I'd test this with serf too, but even when I configure
> with
>
> --with-serf=/usr/local/serf
>
> ...which points to a r1122 serf install, Subversion still picks up
> libneon and seems to prefer it for http:// access (although it did
> build with serf too).
That's intentional.
> After several recompilations, I've concluded
> that the only way to test serf would be to move all the Neon libraries
> in LD_LIBRARY_PATH off to the side -- which I'm prepared to do, just
> not tonight, because it's late.
>
Or, you could use the new configuration setting to choose ra_serf over
ra_neon.
Extract from the 1.5 release notes:
"Subversion 1.5 allows you to build both modules at the same time; you
can choose which library to use on a global or host-by-host basis by
setting the http-library variable in your run-time server configuration
file (~/.subversion/servers). In recognition of the fact that both
libraries are DAV clients, we have renamed ra_dav to ra_neon."
hth,
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 18 10:01:27 2007