Eclipse Community Forums: Subversive » Accepting Incoming Changes (Updates) Slow

Home » Eclipse Projects » Subversive » Accepting Incoming Changes (Updates) Slow

Accepting Incoming Changes (Updates) Slow [message #16099]

Wed, 16 April 2008 17:07

Eclipse User

Originally posted by: mike.boxwoodtech.com

We recently switched from CVS to Subversion+Subversive and we love it.
Everything is working perfectly except updates seem to be taking much
longer than they did with CVS. By this I mean when we "Update all
incoming changes" in the "Team Synchronizing" perspective it takes about
1-2 minutes to complete for only a handful of file changes. This took
about 1-3 seconds with CVS.

I'm not sure why it takes longer since Subversive/Eclipse already knows
specifically what files are changing and how. It should just be a quick
update of those few files.

Our codebase consists of approximately 6000 text-based files averaging
about 2k each, but as I said we're typically only updating a few files at
a time. We're using the "Default SVN Kit (SVNKit 1.1.6
(http://svnkit.com/) r3855)" as our SVN Connector if that makes any
difference. We're on Windows Vista Business/Ultimate Running Eclipse
3.3.2 on our client machines. SVN is running though Apache on Windows XP.

I'd appreciate any advice you can give. Thank you for your time.

- Mike

Re: Accepting Incoming Changes (Updates) Slow [message #16403 is a reply to message #16099]

Wed, 16 April 2008 21:42

Eclipse User

You should first determine if it's svn or the subversive plug-in... How long
does it take to do an update from the command line?

After that, there are a few reasons the svn server could be slow - when we
set up our SVN repository we were told it would be very slow on files with
"mixed" line endings, e.g. Files that have both unix and windows line
endings.

But I am sure there could be other reasons...

On 17.04.2008 04:07, in article
7ec4c0718a6fdb5d0c9dfdd09ace9fdf$1@www.eclipse.org, "Mike"
<mike@boxwoodtech.com> wrote:

We recently switched from CVS to Subversion+Subversive and we love it.
Everything is working perfectly except updates seem to be taking much
longer than they did with CVS. By this I mean when we "Update all
incoming changes" in the "Team Synchronizing" perspective it takes about
1-2 minutes to complete for only a handful of file changes. This took
about 1-3 seconds with CVS.

I'm not sure why it takes longer since Subversive/Eclipse already knows
specifically what files are changing and how. It should just be a quick
update of those few files.

Our codebase consists of approximately 6000 text-based files averaging
about 2k each, but as I said we're typically only updating a few files at
a time. We're using the "Default SVN Kit (SVNKit 1.1.6
(http://svnkit.com/) r3855)" as our SVN Connector if that makes any
difference. We're on Windows Vista Business/Ultimate Running Eclipse
3.3.2 on our client machines. SVN is running though Apache on Windows XP.

I'd appreciate any advice you can give. Thank you for your time.

- Mike

Re: Accepting Incoming Changes (Updates) Slow [message #16683 is a reply to message #16403]

Fri, 18 April 2008 11:58

Eclipse User

Originally posted by: mike.boxwoodtech.com

It's very fast via command line (a few seconds). I suspect that
Subversive must be doing some extra processing after the update. I can
see the files update in the SVN console rather quickly. It then hangs for
about 1-2 minutes while it does some sort of mysterious processing. Then
it finally gives me back control of Eclipse. Once I have control it then
takes a few more seconds to update the navigator view.

We can live with 1-2 minutes for updates since we only do it once or twice
a day. I just found it odd since it was so out of line with how CVS
performed and how the command line performs. Thanks for your help.

Previous Topic:	copy and paste in navigator/package explorer
Next Topic:	SVN providers for Ganymede/Eclipse-3.4M6?

Goto Forum:

-=] Back to Top [=-

Current Time: Thu May 01 08:30:46 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter