Community
Participate
Working Groups
Steps to reproduce: 1. svn co http://svn.jboss.org/repos/jbosstools/trunk jbosstools-trunk 2. Fire up Eclipse 3.6, with m2eclipe and subversive installed into it 3. File > New > Project, browse for above jbosstools-trunk folder. 4. Wait 10 mins for Eclipse to load the project (or, in some cases, run out of memory and crash). 5. subsequent restarts are insanely slow as well due to svn cache/status checking ---- Is there a way to make the svn cache processes / svn status checks happen more 'nice'ly, or more in the background w/o so they don't block the use of Eclipse, or in fact the whole system? Sure, reading from disk (and fetching info from SVN repos) is time/cpu consuming, but could it be 'nice'd so it doesn't crash/hang/block so much of the system's resources? Admittedly this is perhaps not just an svn issue, but also an Eclipse resources issue: see also bug 321380.
There are few important points: 1) There were some not a very nice solutions used in Subversive (see bugs #321542, #359199). Both issues were directly related to the described case. 2) By default Subversive uses some functionality that requires SVN-info cache to be filled first. It works just fine for most of a projects, but when the project is too large it may cause some problems. In that case there is always the way to turn off the cause of it all: functionality, that requires SVN-info cache and the cache itself (see Window->Preferences->Team->SVN->Performace). 3) As for the filling SVN-info cache itself - it is already a background task, split in chunks and queued on per-folder basis, the thread that performs SVN-info reading is running with the Thread.MIN_PRIORITY used. The only way to make it more "'nice'ly" is to use something like sleep() function to pause processing, which is most likely will cause serious performance issues for all the SVN related tasks. So, regarding the solved cases with the bugs #321542 and #359199 I'll assume the case as solved to the best of our abilities.
One more note: Solution for the bug #359199 will be included into the next "early access" build. I hope it will help with the issue, if not - please feel free to inform us, although for the moment I don't know what else could be done.
