[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Thomas M. Hofmann <email_at_thomashofmann.com>
Date: 2006-12-21 14:39:50 CET

Hi Mark,
 
I just saw that the code in HEAD is still using java.io.File. Are you going to revert to using IFile instead?
 
Regards,
 
Thomas

________________________________

From: Thomas M. Hofmann [mailto:email@thomashofmann.com]
Sent: Dienstag, 12. Dezember 2006 4:49
To: dev@subclipse.tigris.org
Subject: RE: Re: RE: [Subclipse-dev] Bug introduced with 1.1.9 - LockDialog

Yes I debugged and all the four files were passed. I selected all four and moved them to a new directory using the refactor functionallity. In this case the validator is called with all four files.
 
Mit freundlichen Grüßen,
 
Thomas Hofmann

________________________________

From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Tue 12.12.2006 16:48
To: dev@subclipse.tigris.org
Subject: Re: Re: RE: [Subclipse-dev] Bug introduced with 1.1.9 - LockDialog

Did you debug to see if all those files came through? I ask because, superficially, every version of the code I have committed would pass those same tests. The difference for you is that writable files can get passed in to the method and they cannot when I test it.

Mark

On 12/12/06, Thomas M. Hofmann <email@thomashofmann.com> wrote:

        Hi Mark,
        
        I tested your latest code and everything looks fine now. I then changed the isReadOnly method to use IFile API instead of java.io.File. It also works so I think calling iFile.isReadOnly would be the way to go.
        
        The test included a read only unmanged file, a read only managed file, a writable managed and a writable unmanaged file. I was prompted to lock the managed read only file and I got the prompt to switch the read only flag on the read only unmanaged file. No prompts appeared for the writable files.
        
        I noticed one more thing which is probably something that affects several classes: When I decide not to lock a read-only file I get an error message with an empty reason string. This is because the Status.CANCEL is returned which does not have and description (it should according to the javadoc in IFileModificationValidator). The same would be the case if the LockResourceCommand would fail.
        
        I appreciate the effort you put into this. Thank you very much!
        
        
        Thomas
        
        
        ________________________________
        
        From: Mark Phippard [mailto:markphip@gmail.com ]
        Sent: Tue 12.12.2006 02:36
        To: dev@subclipse.tigris.org
        Subject: Re: Re: RE: [Subclipse-dev] Bug introduced with 1.1.9 - LockDialog
        
        
        On 12/11/06, Thomas M. Hofmann < email@thomashofmann.com> wrote:
        
                Please try the attached patch. I still think the validator for the files not managed should only get the ones passed that are not managed.
        
                The patch is not based on your latest submission since I did not read your mail before I tried to change it myself.
        
                Thomas
        
        
        Please try again with latest. I did a major refactoring to split the files into managed and unmanaged so that they can be processed just once and separately. This should address your concerns. I am still using my java.io.File based method of determining if the files are read-only. I think the current code works correctly though. It is possible that is not necessary, but it does not really hurt anything.
        
        Mark
        
        
        
        ---------------------------------------------------------------------
        To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
        For additional commands, e-mail: dev-help@subclipse.tigris.org
        
        
Received on Thu Dec 21 14:49:33 2006

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.