You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@red-bean.com> on 2007/08/18 07:01:35 UTC
Problem with chained 'svn cp' in http:// working copy.
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.
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). 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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> Karl: --with-serf must point to the serf *source* dir, not the
> installation dir. Yes, it's not intuitive.
Thanks (and also to Lieven for his tips on the run-time configuration).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Karl: --with-serf must point to the serf *source* dir, not the
installation dir. Yes, it's not intuitive.
On 8/18/07, Karl Fogel <kf...@red-bean.com> 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.
>
> 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). 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.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
--On August 18, 2007 10:35:27 AM +0200 Lieven Govaerts <sv...@mobsol.be>
wrote:
> Lieven Govaerts wrote:
>> 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.
>>
> Oh, I didn't notice that the copy_tests on the Mac buildslave have been
> failing since r26146. The Mac buildslave runs the tests over ra_neon, so
> you're probably seeing the same issue.
I've temporarily reverted r26146 (in r26175) until I have a chance to
determine where this problem is coming from.
FWIW, I'm getting segfaults from ra_serf, not just errors.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Mon, 20 Aug 2007 17:01:40 -0700, Daniel Rall wrote:
> --On August 18, 2007 10:35:27 AM +0200 Lieven Govaerts
> <sv...@mobsol.be> wrote:
>
>> Lieven Govaerts wrote:
>>> 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.
>>>
>> Oh, I didn't notice that the copy_tests on the Mac buildslave have
>> been
>> failing since r26146. The Mac buildslave runs the tests over
>> ra_neon, so
>> you're probably seeing the same issue.
>
> I've temporarily reverted r26146 (in r26175) until I have a chance to
> determine where this problem is coming from.
>
> FWIW, I'm getting segfaults from ra_serf, not just errors.
Hmm, I -- tried to -- send this email this weekend. Anyways...
I'm getting an abort() from Serf, rather than a segfault. The failures
from both Serf and Neon are due to a request for repository mergeinfo
from the local (uncommitted) copy. The request for repos mergeinfo in
this case should actually be for the copyfrom_path and copyfrom_rev (we
already handle this in the 'merge' case). I've got a patch in progress
to libsvn_client/copy.c to fix this problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Daniel Rall <dl...@finemaltcoding.com>.
--On August 18, 2007 10:35:27 AM +0200 Lieven Govaerts
<sv...@mobsol.be> wrote:
> Lieven Govaerts wrote:
>> 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.
>>
> Oh, I didn't notice that the copy_tests on the Mac buildslave have
> been
> failing since r26146. The Mac buildslave runs the tests over
> ra_neon, so
> you're probably seeing the same issue.
I've temporarily reverted r26146 (in r26175) until I have a chance to
determine where this problem is coming from.
FWIW, I'm getting segfaults from ra_serf, not just errors.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Lieven Govaerts <sv...@mobsol.be>.
Lieven Govaerts wrote:
> 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.
>
Oh, I didn't notice that the copy_tests on the Mac buildslave have been
failing since r26146. The Mac buildslave runs the tests over ra_neon, so
you're probably seeing the same issue.
Lieven
**
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problem with chained 'svn cp' in http:// working copy.
Posted by Lieven Govaerts <sv...@mobsol.be>.
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