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

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

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 30 Jul 2010 22:38:43 +0300

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
Received on 2010-07-30 21:40:56 CEST

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