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
