[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-vcm-dev] Team provider problems with replacing files
|
Title: Message
OK, I
created a report in Bugzilla. The number is 43189 for anyone who is interested.
Joe
It sounds like it
is a problem if drag and drop does a delete followed by a create instead of a
straight replace. This requirement should be captured in a bug report so it
can be tracked. Joe, if you don't mind, please enter a bug report and post the
number so other interested parties can add themselves to the CC list.
Michael
| Geoffrey M Clemm
<geoffrey.clemm@xxxxxxxxxx> Sent by: platform-vcm-dev-admin@xxxxxxxxxxx
16/09/2003 07:35 AM Please respond to platform-vcm-dev
| To:
platform-vcm-dev@xxxxxxxxxxx cc:
platform-vcm-dev@xxxxxxxxxxx,
platform-vcm-dev-admin@xxxxxxxxxxx Subject:
Re: [platform-vcm-dev] Team provider problems with replacing
files |
(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