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

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

I strongly support (1), i.e. drag and drop should
be an "edit"
operation, not a "delete/insert" operation.
 In particular, if
the system knows enough to invoke a MoveDeleteHook,
it knows
that it should be issuing the "edit" operation.

This kind of problem has occurred in various places,
i.e. where
the editing framework issued a "delete/insert"
when it should have
issued either an "edit" or a "move".
 In each of these cases, the
editing framework should be fixed (i.e. to issue the
"edit" or 
"move", whichever is appropriate), so that
a Team provider is given
an accurate description of what has happened, and
therefore has
an opportunity to do the right thing.

Cheers,
Geoff 

platform-vcm-dev-admin@xxxxxxxxxxx wrote on 09/15/2003
03:20:22 PM:

> 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