Community
Participate
Working Groups
If the drop target is a pre-existing file, the drop operation should call IFileModificationValidator.validateEdit() instead of performing a delete before the copy/move. This will add the new file contents to the existing version history if the file is under version control. The current deletion behavior yields a new version controlled file with no history connection to previous versions.
Looks like an extension of 16907.
According to the IWorkspace spec validateEdit should be used when a file is read-only and is about to be written to using e.g., setContents. The Navigator copy/move operations are using setContents when overwriting existing files so the version history scenario should work. Are you referring to the Package Explorer or the Navigator? The Navigator meta bug for the validateEdit/setContents discussion was bug 27187.
In our failing scenario, using Eclipse 2.1, dragging a file from the Windows Explorer and dropping it into either the Eclipse Navigator or Package Explorer views only works if the destination file is writeable. If the file is under ClearCase control and is read-only (i.e. checked in), the drop operation fails silently. This scenario in Eclipse 2.0 deleted the destination file and created a new file with the copy of the source file.
This is indeed a bug. validateEdit is only called when copying/moving files or resources within Eclipse. It should also be called when importing files using drag and drop. It is called when importing using the import wizard.
Must fix for 2.1.1 since this is a regression from 2.0.
Upon closer inspection I realized that the ImportOperation does a validateEdit. This works for me when testing with the pessimistic repository provider on the VCM page (after fixing a UI bug in the example plugin). Does the validateEdit work when you drag and drop within the Navigator? Do you get the expected checkout prompt in that case (assuming you prompt)?
I would like to find out if any action is required for 2.1.1. Were you able to look at this?
It turns out our validateEdit code was not expecting to be called with a UI context from a non-UI thread. If calling from a non-UI thread with a UI context is allowed, then this defect can be closed.
I would be inclined to say that calling validateEdit from a non-UI thread should be allowed/the norm. Not all IFileModificationValidators may even use the UI context that is passed in. Opened bug 37838 to clarify the spec.
Calling validateEdit from a non-UI thread is certainly both intended and very likely. At the core level we know nothing of the UI thread, so the validator will have to syncExec into the UI if necessary. Looks like this bug can be closed. We'll look into clarifying the spec as mentioned in bug 37838.
Closing
