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

Re: Performance of svn+ssh vs. file for multiple files

From: Eric Peers <eric_at_missinglinktools.com>
Date: Tue, 06 Jul 2010 19:44:53 -0600

On 07/06/2010 06:16 PM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Eric Peers [mailto:eric_at_missinglinktools.com]
>> Sent: dinsdag 6 juli 2010 22:46
>> To: Daniel Shahaf
>> Cc: users_at_subversion.apache.org
>> Subject: Re: Performance of svn+ssh vs. file for multiple files
>>
>> Good suggestion Daniel. While this does markedly improve performance,
>> it
>> does so at the expense of changing the underlying protocol.
>> Unfortunately, I'm not at liberty to change the underlying protocol - I
>> have customers that define the protocol, I don't. So my "program" needs
>> to access their repos using their protocols.
>>
>> But the results:
>> ssh port forwarding to an active svnserve takes about 2.5s.
>> pure svnserve takes roughly 2s
>>
>> svnserve -d --listen-port 8000
>> ssh epeers_at_localhost -L 3690:localhost:8000
>> ...then run my svn update commands...
>>
>> --eric
>>
>> On 07/06/2010 12:52 PM, Daniel Shahaf wrote:
>>
>>> Have you tried using SSH port forwarding instead of svn+ssh://?
>>>
>>> Daniel
>>> (perhaps one of the other devs will address the points you made; I'm
>>> myself not familiar with that part of the code)
>>>
>>> Eric Peers wrote on Tue, 6 Jul 2010 at 21:17 -0000:
>>>
>>>
>>>> Howdy,
>>>>
>>>> I've got a program that needs to checkout specific files at specific
>>>>
>> versions.
>>
>>>> In this particular case a branch does not make sense. I have found
>>>>
>> that the
>>
>>>> performance of svn+ssh in this case is very bad.
>>>>
>>>> I run the rough equivalent of:
>>>> svn update -r 2 file1 file2 file3 file4 file5
>>>> svn update -r 3 file6 file7 file8 file9 file10
>>>>
>>>> overall I have about 100 such files, and 2 svn update calls. I've
>>>>
>> accomplished
>>
>>>> this with an xargs frontend to svn so as to not overrun the cmdline.
>>>>
> What you see is that updating a simple tree takes approximately the same
> amount of time: most of the time is spend on creating the connection and
> exchanging information on what to update.
>
> But in case of a recursive update below a root, all information is
> transferred at once. The 'svn update TARGET1 TARGET2.... TARGETn' performs a
> separate tree update for every individual selected target.
>
>
> To speed things up it would be interesting to know why you really need to
> update the specific files here, or can you switch to updating per directory?
> Do you need to skip a specific file?
>
> If you update specific files there are some kinds of changes you will never
> receive (e.g. New files or property changes on the directory), and you won't
> get a completely single revision working copy. (Which would actually give
> the best svn update performance as the client can just tell the repository:
> I have this tree at revision N; do you have changes for me?)
>
> Bert
>
>
I agree: I see that a separate tree update happens for each individual
target in my debug efforts. It appears the session setup times are the
dominating factor.

I do need to update specific files - I basically need to replicate
user's workspaces for per-file-per-version (think continuous build
automation). Some files are included, others are not.

Is svn_ra_reparent the way to go here on an established connection with
a custom update routine? Incidentally, where is this routine defined???
I can't find it in the libraries, but I see it in libsvn_ra-1.so but not
in the libsvn_ra directory...

    --Eric
Received on 2010-07-07 03:46:07 CEST

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

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