RE: svn commit: r1806017 - /subversion/trunk/subversion/libsvn_ra_serf/merge.c

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: kotkov@apache.org [mailto:kotkov@apache.org]
> Sent: donderdag 24 augustus 2017 11:43
> To: commits@subversion.apache.org
> Subject: svn commit: r1806017 -
> /subversion/trunk/subversion/libsvn_ra_serf/merge.c
> 
> Author: kotkov
> Date: Thu Aug 24 09:43:28 2017
> New Revision: 1806017
> 
> URL: http://svn.apache.org/viewvc?rev=1806017&view=rev
> Log:
> ra_serf: Prevent the server from generating and sending the full MERGE
> response in cases when we don't require it.
> 
> The full response is not required when working over HTTPv2 protocol.
> When working over HTTPv1, it's only required when the new working copy
> properties need to be stored as part of a commit (indicated by a non-null
> svn_ra_push_wc_prop_func_t callback).

Nice catch!

Does this affect performance enough that we should backport this fix?

	Bert

Re: svn commit: r1806017 - /subversion/trunk/subversion/libsvn_ra_serf/merge.c

[Evgeny Kotkov <ev...@visualsvn.com>]

Bert Huijben <be...@qqmail.nl> writes:

>> ra_serf: Prevent the server from generating and sending the full MERGE
>> response in cases when we don't require it.
>>
>> The full response is not required when working over HTTPv2 protocol.
>> When working over HTTPv1, it's only required when the new working copy
>> properties need to be stored as part of a commit (indicated by a non-null
>> svn_ra_push_wc_prop_func_t callback).
>
> Nice catch!
>
> Does this affect performance enough that we should backport this fix?

Thanks!

I guess that it would be nice to backport this fix, as it prevents the
server from reading the list of the committed changes after the commit
and also reduces the size of the sent response.  I think that the full
MERGE response can be quite large for commits with thousands of
changed paths, although I don't have any real numbers at this time.

With that in mind, I have put nominating this change on my todo list,
unless someone else beats me to it.


Regards,
Evgeny Kotkov