Community
Participate
Working Groups
Build I20021126 The code contained in the status returned from IWorkspace#validateEdit() can't be used to derive why validateEdit failed (the current CVS plugin simple uses IStatus.ERROR as a code). For example if it failed because a read-only file couldn't be made writable (since the file is locked by another user) JDT-UI would like to present a dialog to the user but not log the status. If it fialed due to another reason the status should be logged as well. I propose that core resources defines a corresponding error code and that the spec of validateEdit is extended is a way that all "implementors" of this hook must use this constant to signal the case that a file couldn't be made "writable".
Adding Jeem to CC for comment.
Since you're in UI code, I assume you are passing in a context (Shell) to validate edit. If so, you don't need to report anything, as the spec states: "If a shell is passed in as the context, the VCM component may bring up a dialogs to query the user or report difficulties; the shell should be used to parent any such dialogs; the caller may safely assume that the reasons for failure will have been made clear to the user." If you're not in UI code, just display the given status to the user, and don't log anything. This is really a boolean operation: OK signals that the files are writable, ERROR signals they are not writable. There is no reason to log anything here. If the VCM component had some kind of internal error, it can log that itself.
Then this should be at least speced in the Javadoc. And I am still convinced that the status returned should have a meaning full code.
I'm not sure what cases are not covered by the doc. Are you thinking that the checkout might suceed but an ERROR status be returned for another reason? If there are only two possible outcomes ("the files are modifiable" or "the files are not modifiable"), then another status code isn't useful.
*** This bug has been marked as a duplicate of 42230 ***
