You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2013/01/30 17:46:56 UTC
Can we remove DAV-props/WC-props from the code now?
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
Re: Can we remove DAV-props/WC-props from the code now?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Jan 31, 2013 at 3:28 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan@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 <iv...@visualsvn.com> wrote:
>> > On Wed, Jan 30, 2013 at 10:20 PM, C. Michael Pilato <cm...@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)
>
Client request checked-in URL to CHECKOUT proper resource. This
request happens only during commit, not on update/checkout.
--
Ivan Zhakov
RE: Can we remove DAV-props/WC-props from the code now?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan@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 <iv...@visualsvn.com> wrote:
> > On Wed, Jan 30, 2013 at 10:20 PM, C. Michael Pilato <cm...@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
Re: Can we remove DAV-props/WC-props from the code now?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Jan 31, 2013 at 12:18 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Wed, Jan 30, 2013 at 10:20 PM, C. Michael Pilato <cm...@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.
--
Ivan Zhakov
Re: Can we remove DAV-props/WC-props from the code now?
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, Jan 30, 2013 at 10:20 PM, C. Michael Pilato <cm...@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
So I'm +1 to remove WC props completely.
--
Ivan Zhakov
Re: Can we remove DAV-props/WC-props from the code now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Can we remove DAV-props/WC-props from the code now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/31/2013 02:11 PM, Greg Stein wrote:
> 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.
Strictly speaking, a switch will only invalidate WC props if the RA layer's
invalidate_wc_props() RA callback is hook up to the
svn_wc__node_clear_dav_cache_recursive() function (or its pre-WC-NG
manifestations). So, while the docs in svn_props.h do state:
/** WC props are props that are invisible to users: they're generated
* by an RA layer, and stored in secret parts of .svn/.
...it does seem that we effectively we handed WC API users a generic way to
store and retrieve properties for whatever purpose they saw fit. I suppose
it would be a capability breakage to take that functionality away.
> 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.
Yup -- the activity URL.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Can we remove DAV-props/WC-props from the code now?
Posted by Greg Stein <gs...@gmail.com>.
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
<ju...@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