Community
Participate
Working Groups
200401060800 - started an existing workspace - had the synchronized view stacked over the package explorer - clicked on the package explorer tab - got blocked for about 3 minutes. The back ground thread was refreshing the sync info.
Is this reproducable for you? I can switch back and forth between the two views during a refresh with no delay. Possible causes of the block would be either that the packages view obtains a scheduling rule on resources that are being refreshed (i.e. obtains the workspace lock) or that the sync view is redrawing at the time of the blockage. The later is more likely. Did you have a large number of incoming or conflicting changes?
I tried to reproduce but was able to do so today. Just to clarify: the message I saw in the status line during the blockage was something like "Updating synchronization state...". I didn't trigger a team action.
There are several problems here: - the major problem is that the wizard does not fork its modal context. Therefore, it is run in the UI thread but the job mechanism doesn't show the blocked dialog because it looks for a particular type of progress monitor (and the wizard uses a different type of progress monitor). - another problem is that the JDT UI operations locks the entire workspace. Even if the above is fixed, the user would have to wait until all resource scheduling rules are released before it could run. The operation would be more responsive if only the resource (or at least project) involved were locked. Asigning to UI and copying John as the biggest issue is the problem of a wizard's modal context running in the main thread.
Michael, did you annotate the correct PR here ?
Oops
I have not been able to reproduce this. We have done a lot of optimizations to the model building code of the sync view so perhaps that has helped.
