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

Re: TortoiseSVN "Get lock" of multiple files fails via Java-SSL-tunnel since v1.9.0 (bug?)

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 6 May 2016 13:35:06 +0200

On 06.05.2016 13:12, Stefan Hett wrote:
> Hi David,
>> Hi David,
>>> I run another check with 1000 files in a test directory:
>>> -> Just saying 'svn lock *' works fine, it locks file after file and gives a good visual feedback of what is happening.
>>> -> TortoiseSVN (v1.9.4) instead shows up nearly immeadiatly "Locked by ... file ..." for about 37 files, then pauses with transfer-speed-zero. If waiting long enough (about 5 min) it continues working but throws an already-locked-error for about 50 files and then continues locking the missing ones correctly.
>>>
>>> For me it seems that TortoiseSVN somehow tries to lock a bunch of files immeadiatly but can't receive all server-answers on a slow (bad?) connection (Java-SSL-Tunnel) and finally times out. SVN instead seems to work file-by-file (as did Tortoise 1.8.12) and manages to lock all files without problems.
>>>
>>> Could this be a possible explanation? Is there a possibility (i.e. a setting) to switch back to the "old" file-by-file locking?
>>>
>> That's kind of my suspicion here too (aka: some operation fails/breaks
>> on the server or the transmission is lost, client waits for a time out
>> and then you have the hang which you are describing).
>>
>> Maybe Stefan Küng can confirm whether TSVN just utilizes the SVN
>> library here directly (rather than doing some special things itself).
>> If so, it's worth moving that on to the SVN users list, I guess...

TSVN of course uses the svn library APIs to do the locking.
It passes all files to be locked to the API at once, and then the API
would do the locking.

> On the SVN IRC channel I've been pointed to this known JIRA issue by
> stsp: https://issues.apache.org/jira/browse/SVN-4557
> This could be the problem you are facing.
>
> The underlying change between SVN 1.8 and 1.9 here is that 1.9 can
> produce an http-header section which is much larger than it would be
> with the 1.8 client. That however depends on some changes in TSVN and I
> can't confirm whether that really is the case (maybe someone else can do).

To test that, you could configure Apache with a higher value of the
LimitRequestFieldSize
configuration.

> For instance if SVN 1.9 would introduce a new API supporting the
> multi-lock-case and TSVN 1.9 makes use of that (while TSVN 1.8 would use
> the older SVN API) the net result is that with 1.9 you run into the
> header-issue described in SVN-4557 while with TSVN 1.8 you wouldn't.
>
> Given that you state you don't have any issues when not using the
> SSL-tunnel, I could imagine that the SSL-tunnel protocol/server is
> having trouble with passing on the longer http-header section in 1.9.
> Maybe that's a lead helping you to find a workaround?

the svn 'servers' config file has a few options which might help here as
well:
http-chunked-requests
and
http-bulk-updates

not sure if those are even in play here, but worth a try.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3171515
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-05-06 13:35:16 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.