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.
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
Received on 2008-01-07 13:40:53 CET