[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] IMoveDeleteHooks
|
>>We decided not to use IMoveDeleteHook because of the lack of batch
>>processing.
Note that the intention of IMoveDeleteHook is that it allows you the
provider to in effect implement the Core move and delete methods. These
methods are called at all sorts of times from various parts of the system -
thus the lack of batching. The primary client for this hook was Clearcase
because of their dynamic views and requirement to custom handle local file
system moves which were in reality occuring within their virtual file
system. Also, it allows you to veto the operation. Its very powerful but
low level.
If all you really want is notification then deltas are better since they
are batched. You shouldn't feel you are missing out on anything if you
don't override move/delete :)
The veto case is interesting. Its really a matter of policy whether you
want to allow move/delete to proceed if you can't contact the server, or
checkout the resources from the server. As Vladimir points out, there are
cases where perhaps disallowing the operation is overly severe, so you may
choose to never veto but instead just record/notify.
You may find a combination of deltas for batching and move/delete for
policy enforcement works best.
Kevin
"Vladimir Grishchenko"
<vladgri@xxxxxxxxxxx> To: <platform-vcm-dev@xxxxxxxxxxx>
Sent by: cc:
platform-vcm-dev-admin@ Subject: Re: [platform-vcm-dev] IMoveDeleteHooks
eclipse.org
05/11/2002 03:00 PM
Please respond to
platform-vcm-dev
We decided not to use IMoveDeleteHook because of the lack of batch
processing. We are using resource delta mechanism instead. One problem that
we still have open is you can get a delta notificatin while some other
dialog (like create a new file dialog) is still open and if you try to open
your own dialog it is impossible to get a reference to the correct parent.
The best you can do in this case is to use the default parent which is the
current workbench window. The result is your dialog is shown between
current active dialog and the main window. Yet worse, if your dialog blocks
the thread that opened it, the original dialog has no chance to close until
your dialog closes. Wondering is there a safe way to open a dialog and do a
remote operation on delta notification or may be we are doing something
that
is inherentrly wrong...
Another thing I was curious about is what do you do in the move/delete hook
when there is some sort of repository IO exception, say the connection is
broken or so. Does this mean that local move will also fail? Sounds like a
major inconvenience if someone uses a dial-up to access his repository, or
even worse is on a trip with no means to connect to a repository at all.
Probably a better solution would be to accumulate move/delete delta
information and apply it during next synchronization operation, whatever it
is, or may be even a combination of both...
-Vladimir.
----- Original Message -----
From: "Adam Terrenzio" <adam.terrenzio@xxxxxxx>
To: "IBM-Vcm-Dev (E-mail)" <platform-vcm-dev@xxxxxxxxxxx>
Sent: Tuesday, November 05, 2002 10:53 AM
Subject: [platform-vcm-dev] IMoveDeleteHooks
> We are currently working on a full implementation of the interface.
> Completing the implementation of the Move/Delete hooks has been
interesting
> attempting to get an acceptable user experience.
>
> The moveFile()/deleteFile() methods only give you one file at a time and
> does not allow for batch processing. That means that if the user selects
50
> different files, and then moves them to the same location, we would get
50
> different moves, each possibly requiring a prompt from our version
control
> product for decisions on how to handle it in the repository.
>
> Our prompts have "OK to ALL" buttons on them that allow the user to have
a
> single interaction apply to the entire set of selections (this greatly
> reduces the number of dialogs), but we can't use this in this case
because
> we only get the actions one at a time. What we need is the ability to
hood
> in at a point where we are given the entire selection (api doesn't appear
to
> have this point) or a way to 'simulate' having been called with the
entire
> selection. Is there a way to batch them and then process all at once? I
> could not find a gesture such as MovesComplete to capture (listen to).
It
> would be no problem caching the first answer, the question would be - how
to
> know when everything is done to reset the question? Is there a way to
gain
> access to the selection and then (when we would at least know the
first/last
> element) execute the repository operation for that set?
>
> How would something like this behave within the scope of Refractoring?
Does
> it also construct a Selection object which then gets processed or is it
more
> of a one-at-a-time processing model? Can I just get an array of IFiles
> (source, dest pairs) instead of them singly?
>
> Thanks,
> Adam.
>
> Adam Terrenzio
> Software Developer, MKS Inc., www.mks.com
> Tel: (519)883-3216
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
>
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
