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

Re: Son of DAV Questions

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-01-04 00:17:04 CET

On Thu, Jan 03, 2002 at 02:03:59PM -0600, Ben Collins-Sussman wrote:
> So normally, when ra_dav does an update, it requests a custom report.
> mod_dav_svn sends back a report that looks mostly like an XML
> representation of an editor drive. ra_dav parses this report, and
> thereby knows which file contents and properties to fetch.

Right.

> It seems that whenever the report contains an 'add_file' or 'add_dir',
> ra_dav unconditionally fetches all props for the object.

Yup. It does this to get user properties, primarily. We also need the other
properties, but we'll always have to "fetch all" for those user props.

However, after the last visit to Chicago, I realized that cmpilato was right
to force a <fetchprops> in there rather than having it implicit in add_file
and add_dir. It is entirely possible that the file/dir has *no* props of any
relevance, so we shouldn't waste the round trip.

> Otherwise,
> ra_dav only fetches an object's props when the report says it needs
> to.

Yah.

> Here's the issue: we want these three new DAV properties
> (version-name, creationdate, creator-displayname) to be
> unconditionally retrieved for *every* item mentioned in the update
> report. I can think of 3 ways to do this:
>
> 1. Have ra_dav automatically fetch the three props for each item
> in the report. Of course, that's an extra request per item,
> above and beyond the GET it is doing on each item.

Yup.

> 2. Have the report tell ra_dav to fetch the three props. Pretty
> dumb, since this is just a more complex version of #1.

Yah... dumb :-)

> 3. Embed the three props/values next to each item in the report.

Certainly.

> Any objections to #3? gstein?

     4. [optimization] The report knows all the versions seen and gives you
         a table of version -> creationdate, creator-displayname.

     5. [optimization] For each directory containing files, do a PROPFIND
         of Depth:1 on that dir and collect the props for the children,
         rather than doing a PROPFIND for each child.

I would say that the report should include the values unless <fetchprops> is
added to the report. For simplicity, you could just always add them to the
report and we can optimize the thing later (e.g. leave a comment in the code
to that effect).

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 Sat Oct 21 14:36:54 2006

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.