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 <julianf...@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
