On 9 May 2016 at 15:03, David Hinken <d.hinken_at_isfh.de> wrote:
>> > Ivan suggested to use the svn command-line tool. I just tried it using a batch file
>> > and passed all 1000 text files to 'svn lock a b c ...'. It works fine without any trouble!
>> > It seems to work file-by-file and thus takes is slower is quite slow but work without problem.
>> It's really strange, because TortoiseSVN uses the same API in the same
>> way as Subversion command line client.
>> What svn.exe version you're testing? You may use 'svn.exe --version'
>> command to find Subversion command line client version.
> Sorry, my mistake, I had two versions of subversion installed.
> svn version 1.8.13 (r1667537) works file-by-file and works without any problem.
> svn version 1.9.4 (r1740329) shows a similar behaviour as TSVN. It tries to lock
> about 30-40 files at once and then hangs without any sign of progress.
Does it hang after successfully locking 30-40 files or it doesn't work
completely when attempt to lock more than 30-40 files at once?
>> I'm not familiar with Java-Tunnel. Could you please share URL you're
>> using to checkout Subversion working copy.
> The URL is
> and redirects via the Java-Tunnel (running in Firefox) to the SVN server.
Now it's more clear: Java-Tunnel acts as a proxy and forwards all
requests to SVN Server. The most likely problem that Java-Tunnel
doesn't implement HTTP pipelining  properly. HTTP pipelining is a
technique in which multiple HTTP requests are sent on a single TCP
connection without waiting for the corresponding responses. svn
lock/unlock uses HTTP pipelining to lock/unlock multiple files since
Subversion 1.9.0. HTTP pipelining is also used by 'svn checkout', but
this can be disabled on server or client-side.
I suggest you report this problem to Java-Tunnel developers.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2016-05-09 14:18:35 CEST