Community
Participate
Working Groups
The "Synchronize" button in the Team-Synchronization perspective is very slow (>5min), when there are changes in the remote repository. When there are no changes, it is fast (<10sec). Doing a normal "Update" is always fast. I'm using the Native JavahL 1.4.4 now, but before that I was using the SvnKit, and it showed the same behaviour (I think that one was always slow). Protocol is http. Is this reproducible for anybody? Is there any more information I can provide to help?
Fix will be available at the end of this week.
Which week is that? :) Can I try the fix somewhere?
Fix is included into Subversive build 0.7.0.v20080321 which is available for download.
OK, thats the one I'm using. And sorry to say, but it is still slow. There was a single changed file in the repositoy, and it took about 1min to discover that...
I cannot reproduce described behaviour. Synchronization is finished for me in ~2 minutes when I have 41 projects (all these projects are accessed through internet using svn+ssh and http protocols) in Synchronize View and totally 45 incoming changes for these projects. (Tested connector - SVN Kit 1.1.4). So, could you please provide following information: 1) How much projects you have registered in the Synchronize View 2) Are all these project related to the same repository? 3) How much time takes expanding of any node for the repository to which related these projects inside SVN Repositories Exploring perspective? P.S. Also you can try to disable option "Window->Preferences->Team->SVN->View Settings->Show synchronize info contiguous" (disabling this option may speed up synchronization if repository access latency is too high).
I cannot reproduce described behaviour. Synchronization is finished for me in ~2 minutes when I have 41 projects (all these projects are accessed through internet using svn+ssh and http protocols) in Synchronize View and totally 45 incoming changes for these projects. (Tested connector - SVN Kit 1.1.4). So, could you please provide following information: 1) How much projects you have registered in the Synchronize View 2) Are all these project related to the same repository? 3) How much time takes expanding of any node for the repository to which related these projects inside SVN Repositories Exploring perspective? P.S. Also you can try to disable option "Window->Preferences->Team->SVN->View Settings->Show synchronize info contiguous" (disabling this option may speed up synchronization if repository access latency is too high). Sorry for the long delay, was working on another project (using CVS) To answer your questions: It's only one project, and expanding nodes takes less than a second. Here is what I did. I deleted all except for 1 project in my workspace. The remaining project contains 377 files: > find . -name .svn -prune -o -type f |wc -l 377 There are two remote changes in that project: > time svn -u st * 73922 src/changes/changes.xml * 74075 pom.xml ? .classpath.bak Status against revision: 75346 svn -u st 0.04s user 0.05s system 13% cpu 0.659 total So this took also less than a second When doing a Team Synchronize on that project, it took 50sec. Almost all of the time the progress bar was on 40% saying: Fetch Revision information: 75227 The 75227 revision is a one line change to the src/changes/changes.xml file. After it finished, it displays: 4 new changes found (incoming 4; outgoing 4). which is strange, cause there are only two incoming changes. The actual Synchronization view displays the correct information. There is nothing in the log or in the SVN console. The "Show synchronize info contiguous" was turned off. Repository access is done via http and it's on the local net. Any more information I can provide to help, or anything else I can try? Some more data: I'm using MacOSX 10.4.11, Eclipse Version: 3.3.2 Build id: M20080221-1800 The SVN Connector: Native JavaHL (svn:1.4.4 (r25188) jni:0.9.0) > svn --version svn, version 1.4.4 (r25188) compiled Jun 14 2007, 14:23:02
Thank you for providing additional information. >When doing a Team Synchronize on that project, it took 50sec. Almost all of the >time the progress bar was on 40% saying: > Fetch Revision information: 75227 > >The 75227 revision is a one line change to the src/changes/changes.xml file. > >After it finished, it displays: > 4 new changes found (incoming 4; outgoing 4). "Fetch Revision information" text is shown when Subversive fetches log message for the revision in order to support Eclipse's incoming change sets. Also, as I see, the revision number is very impressive. :) So, I think you need to check what is the version of the SVN server which your project is related to. AFAIR some old SVN versions cannot handle log message query argument which says how many revisions should be reported to the client side. In that case receiving this information may take very long time even if repository is accessed through local network.
Reopen in order to link with similar report.
NOTE: Similar problem described in "linked to" report also happened on Mac platform. *** This bug has been marked as a duplicate of bug 227708 ***
Nikolaus Heger wrote: "I have new, and significant information on our repository. I have found a potential cause for the slowness. When I issue a "svn log --verbose (filename)" on one of the slow files, I get a list of "changed paths" which each revision. That is interesting but has a fatal problem with the initial revision. The file was there from the beginning, and our repository was set up from scratch with an existing code base, so the last rev looks like this: r9 | rob | 2008-04-06 12:54:48 +0700 (Sun, 06 Apr 2008) | 1 line Changed paths: A /modules/moduleA A /modules/moduleA/branches A /modules/moduleA/branches/branch1 ..... And it now goes on to list all 55,000 files that were checked in on the initial checkin, each one on it's own line. That's over 6MB of data, just for the log on a single file. All operations that use a verbose svn log would be affected by this." The reason of the problem is clean now and definitely Synchronize view should not grab affected paths. So, I reopen this issue.
