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

Re: revprop changes and hooks

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 17 Jun 2010 19:21:16 +0300 (IDT)

[ 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"?

Thanks!

Daniel

> > 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.
> >
>
> Agreed.
>
>
Received on 2010-06-17 18:34:01 CEST

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.