RE: RE: [Subclipse-dev] Bug introduced with 1.1.9 - LockDialog

Hi Mark,
 
first of all let me make sure that we are looking at the same code.
 
I am looking at SVNFileModificationValidator from revision 2853. The commit comment is:
"Improve handling of read-only files that are not managed by SVN. Needed to add a prompt to remove the read-only attribute."

Here are my observations:

Test 1:

- Create a new simple project

- Add a file test1.txt to the project

- Add the project and the file to version control

- Open test1.txt and add some text. The callback SVNFileModificationValidator#validateSave is called. SVNFileModificationValidator#validateEdit is not called so the code that has been changed in rev. 2853 is not run.

This is interessting since I would have expected the validateEdit to be called.

Looking at the way base eclipse components use the validateEdit method and at the API docuemtation from IWorkspace#validateedit I can see that the validateEdit method is and should only be called in case a resource is read only.

Let me describe when I see the problem. I am using Rational Software Architect version 7 and I am working on a UML project. Whenever I add a emx (UML model file) to Subversion I see the problem as soon as I try to edit it. I figure that this happens because Rational Software Architect is not obeing the API contract. It is always calling Workspace#validateEdit even if the file is not read only.

So this looks like a bug in RSA 7. The question is if you could insert some additional code to make the SVNFileModificationValidator#validateEdit more safe in regard to missuse. The API doc of IFileModificationValidator does not include the restriction that it may only be called for read only files.

The code in the current implementation is prompting for every file managed by subclipse. This is why I see the behavior.

Actually the code that is calling in the case an UML model is opened is not RSA 7 specific. It is the

org.eclipse.gmf.runtime.common.core.command.FileModificationValidator from the GMF runtime. It's approveFileModification method is calling the validateEdit method no matter what the read only flag is. Later in the call chain the org.eclipse.gmf.runtime.common.ui.resources.FileModificationValidator is called with the okToEdit method with three args which then finally calls IWorkspace#validateEdit without checking for read only resources first. So this is propably effecting all GMF applications.

I guess the best way to deal with this would be to

a) make the subclipse code more tolerant

b) file a bug with GMF and maybe with IWorkspace API doc to clarify the calling contract.

What do you think?

Thomas

________________________________

From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Fri 08.12.2006 23:53
To: dev@subclipse.tigris.org
Subject: Re: RE: [Subclipse-dev] Bug introduced with 1.1.9 - LockDialog

On 12/8/06, Thomas M. Hofmann <email@thomashofmann.com> wrote:
> Well, in my case the file in question is not read-only and the problem
> occurrs with another file (in the same project too).
> What info would you need?

I don't know. Do you get it for every file? You looked at the code,
maybe look again to see if you can see why files are passing through
the filter. I'll try editing a few more files, but I have never seen
it incorrectly.

Are you on Windows? It is possible the check for read-only gives
false positives on other operating systems.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org