On Mon, 20 Aug 2007 17:01:40 -0700, Daniel Rall wrote:
> --On August 18, 2007 10:35:27 AM +0200 Lieven Govaerts
> <firstname.lastname@example.org> wrote:
>> Lieven Govaerts wrote:
>>> 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
>>>> 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.
>>> 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
>> 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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Aug 22 11:30:26 2007