"Diefenderfer, Kristopher" <email@example.com> wrote
on 09/21/2005 02:05:00 PM:
> My team is experiencing extremely slow synchronization times. The sync
> dwarf our update and commit times. For instance, it might take 3 and a
> minutes to synchronize a few folders and <3 seconds to update the 5
> are found to be modified. We’ve tried switching between JavaSVN and
> and get the same performance. What is most worrisome is that our
> 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 few
> 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://
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Thu Sep 22 04:13:05 2005