Community
Participate
Working Groups
Setting the input to the compare viewer in the Sync View may result in a long-running remote operation while the contents of the remote file are being fetched for the first time. Without a progress monitor it is not possible for the user to cancel the retrieval of a large file. If a connection error occurs, the user may need to wait up to 60 seconds until the timeout expires. Moreover, this work is happening in the UI thread so the UI is unresponsive and the application may appear to be "hung" for an extended duration.
I was thinking of something along the lines of putting a progress monitor in the status bar with a STOP button. I have seen some instances of this in Eclipse already.
Can't fix yet due to PR#13844. Creating a modal context inside the methods that retrieve remote contents causes a NullPointerException in Compare.
later
Reopening
*** Bug 13159 has been marked as a duplicate of this bug. ***
We should ensure that progres/cancellation is supported in the new sync view.
Progress appears for all operations in the Live Sync View. For refresh, either the workbench progress bar or the Job Progress mechanism is used. When opening a compare editor, a progress monitor is used. However, the fetching of the remote contents still happens without a progress monitor. The culprit is RemoteResourceTypedElement#createStream() which creates a NullProgressMonitor. The problem is that the compare interface IStreamContentAccessor does not provide a progress monitor on it's getContents(). Therefore, we either need to prefetch the contents before opening the editor or somehow get a monitor to the getContents. Anothe option may be to spawn a job but this would block the getContents() which is not ideal. Given that we have remote file content cahcing, I think we shoudl pre-fetch the contents.
The problem is that we would also need to pre-fetch the base just in case. It would be interesting to spawn a background job to fetch the base so it would be there if the user wants it. Special consideration would need to be made for the case where the user requests the base before it has been fetched.
Forget the last comment I made. Compare needs both the base and remote immediately so we would need to prefetch both.
I have released the code to prefetch the contents. I'm not closing the bug yet becuase I'm not convinced this is the best fix.
This fix is adequate for M2 however it is CVS specific in the sense that it requires the IRemoteResource to cahce the contents and the CS implementation does. We will need to do similar caching in Team. An ideal soluton would be to post the caching from CVS in such a way that it could be used in both places and avoid duplicate caching of contents. Moving bug to 3.0 M3.
I'm deferring the cleanup to M4. What we need is a mechanism by which we can query a remote handle to see if it supports caching or not. If it does, then tell the hanlde to cache. If it doesn't, we need to provide the cahcing in Team to ensure responsiveness.
Added API to IRemoteResource to get an IStorage which provides access to cache contents for the remote handle. Fix has been released to HEAD.
