On Thu, May 10, 2012 at 5:41 PM, C. Michael Pilato <cmpil...@collab.net> wrote:
> On 05/10/2012 06:21 AM, Ivan Zhakov wrote:
>> It seems that ra_serf unconditionally retrieves properties using
>> PROPFIND for *all* added files:
>
> Yup, that's what I said. :-)
>
>> subversion\libsvn_ra_serf\update.c:1633 (start_report)
>> [[[
>> else if ((state == OPEN_DIR || state == ADD_DIR) &&
>> strcmp(name.name, "add-file") == 0)
>> {
>> const char *file_name, *cf, *cr;
>> report_info_t *info;
>>
>> file_name = svn_xml_get_attr_value("name", attrs);
>> cf = svn_xml_get_attr_value("copyfrom-path", attrs);
>> cr = svn_xml_get_attr_value("copyfrom-rev", attrs);
>>
>> if (!file_name)
>> {
>> return svn_error_create(
>> SVN_ERR_RA_DAV_MALFORMED_DATA, NULL,
>> _("Missing name attr in add-file element"));
>> }
>>
>> info = push_state(parser, ctx, ADD_FILE);
>>
>> info->base_rev = SVN_INVALID_REVNUM;
>> info->fetch_props = TRUE;
>> info->fetch_file = TRUE;
>> ]]]
>>
>> Do you know why?
>
> "We've always done it that way." :-)
>
> Seriously, this decision is so old that I can't remember its reasoning. It
> could be because there are *always* some properties of interest on added
> files, therefore no reason to conditionalize the fetch. Even if there are
> no user-defined props, the "entry props" for last-committed-rev,
> last-committed-author, etc. need to be fetched.
>
> One easy improvement we could make would be to amend the protocol to go
> ahead and pass directly those "entry props" for added files, too, and to
> return to using the <fetch-props/> tag for added files that have
> user-defined props set. On the client side, the mere presence of
> <set-prop>...</set-prop> for an added object would mean "Don't assume that
> you need to fetch properties because I'm giving some of them to you
> directly", and of course the presence of the <fetch-props/> tag would then
> indicate "...but in this case, please go ahead and fetch them all".
>
> Such a change would also open the door for us passing *all* the properties
> for added objects inline in the future if we wish: just
> <set-prop>...</set-prop> them all and *don't* include the <fetch-props/>
> indicator.
>
It seems to be a good thing to try to implement on Hackathon in Berlin.
I'm often switching between different branches and I'll benefit a lot
if this operation will just take one REPORT request, instead of many
PROPFINDs for each added file.
--
Ivan Zhakov
