[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: changing the checkout process

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-05-15 23:52:46 CEST

On Thu, May 15, 2003 at 07:28:57PM +0200, Branko ??ibej wrote:
> Ben Collins-Sussman wrote:
>...
> >Any thoughts?
>
> What happens to memory usage on the server? Does it have to keep a delta
> of the whole tree in memory, or is that representatino optimal (e.g.,
> WRT single-rev subdirectories).

We stream the update report. The memory on the server should be fine.

The ra_dav library has some issues with sending PROPFIND requests, but we
covered that last week. The basic story is this:

* during checkout, we (erroneously) send a PROPFIND for each item fetched,
  rather than using the props from the Depth:1 result for the parent
  directory.

* switching to the update process for checkout means that we will send a
  PROPFIND for each item fetched. same as current, but *not* the same as the
  theoretical "best" that the checkout code could do.

* in a second change, we modify the update processing to recognize that
  "add-directory" implies all the children will be added, too. thus, we
  should do a PROPFIND for Depth:1 and hold those props around for the
  directory and all the children. thus, we return to the theoretical "best"
  PROPFIND usage for a checkout. secondary effect is better PROPFIND usage
  during an update which adds directories.

(we still have server issues around PROPFIND on large dirs (iz#773), but
 that isn't affected one way or another by the checkout process change;
 also, we'll be working on that issue asap)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 15 23:51:15 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.