[ summary: a question about the ra_dav protocol ]
Daniel Shahaf wrote on Thu, 17 Jun 2010 at 16:21 +0300:
> Philip Martin wrote on Thu, 17 Jun 2010 at 12:18 -0000:
> > Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> > > But I wonder if, while here, we could go further and obtain the
> > > "expected old property value" from the RA layer (and pass it to the pre-
> > > hook). (This probably means revving svn_ra_change_rev_prop() the same
> > > way svn_fs_change_rev_prop() was revved.) That will allow "svn propset
> > > k v --if-old-value-is=vprime" to work...
Before just applying the libsvn_repos change, I'm looking into this.
* ra_local: trivial
* ra_svn: change-rev-prop's tuple may end before the value, so either
a new command or a new capability would be needed.
* ra_dav: I don't know about this one.
From the neon/serf side, adding the optional "expected preexisting
value" should be straightforward (just another tag/attribute).
From the mod_dav_svn side, however, the propchanges/propdeletes come
from db_store/db_remove (respectively), and I don't know/see how
mod_dav_svn could obtain the optional "expected preexisting value"
(even if it were present in the request).
Could someone teach me how mod_dav_svn might be able to obtain the
optional "expected preexisting value"?
> > Perhaps. It would require both client and server upgrades and I don't
> > think there is any way we can provide backward compatibility, so a new
> > client would have to detect old servers and report some not-supported
> > error.
Received on 2010-06-17 18:34:01 CEST