> -----Original Message-----
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: donderdag 31 januari 2013 11:56
> To: C. Michael Pilato
> Cc: Julian Foad; Subversion Development; BertHuijben
> Subject: Re: Can we remove DAV-props/WC-props from the code now?
>
> On Thu, Jan 31, 2013 at 12:18 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> > On Wed, Jan 30, 2013 at 10:20 PM, C. Michael Pilato <cmpil...@collab.net>
> wrote:
> >> On 01/30/2013 11:46 AM, Julian Foad 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. "
> >>
> >> libsvn_ra_serf today only interacts with a single DAV prop:
> >> SVN_RA_SERF__WC_CHECKED_IN_URL. That property is...
> >>
> >> ...invalidated:
> >> - during all switch operations.
> >> ...read:
> >> - during non-HTTP-v2, skelta-mode updates.
> >> - during non-HTTP-v2 commits.
> >> ...written:
> >> - during non-HTTP-v2 commits.
> >>
> > It would be great to remove WC props support from all layers in 1.8.
> > They are mostly superseded by other things:
> > - 1.8 client against pre-1.8 server uses non-skelta bulk-mode for updates
> > - 1.8 client and 1.8 server uses HTTPv2
> > - runtime baseline-information cache implemented in svn 1.7 stores
> > information about checked-in URL for revisions. So checked-in URL will
> > be requested only once for each revision during commit to pre-1.7
> > server
> >
> I've tested svn 1.8 commit to svn 1.6 server: disabling wc-props
> results one extra PROPFIND request for each changed file compared to
> wc-props enabled client. I think that one extra request is ok. Users
> should upgrade server if they want performance.
Why this extra request per node?
(Assuming it is an update/checkout)
I would have expected one or a few extra requests total for an update,
unrelated to the amount of changes.
Shouldn't the one-request update get all the information it needs for the nodes
in that request?
Are we still trying to find properties outside that request?
Bert
