mod_dav question: how to obtain additional client-provided information in db_remove()?

[Daniel Shahaf <d....@daniel.shahaf.name>]

So, I'm looking at teaching ra_dav how to transfer the "expected current
value of a revprop" when editing it.


I started implementing this by extending the PROPPATCH request
(specifically, adding a child to the <D:propertyupdate><D:set><D:prop>
or <D:propertyupdate><D:remove><D:prop> element).

For setting and editing revprops, this seems to be okay: in
mod_dav_svn/deadprops.c:db_store() I get the apr_xml_elem *ELEM
corresponding to D:prop and can use it to access the child I'm adding.
However, for removing revprops, db_remove() (also in deadprops.c) gets only
a dav_db and a const char *propname as arguments.

I've dug in the dav_db structure, and reached as far as
db->resource->info->r (which is a request_rec living under the
dav_resource_private sturct), but I can't find anywhere a way to get a
handle on the XML request body.


And the question:

* How can I teach 'propdel --revprop' to pass an expected (pre-deletion) value
  of the revprop?


Thanks,

Daniel
(yeah, I could just make the client code always go via <D:set> and never via
<D:remove>, but that's ugly isn't it?)

Re: mod_dav question: how to obtain additional client-provided information in db_remove()?

[Daniel Shahaf <d....@daniel.shahaf.name>]

Thanks for the quick response.

C. Michael Pilato wrote on Fri, Jul 30, 2010 at 14:42:03 -0400:
> On 07/30/2010 01:21 PM, Daniel Shahaf wrote:
> > * How can I teach 'propdel --revprop' to pass an expected (pre-deletion) value
> >   of the revprop?
> > 
> > (yeah, I could just make the client code always go via <D:set> and never via
> > <D:remove>, but that's ugly isn't it?)
> 
> Sometimes "ugly" is all we can manage when it comes to mod_dav.  A generic
> DAV client and provider don't have a compelling reason to pass along the
> information you're trying to add here, so I won't come down hard on the
> mod_dav APIs in this case.

In fact, the relevant mod_dav_svn code contains comments indicating that
editing revprops is a violation of DeltaV.

> But the fact of the matter is that they don't give us what we need.  So we
> work around them.  Or we tweak them (and then we still work around them for
> compat).
> 

Okay then; I'll figure out a way to get the information from point A
(svn_ra_{neon,serf}__change_rev_prop()) to point B (svn_repos_fs_change_rev_prop4())
via point C (mod_dav_svn) within the constraints of the existing mod_dav APIs.

Which probably means I'll try routing to-be-atomic revprop removals via db_store().

(I just hope it will work as expected, without breaking in subtle ways due to
mod_dav assumping his providers' db_store() and db_remove() will actually act
within their API-dictated confines.)

> 

Thanks,

Daniel

Re: mod_dav question: how to obtain additional client-provided information in db_remove()?

["C. Michael Pilato" <cm...@collab.net>]

On 07/30/2010 01:21 PM, Daniel Shahaf wrote:
> * How can I teach 'propdel --revprop' to pass an expected (pre-deletion) value
>   of the revprop?
> 
> (yeah, I could just make the client code always go via <D:set> and never via
> <D:remove>, but that's ugly isn't it?)

Sometimes "ugly" is all we can manage when it comes to mod_dav.  A generic
DAV client and provider don't have a compelling reason to pass along the
information you're trying to add here, so I won't come down hard on the
mod_dav APIs in this case.  But the fact of the matter is that they don't
give us what we need.  So we work around them.  Or we tweak them (and then
we still work around them for compat).


-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand