[platform-vcm-dev] .project and .classpath modification notification

[Kevin_McGuire@xxxxxxxxxx]

We've now closed this bug report.  Since validateEdit/validateSave are a 
bit complex I thought I should provide information here for the community 
so that other's won't get tripped up by this.


Pessimistic providers must watch for both validateEdit and validateSave. 
You cannot assume that validateEdit is called prior to every file 
modification.  You can however rely on validateSave being called.

ValidateSave is called from deep with core resources.  When a file is 
saved (specifically, when setContents() is called), Core initiates the 
validateSave callback and Team notifies the provider registered for that 
file's project.  Thus you are guaranteed to get a validateSave() 
notification, always.

However, this save notification is insufficient for the following cases:

1. You are in an interactive editor of some kind.
2. Several files are being modified, and should one checkout fail you 
would like to fail the entire operation.

In case 1, you would like the file to be checked out as soon as you start 
modifying its contents in the editor (ie. as soon as you start typing). If 
by contrast the check out attempt didn't happen until the file was saved, 
the user could be stuck with uncommitable edits, which is a somewhat 
disagreeable situation for the user.  For this reason eclipse text editors 
call validateEdit() on first keystroke.

However, for property pages and other automated processes, its perhaps 
nice but not necessary for the caller to do a validateEdit prior to 
resource 
modification.  This is because the file changes are made and applied 
(saved) in the same operation, so case 1 above doesn't occur.  Thus 
callers may rely on validateSave.  It should also be mentioned that 
validateEdit() relies on the good graces of the caller to invoke, while as 
validateSave() is guaranteed to get called.

The second case is a side effect of the fact that validateSave is only 
called on a single file (since its called from the file save code).  But 
in cases like JDT refactoring which often affects several files, you want 
failure to check out all the files to fail the refactoring.  Otherwise the 
user will be left with a partial refactoring which may be difficult to set 
straight.  Since validateEdit() takes an array of IFiles, then refactoring 
and others call it at the start of the operation.


Thus although a provider *usually* gets validateEdit() notifications, they 
must also handle validateSave.


We will try to make sure that there is better doc in either the 2.1 isv 
guide or online in the VCM web pages.

Cheers,
Kevin

---------------------------------------------------------------------------------------------------



Recently we've received the following bug report which sounds similar to 
your case: 

http://bugs.eclipse.org/bugs/show_bug.cgi?id=29414 

We will be investigating this bug report, so if it sounds the same please 
feel free to add yourself to the CC. 

Kevin 





"Vladimir Grishchenko" <vladgri@xxxxxxxxxxx> 
Sent by: platform-vcm-dev-admin@xxxxxxxxxxx 
02/05/2003 12:20 PM 
Please respond to platform-vcm-dev 
        
        To:        <platform-vcm-dev@xxxxxxxxxxx> 
        cc:         
        Subject:        [platform-vcm-dev] .project and .classpath 
modification notification 




Hello,

We found a little problem while versioning .project and .classpath files.
Our repository provider is "pessimistic" and local files are kept in
read-only state until they are checked out. We do not get a chance to
perform any action to clear read-only flag because there is no 
modification
notification whenever project properties are modified thorough the project
property page. The result is that project property modification fails with
an error saying that project file is read-only and cannot be modified. Did
anyone get this problem before?

Thanks,
Vladimir.