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
Kris
-----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>
wrote
on 09/21/2005 02:05:00 PM:
> My team is experiencing extremely slow synchronization times. The
sync
times
> dwarf our update and commit times. For instance, it might take 3 and
a
half
> 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
JavaHL
> 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
that
> performance will decrease over time.
>
> To be clear, we are trying to issue team->synchronize commands from
various
> spots in eclipse (Java perspective, java browsing perspective, etc)
targeting
> projects, sub directories or files.
>
> Are there known performance problems in the areas of synchronization?
Are
> actual content comparisons being done in a sync request? We have a
few
binary
> 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
the
svn status -u -v command from a similar location in your project
structure
and see how it compares. We could never run any faster than that
command,
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
them
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
critical.
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://
Mark
________________________________________________________________________
_____
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