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

Re: [PATCH 2/2] git-svn: allow git-svn fetching to work using serf

From: Lieven Govaerts <lgo_at_apache.org>
Date: Sun, 7 Jul 2013 20:11:18 +0200

On Sun, Jul 7, 2013 at 4:48 PM, Kyle McKay <mackyle_at_gmail.com> wrote:
> On Jul 7, 2013, at 06:39, Daniel Shahaf wrote:
>>
>> Kyle McKay wrote on Sat, Jul 06, 2013 at 19:46:40 -0700:
>>>
>>> On Jul 6, 2013, at 19:23, Jonathan Nieder wrote:
>>>>
>>>> Kyle McKay wrote:
>>>>
>>>>> Unless bulk updates are disabled when using the serf access method
>>>>> (the only one available with svn 1.8) for https?: urls,
>>>>> apply_textdelta does indeed get called multiple times in a row
>>>>> without an intervening temp_release.
>>>>
>>>>
>>>> You mean "Unless bulk updates are enabled" and "without an intervening
>>>> close_file", right?
>>>
>>>
>>> The problem seems to be skelta mode although it may just be the fact
>>> that ra_serf has multiple connections outstanding and since ra_neon only
>>> ever has one it can't happen over ra_neon.
>>>
>>> If the server disables bulk updates (SVNAllowBulkUpdates Off) all
>>> clients are forced to use skelta mode, even ra_neon clients.
>>
>>
>> As Brane and I have pointed out, git-svn can instruct libsvn_* to use
>> bulk updates regardless of the server version, by setting
>> SVN_CONFIG_OPTION_HTTP_BULK_UPDATES (new in 1.8).
>>
>> If you have questions about that, though, please address them to
>> users_at_subversion.apache.org (the proper list for API usage questions),
>> not to me personally.
>
>
> According to the table at
> <http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default>,
> if the server sets SVNAllowBulkUpdates Off, the client will be forced to use
> skelta no matter what the client setting is.

Indeed, the server admin has the final say in which mode is actually
used. SVNAllowBulkUpdates Off is only advised if the server admin
wants a log line per accessed resource. I doubt it's used a lot, but
the option is there.

>
> Is that table incorrect?

No, that table is correct.

> Kyle

Lieven
Received on 2013-07-07 20:12:12 CEST

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