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

ne_proppatch(), issue #1520, dead-end.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-09-13 16:39:35 CEST

Oh crud. Greg and I have been discussing a solution to issue #1520.
Basically, we send a PROPPATCH to change a revision property, and we
get back a 207 response that contains a 500 error internally: "no
revprop hook present." The user never sees the error, a

The problem is that we're using homemade proppatch() code, and it
never checks the body of a 207 response. It assumes 207 ==
SVN_NO_ERROR unconditionally, even if the 207 response contains real
error codes. This is why the 'no-revprop-hook-script' error never gets
propagated back the client, and the client sees a lie: "set svn:log
property".

The obvious thing to do, we thought, was to start using
ne_proppatch(). Presumably it search 207 repsonse bodies for errors.
(Right, Joe?)

So I rewrote svn_ra_dav__do_proppatch() to simply call ne_proppatch().
ne_proppatch() requires an array of 'ne_proppatch_operation'
structures:

typedef struct {
    const ne_propname *name;
    enum {
        ne_propset,
        ne_propremove
    } type;
    const char *value;
} ne_proppatch_operation;

No big deal, really. But I noticed this bit of code in do_setprop(),
which is the helper func responsible for parsing the name/value data
(and is now building operation structures):

  /* If a property is XML-safe, XML-encode it. Else, base64-encode
     it. */
  if (svn_xml_is_xml_safe(value->data, value->len))
    {
      svn_stringbuf_t *xml_esc = NULL;
      svn_xml_escape_cdata_string(&xml_esc, value, pool);
      xml_safe = xml_esc->data;
    }
  else
    {
      const svn_string_t *base64ed = svn_base64_encode_string(value, pool);
      encoding = " V:encoding=\"base64\"";
      xml_safe = base64ed->data;
    }

  ne_buffer_concat(body, "<", xml_tag_name, encoding, ">",
                   xml_safe, "</", xml_tag_name, ">", NULL);

I totally forgot that we potentially have an svn-specific 'encoding'
attribute attached to our property tags:

<D:set>
  <D:prop>
     <C:moo V:encoding="base64">ECAE234D3234AXRCR</C:moo>
  </D:prop>
</D:set>

I don't think there's a way to get this feature using ne_proppatch().
I'm cc'ing Joe -- Joe, is that correct? Is there some clever thing I
can do? We not only need the ability to attach a custom attribute,
but also to have neon declare the xml namespace in the enclosing
<D:propertyupdate> tag.

Maybe this 'encoding' tag is the whole reason we have custom proppatch
code at all? Cmpilato was the one who implemented the custom encoding
feature.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 13 16:40:28 2003

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.