Re: [platform-vcm-dev] Team provider problems with replacing files

[Geoffrey M Clemm <geoffrey.clemm@xxxxxxxxxx>]

(1) In systems that version the file namespace, a
"delete" is not
a modification to the file being deleted, but rather
a modification
to the folder/directory containing the file being
deleted.
That is why it is critical that the editing framework
carefully
(and correctly) distinguish between an update of an
existing file
(which invokes validateEdit), and a delete (which
invokes
the IMoveDeleteHook).

(2) See above.  A system that versions the file
namespace will
checkout the parent directory in the IMoveDeleteHook,
not the
file being deleted.

Cheers,
Geoff


Michael wrote on 09/15/2003 03:43:04 PM:

> 
> Joe, 
> 
> I have two comments on your problem: 
> 
> 1) Even if drag and drop does a delete followed by an add, I think
> that validateEdit should still be called. If this is not the case,
> please log a bug report against Platform UI. Be sure to include 
> which version (and build if 3.0) of Eclipse you are using. 
> 
> 2) Even with the above bug, don't you get an opportunity to do a 
> checkout when the file is deleted (i.e. through the IMoveDeleteHook)?
> 
> Michael 
> 
> 

> 
> "Zulli, Joseph S" <Joseph.Zulli@xxxxxx> 
> Sent by: platform-vcm-dev-admin@xxxxxxxxxxx 
> 15/09/2003 03:20 PM 
> Please respond to platform-vcm-dev 
> 
>         
>         To:        <platform-vcm-dev@xxxxxxxxxxx>
>         cc:         
>         Subject:        [platform-vcm-dev]
Team provider problems 
> with replacing files
> 
> 
> 

> Hi Everyone, 
> I have designed a repository provider interface
that follows the 
> early binding (pessimistic) model. My provider is having problems
> with file replace operations, mainly drag and drop but there are 
> others. I'm hoping to bounce some ideas off of you guys because I'm
> quite stuck as to how to remedy this problem. The problem is as follows:
> 
> -- File contents are not allowed to be changed unless the file is
> checked out first. This is normal early binding behavior. Usually,
> this is not a problem because before the file is modified, my 
> provider will get notification via the IFileModificationValidator
> class's validateEdit() and validateSave() methods. When such 
> notification happens, my provider will check the file out. 
>   
> -- In the case of a file replace, say drag and drop from into the
> Navigator, the file to be replaced will be deleted then re-added.
> The validateEdit/validateSave methods never get called and the file
> never gets checked out. This causes lots of problems when the user
> tries to synchronize their workspace later on. The file gets marked
> as new even though it isn't, and when you try to check it in the 
> check in fails because there is already an existing file with the
> same name and that file was not reserved. 
> I was thinking of the following changes to Eclipse
but I'm not sure 
> if either of them is really the answer. 
> 1)  Instead of doing a delete then add,
just change the contents of 
> the file when doing a replace. That way, a pessimistic provider can
> get edit notification and check the file out. From the user 
> perspective, this is what is happening anyway.   
> 2)  Add a new team notification to the IMoveDeleteHook
for replace, 
> a replaceFile method or something like that. This will allow an SCM
> provider plugin to set up for a replace operation. It would not 
> matter whether the calling plugin performs the replace using the 
> delete/add or update contents method as long as the provider has 
> some way of knowing beforehand that there is a replace going on. 
> What do you guys think? Does anyone have any
other input or 
> workarounds? I would sure appreciate it. I suspect that this problem
> is being faced by many SCM providers and may be faced by more to 
> come if we don't come up with a solution. 
> Thanks, 
> Joe