[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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