Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 28123

Summary: [Examples] Pessimistic provider should return !OK for read-only not under version control
Product: [Eclipse Project] Platform Reporter: Knut Radloff <knut_radloff>
Component: TeamAssignee: 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 CLA 2002-12-11 14:10:55 EST
build 20021210

I'm using the pessimistic repository provider example to test validateEdit 
changes to copy operations.
I have a project under version control and a read-only file that is not. 
validateEdit for that file returns OK, presumably because the repository 
provider says it's ok to write because it doesn't manage the file. When the 
project is not under version control the same scenario returns ERROR as per the 
IWorkspace.validateEdit spec.
The spec says that I can expect to be able to write to the file when 
validateEdit returns OK. This is not true in this case.
Comment 1 Knut Radloff CLA 2002-12-11 16:36:28 EST
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.
Comment 2 Kevin McGuire CLA 2002-12-11 18:43:30 EST
IWorkspace.validateEdit should return ERROR when read-only file is not under 
version control
Comment 3 Nick Edgar CLA 2002-12-12 09:14:11 EST
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.

Comment 4 Knut Radloff CLA 2002-12-12 09:56:55 EST
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.
Comment 5 Kevin McGuire CLA 2002-12-12 13:43:49 EST
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.
Comment 6 Kevin McGuire CLA 2002-12-12 16:38:15 EST
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.
Comment 7 Michael Valenta CLA 2004-11-08 21:59:01 EST
Should ensure this is right for 3.1
Comment 8 Michael Valenta CLA 2005-03-30 10:58:15 EST
This was fixed in 3.1