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

["Zulli, Joseph S" <Joseph.Zulli@xxxxxx>]

Title: Message

Hi Michael,

 

Thanks for the response,

 

1) I'm pretty sure that validateEdit is not getting called. I will ask my team to verify that one more time.

 

2) It's true we do get notified when a file is being deleted and we can check the file out then, but how do we know if the file going to be recreated or not? Checking out a file before a normal deletion would not make sense. For a normal deletion, the standard behavior is to delete the remote file on the repository as well, not check it out. There needs to be some way to distinguish the two (normal deletions and replacements).

 

Thanks,

Joe 

-----Original Message-----
From: platform-vcm-dev-admin@xxxxxxxxxxx [mailto:platform-vcm-dev-admin@xxxxxxxxxxx] On Behalf Of Michael Valenta
Sent: Monday, September 15, 2003 12:43 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: Re: [platform-vcm-dev] Team provider problems with replacing files

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