Community
Participate
Working Groups
When starting the workspace in the morning, as soon as I switch to the Synchronize view it takes about 10 minutes to complete the job "Updating CVS Workspace". If I kill it, I can immediately see exactly the outgoing changes. Indeed I need to kill it to start a "Synchronize" with the repository in order to get latest incoming changes. In my workspace I have: org.eclipse.jdt.ui org.eclipse.jdt.ui.tests org.eclipse.jdt.ui.tests.refactoring org.eclipse.jdt.core org.eclipse.jdt.core.tests org.eclipse.jdt.core.tests.builder org.eclipse.jdt.core.tests.compiler org.eclipse.jdt.core.tests.model org.eclipse.jdt.core.tests.performance jdt-core-home jdt-core-www org.eclipse.releng org.eclipse.test.performance.win32 org.eclipse.test.performance from source and shared with a CVS repository.
*** Bug 119848 has been marked as a duplicate of this bug. ***
I have come up with a nice way to deal with this but it requires API to be added to an exisiting class. I need the class SynchronizationContext to extend PlatformObject so I can get access to an internal background handler. This will allow me to track the state of the handler and show an appropriate message in the sync view. With this, on startup, the view will display that it has yet to be initializaed. Then the user can choose to initialize or sync and the view will be populated. McQ, can I get approval for the API change? I can get it into M6 since we will need a rebuild to deal with the ISaveable changes anyway. I will then be able to implement the above described behavior early in RC1.
This would definitely be a plus for the out-of-the-box experience. Right now it takes a long time after each restart to update the cvs information. This is blocking other possible cvs operations and it slows down the start of the java tooling.
+1. go for it.
Fix released to HEAD
Verified