[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: serf property caching

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: 2007-08-12 00:12:01 CEST

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?

the problem is this: - - [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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.