| Summary: | [Examples] Pessimistic provider should return !OK for read-only not under version control | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Knut Radloff <knut_radloff> |
| Component: | Team | Assignee: | Platform Team Inbox <platform-team-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | dj.houghton, jeem, Kevin_McGuire, n.a.edgar |
| Version: | 2.0 | ||
| Target Milestone: | 3.1 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | 28216 | ||
| Bug Blocks: | |||
|
Description
Knut Radloff
Team should display an error message if a context is passed in and a file is read-only. I think it would be useful if an option would be displayed to make the file read-write. validateEdit would return OK then and the write operation could succeed. IWorkspace.validateEdit should return ERROR when read-only file is not under version control The spec says that the user will have already been warned if you had passed in a shell but the resource could not be made read/write. This not the case when there is no provider. The caller doesn't know the difference. VCM should either display a dialog in this case, or return a status indicating that there is no version provider, so the move/copy can proceed with overwriting the file. Yes, a "don't care" return status would be useful. If a file is not under version control (and thus the VCM provider can't/shouldn't make it read/write) we want to support deleting the file anyway. Perhaps Core could add a WARNING status to the spec. I.e., the VCM provider says it's ok to write from a VCM point of view but the caller is warned that the file is read-only anyway. See comment 14 in bug 21666 about delete behavior. Getting back OK, but it remaining read-only, could be the hint for "Don't care". In this case, the UI could be helpful and offer to make it writeable. Getting back !OK, and read-only, would mean the provider tried but was unsuccessful at checking it out. In this case, the UI should *not* be helpful and offer to make it writeable. I've tried to capture Knut's spec observations and requirements in bug #28216. Further spec discussion should happen there. Bug #28218 is for Nick's comments about the default provider not prompting. This bug will remain Jed's for making the Pessimistic provider spec compliant. I suggest he make it compliant according to the current spec, then if the spec changes we can adjust the pessimistic provider again. Should ensure this is right for 3.1 This was fixed in 3.1 |