For API compatibility purposes... no, they cannot be removed.
We renamed them to "dav_cache", but the original APIs called them "WC
props" and never stated they might disappear.
Unless you can find something that says they will disappear (as Mike
noted, a switch will invalidate them), then an API user is going to
expect to get/set those properties just like any others.
And yes, the RA code has always been able to work without them. As
Ivan notes, we cache a URL for each resource to avoid a PROPFIND at
commit time. A long time ago, we stored a second WC prop, but I forget
what it was.
Cheers,
-g
On Wed, Jan 30, 2013 at 11:46 AM, Julian Foad
<julianfoad_at_btopenworld.com> wrote:
> It would be awesome if we can now completely remove the code supporting 'DAV props' aka 'WC props' in the client side, if it is no longer needed there.
>
> I know little about it myself, but on IRC, Bert said [1]:
>
> "I would hope we can ignore WC/DAV props. And if somebody suggests it I would be +1 on removing them now completely from our client. (The skelta update in serf for old style servers makes them unnecessary).
>
> I think the reason to keep them was serf without http v2, but that should be fixed.
> Using a subversion 1.0 server (pre skelta) would get slower, but I don't think anybody cares about that.
>
> It still works ok.
>
> The repository diff already makes sure dav props won't show up during merge. (I think since 1.7)
>
> Dav props should nowdays only be written by the update editor, and read by some callback api that is initialized with ra sessions.
> "
>
> - Julian
>
>
> [1] Logged at <http://colabti.org/irclogger/irclogger_log/svn-dev?date=2013-01-30#l458>.
>
> --
> Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Received on 2013-01-31 20:12:06 CET