Hyrum K. Wright wrote:
> Justin Erenkrantz wrote:
>
>> On 8/8/07, Hyrum K. Wright <hyrum_wright@mail.utexas.edu> wrote:
>>
> ...
>
>>> explicitly asking for it, but rather the set of checked_in_props. (This
>>> set does *not* contain DAV:href, and I don't know why the initial call
>>> to retrieve_props() succeeds.) When I use all_props instead of
>>> checked_in_props, the DAV:href gets pulled from the cache correctly, and
>>> we don't hit the abort().
>>>
>> Instead of using all_props, I'd just add a new structure to ra_serf.h:
>>
>> static const svn_ra_serf__dav_props_t href_props[] =
>> {
>> { "DAV:", "href" },
>> { NULL }
>> };
>>
>> and use href_props rather than all_props.
>>
>
> I made this change, and it works. However, other calls to
> svn_ra_serf__retrieve_props() are failing with a different message:
> subversion/libsvn_ra_serf/util.c:329: (apr_err=20014)
> svn: Error running context: Internal error
>
> This looks like some kind of error internal to serf itself. In doing
> more digging, it looks to be coming from context.c, around line 870.
> Given that information, I think that this is a bug in serf, not in our
> usage of it. My serf-fu isn't that great, though, so I'm not sure. I'm
> going to commit my patch with Justin's recommended change above, but it
> will generate quite a number of new failures. Anybody with a little bit
> more knowledge care to debug this new problem?
>
Hyrum,
the problem is this:
127.0.0.1 - - [11/Aug/2007:23:28:25 +0200] "PROPFIND HTTP/1.1" 400 326 "-"
The client is doing a PROPFIND request without specifying a URI, hence
it fails with 400 Bad Request. I traced this back to
libsvn_ra_serf/log.c svn_ra_serf__get_log() line 490. The
svn_ra_serf__retrieve_props is called with baseline_url = "". Note
baseline_url is not NULL, that's why svn isn't aborting here.
I didn't look into it any further since it seems to be related to what
you were trying to solve. If you need more info let me know.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 12 00:06:54 2007