On Jan 7, 2008, at 7:00 AM, Niel De Clerk wrote:
> Agreed - but that does explain why the first is faster than the
> second,
> even though you don't get more information from the second - I can't
> think of a reason why you'd want to use the second option rather than
> the first, except if you're interested in only about 10% of the
> files in
> the directory.
This is what I was attempting to explain in my original response.
When we profiled the code we found that when you do the following:
% svn <svn-command> file1 file2 file3 ...
this will initiate a separate connection for each target of the
command. (which is what happens when you
use shell wildcards. It's completely unnecessary, but this happens
to be
the way that the svn client is written. Similarly, when you give it a
single
directory as a target, it will run that command using a single
connection. Recursive
operations are done using that same connection.
In hacking with the subversion source code to force it to use one
connection per svn
command invocation, we got a very significant speedup.
>
>
> On a different note, is there a way to include subdirectories when
> using
> wild-cards? I.e. use something like *.kb to include all files in the
> current directory and all of its subdirectories?
>
> Cheers
> Niel
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy_at_gmail.com]
> Sent: 07 January 2008 13:55
> To: Niel De Clerk
> Cc: users_at_subversion.tigris.org
> Subject: Re: RE: Re: Faster SVN Status
>
> On Jan 7, 2008 12:21 AM, Niel De Clerk <NDeclerk_at_angloplat.com> wrote:
>> I definitely also saw the additional delay introduced with multiple
>> transactions. Below are 2 ways of getting exactly the same thing.
>> However the first give all the results followed by a single "Status
>> against revision X" message where the second will give the "Status
>> against revision X" for each individual file. To me this indicates
> some
>> additional handshaking? When on the same network as the repository,
>> this is a non issue, but when on a remote connection (e.g. using VPN
>> from home) this can make the difference between a 30 second and a 190
>> second transaction.
>>
>> Svn status --show-updates --verbose -N c:\my-files
>
> This asks for the status of the directory. One transaction.
>
>> Svn status --show-updates --verbose c:\my-files\*.*
>
> This asks for the status of each child of the directory because the
> shell expands the wildcards. It's the same as if you were to run:
>
> svn status --show-updates --verbose c:\my-files\file1
> c:\my-files\file2 c:\my-files\file3 c:\my-files\directory1
>
> It's not (IMHO) "exactly the same thing." You're asking for 2
> different kinds of information.
>
>>
>> -----Original Message-----
>> From: news [mailto:news_at_ger.gmane.org] On Behalf Of Vincent
>> Tondellier
>> Sent: 06 January 2008 01:51
>> To: users_at_subversion.tigris.org
>> Subject: RE: Re: Faster SVN Status
>>
>> Harvey, Edward wrote:
>>
>>> I can't say exactly what's happening in Niel's situation, but I
>> support
>>> a company with worldwide network, and when we SSH from Boston to
> India
>>> or vice-versa, there is a few second delay. Because there's a 250ms
>>> ping response delay, and the initial ssh handshake is the equivalent
>> of
>>> 10-15 small packet round-trips, it's about 5-6 seconds before the
>>> command prompt appears.
>>>
>>> If you use svn:// protocol and svnserve, there's just the basic tcp
>>> handshake before useful data starts going across, so it's much
> faster.
>>> Call it 1-2 x the ping delay. About a half a second for me.
>>>
>>> If you use https://, it looks like something like half a dozen small
>>> packet round trips. In my case, about 2 seconds delay. So it's
>> faster
>>> than svn+ssh, but not as fast as svnserve.
>>>
>>
>> You should try the connection caching feature of OpenSSH, it only
>> establish
>> one master ssh connection, and opens new ssh "channels" for each new
>> connection you make. The GCC wiki have some explanations on this :
>>
>> http://gcc.gnu.org/wiki/SSH connection caching
>>
>>>> -----Original Message-----
>>>> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
>>>> Sent: Friday, January 04, 2008 10:42 AM
>>>> To: Steven Bakke
>>>> Cc: Niel De Clerk; users_at_subversion.tigris.org
>>>> Subject: Re: Faster SVN Status
>>>>
>>>> Steven Bakke wrote:
>>>>>
>>>>> However through profiling we found a performance bottleneck in
> that
>>>> it
>>>>> starts a new repository session (network connection) once for
> each
>>>>> target of the command. In our case the problem was with 'svn
>>>> update',
>>>>> but I think it applies to almost anything. The performance
> became
>>>>> dominated by ~2-3 seconds per target overhead each time it made a
>>> new
>>>>> svn+ssh connection to the server.
>>>>
>>>> What can possibly cause a several-second delay? Does your reverse
>> DNS
>>>> lookup resolve quickly? Are IDENT queries dropped and timing out?
>>>>
>>>> --
>>>> Les Mikesell
>>>> lesmikesell_at_gmail.com
>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>
>>
>>
>> This email is subject to our email legal notice, to view browse to
> http://www.angloplatinum.co.za/E-mailLegalNotice/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: users-help_at_subversion.tigris.org
>>
>>
>
>
> This email is subject to our email legal notice, to view browse to http://www.angloplatinum.co.za/E-mailLegalNotice/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-07 15:56:34 CET