[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-11 21:09:17 CET

Hi again,
 
I just updated and debugged the code.
 
The isReadOnly method does not what it should. file.getFullPath().toFile(); evalutes to a path that is missing the workspace root an thus is always treated as read only.
 
But please have a look at the following code again and my comments.
 
public IStatus validateEdit(IFile[] files, Object context) {

String comment = "";

boolean stealLock = false;

// reduce the array to just read only files

IFile[] readOnlyFiles = getReadOnly(files); <- Ok these are the read only files

int managedCount = readOnlyFiles.length;

SVNTeamProvider svnTeamProvider = null;

RepositoryProvider provider = RepositoryProvider.getProvider(files[0].getProject());

if ((provider != null) && (provider instanceof SVNTeamProvider)) {

IFile[] managedFiles = checkManaged(files); <- These are the managed files. The can be read only or writable.

managedCount = managedFiles.length;

if (managedCount > 0) { <- the condition is true for the writable files that are managed too!

if (context != null) {

ISVNFileModificationValidatorPrompt svnFileModificationValidatorPrompt =

SVNProviderPlugin.getPlugin().getSvnFileModificationValidatorPrompt();

if (svnFileModificationValidatorPrompt != null) {

if (!svnFileModificationValidatorPrompt.prompt(managedFiles, context)) <- This is were the dialog gets trigged.

return Status.CANCEL_STATUS;

comment = svnFileModificationValidatorPrompt.getComment();

stealLock = svnFileModificationValidatorPrompt.isStealLock();

}

}

svnTeamProvider = (SVNTeamProvider) provider;

LockResourcesCommand command = new LockResourcesCommand(svnTeamProvider.getSVNWorkspaceRoot(), managedFiles, stealLock, comment);

try {

command.run(new NullProgressMonitor());

} catch (SVNException e) {

e.printStackTrace();

return Status.CANCEL_STATUS;

}

}

}

// This is to prompt the user to flip the read only bit

// on files that are not managed by SVN

if (readOnlyFiles.length > managedCount) { <- OK if there are more read only than managed there must be some read only not managed

synchronized (this) {

if (uiValidator == null)

uiValidator = loadUIValidator();

}

if (uiValidator != null) {

return uiValidator.validateEdit(files, context); <- Is this correct? Shouldn't only the files not managed and read only be passed here?

}

// There was no plugged in validator so fail gracefully

return getStatus(files);

}

return Status.OK_STATUS;

}

 
Thomas

________________________________

From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Mon 11.12.2006 16:02
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:

        Hi Mark,
        I am away from my computer right now but I think that that change from IFike to File won`t be enough since the Code is prompting for each file managed no matter what the result of determining the read only files is.
        
        I will have a look at the resource rule factory but I did not see it involved but I will check again.

I think that RSA is telling Eclipse that the file is read-only. That is why all of these checks that should be eliminating the file are not working. They are all using the same internal Eclipse cache. By using the Java File object it will fix it unless the files really are read only. In which case, it is all working properly anyway.

I'd all but guarantee this change will fix it.

Mark

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

Received on Mon Dec 11 21:21:11 2006

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