You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2002/01/03 20:03:59 UTC
Son of DAV Questions
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.
It seems that whenever the report contains an 'add_file' or 'add_dir',
ra_dav unconditionally fetches all props for the object. Otherwise,
ra_dav only fetches an object's props when the report says it needs
to.
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.
2. Have the report tell ra_dav to fetch the three props. Pretty
dumb, since this is just a more complex version of #1.
3. Embed the three props/values next to each item in the report.
Any objections to #3? gstein?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Son of DAV Questions
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 03, 2002 at 05:46:15PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > 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.
> >
>
> Huh? This has nothing to do with the problem. The whole point is
> that the 3 dav-props are going to be embedded in the report, so we're
This was an *alternative*. If the props ARE NOT in the report, then this is
a way to get the props for large groups of files.
> not planning to do a PROPFIND on any children unless the report
> *explicitly* says to do so. That's how it works already.
I wasn't clear enough. Let's say your repository has the following files:
/foo/file1
/foo/file2
/foo/file3
/foo/file4
And the report says to fetch file1, file2, and file4. You could do a
PROPFIND on /foo with a Depth:1 and get the properties for all of the files
in one shot. The props for file2 will appear, but can be ignored.
It is a balancing act of "will props for the unwanted files outweigh the
overhead of multiple requests?"
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
Re: Son of DAV Questions
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > 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.
Great idea.
>
> 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.
>
Huh? This has nothing to do with the problem. The whole point is
that the 3 dav-props are going to be embedded in the report, so we're
not planning to do a PROPFIND on any children unless the report
*explicitly* says to do so. That's how it works already.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Son of DAV Questions
Posted by Greg Stein <gs...@lyra.org>.
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