[ 
https://issues.apache.org/jira/browse/SVN-4228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Zhakov updated SVN-4228:
-----------------------------
    Fix Version/s:     (was: blue-sky)
                   1.8.0

> Consider sending per-directory, depth:1 PROPFINDs during ra_serf update 
> handling
> --------------------------------------------------------------------------------
>
>                 Key: SVN-4228
>                 URL: https://issues.apache.org/jira/browse/SVN-4228
>             Project: Subversion
>          Issue Type: Improvement
>          Components: libsvn_ra_serf
>    Affects Versions: 1.7.x
>            Reporter: C. Michael Pilato
>            Assignee: Greg Stein
>            Priority: Minor
>             Fix For: 1.8.0
>
>
> {noformat:nopanel=true}
> This idea is forked from issue #4173.
> The general complaint was that, when performing a checkout or any update
> operation which is adding new nodes, pre-1.8 ra_serf would turnaround with a
> server PROPFIND to fetch the properties on the new nodes.  For a checkout, 
> this
> meant issuing a PROPFIND per node in the tree.  It was suggested that perhaps
> the client could issue a Depth:1 PROPFIND for each directory instead, caching
> the results on the client-side so that the properties retrieved for immediate
> children of the directory wouldn't have to be separately fetched.
> Note that, per issue #4173, ra_serf in 1.8 will no longer issue PROPFINDs at 
> all
> against a 1.8 server.  So this optimization would only make sense when
> communicating against and older server.
> Note also that this optimization is not without its costs, both in terms of 
> code
> complexity and, oddly enough, real inefficiency in situations where the set of
> added items is small, but the PROPFINDs needed to fill in the details for 
> those
> things are quite large (say, a single added file within a directory that has
> hundreds of heavily-propertied sibling files).
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to