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

RE: Re: Extremely slow synchronization time

From: Diefenderfer, Kristopher <kristopher.diefenderfer_at_cybertrust.com>
Date: 2005-09-22 00:29:51 CEST

Thanks for the tips Mark. Looks like going with javaSVN gives us a
little better performance when we have differences. The command line
runs at about the same speed. I'll see if I can setup use of the
different protocol. Maybe we'll see noticeable performance there.

Thanks again


-----Original Message-----
From: Mark Phippard [mailto:MarkP@softlanding.com]
Sent: Wednesday, September 21, 2005 2:13 PM
To: users@subclipse.tigris.org
Subject: Re: Extremely slow synchronization time

"Diefenderfer, Kristopher" <kristopher.diefenderfer@cybertrust.com>
on 09/21/2005 02:05:00 PM:

> My team is experiencing extremely slow synchronization times. The
> dwarf our update and commit times. For instance, it might take 3 and
> minutes to synchronize a few folders and <3 seconds to update the 5
files that
> are found to be modified. We've tried switching between JavaSVN and
> and get the same performance. What is most worrisome is that our
project is
> brand new and we have very few files checked in so I can only assume
> performance will decrease over time.
> To be clear, we are trying to issue team->synchronize commands from
> spots in eclipse (Java perspective, java browsing perspective, etc)
> projects, sub directories or files.
> Are there known performance problems in the areas of synchronization?
> actual content comparisons being done in a sync request? We have a
> files checked in, is there a performance issue syncing binary files?
> Important stats : subclipse 0.9.34, eclipse 3.1.0

It is definitely a lot slower than those other operations, unless I
suppose the update was bringing down a lot of new files. Try running
svn status -u -v command from a similar location in your project
and see how it compares. We could never run any faster than that
since we have to do it, plus some extra stuff.

If you have any incoming changes, using JavaSVN should be considerably
faster than JavaHL. When using the latter, for each incoming change we
have to run the equivalent of an svn info to get information that svn
status is not returning. I have submitted a patch to Subversion for
to add this in a future release so we could do it all in one round-trip.

Because of the extra server round-trips, network performance is
Synching with a server on my LAN is pretty reasonable. Doing it with
tigris.org is pretty slow.

Anyway, JavaSVN should be giving the best performance. Likewise, svn://

will give better performance than http://


Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs.
Received on Thu Sep 22 08:29:51 2005

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

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