Re: [platform-vcm-dev] FW: Separating the "VCM-GUI hooks/callbacks" from

[Kevin_McGuire@xxxxxxx]

>> I was under the impression that the TeamProvider
interface was intended to be somewhat more generic, so that a system
significantly richer than CVS could be integrated into the framework
by implementing ITeamProvider.

The intent was that ITeamProvider described the subset by which you could 
deal generically with any repository.  It would therefore be one of the 
pieces needed to support a generic UI.

But yes, the story also said that if you wanted your repository's model to 
be better represented, then you were free to do so and ITeamProvider 
wouldn't help you here.  In this case the value of ITeamProvider would be 
that any plugin could make VCM calls without knowing the underlying repo 
type.  Realistically though the usecases for scripted repo-neutral VCM are 
small and not clear to us, so this is being de-emphasized.

Kevin McGuire







"Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
Sent by: platform-vcm-dev-admin@xxxxxxxxxxx
12/10/2001 07:18 PM
Please respond to platform-vcm-dev

 
        To:     platform-vcm-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-vcm-dev] FW: Separating the "VCM-GUI      hooks/callbacks" 
from the "TeamProvid er" API

This is basically the way that I've understood the VCM work. The main
difference is that I was under the impression that the TeamProvider
interface was intended to be somewhat more generic, so that a system
significantly richer than CVS could be integrated into the framework
by implementing ITeamProvider. (To be honest, I still haven't had time
to take a detailed scan through the VCM interfaces, and this could be
why I expected ITeamProvider to be more generic.)

While I haven't looked at the code, a member of my team has, and from
what he's told me, I think that the 2.0 stream ITeamProvider is used to
implement the 2.0 CVS plugin.

I definitely agree with you that the goal should be to have the UI avoid
directly calling ITeamProvider, and rather use the most generic VCM-GUI
hooks that provide the necessary function.  I'm particularly in favor of
this, because my system is sufficiently different from what's done 
in most other systems that unless the standard interfaces are extremely
generic, there'll be no way to really take advantage of what we provide 
using the standard components.

                 -Mark Chu-Carroll


On Sun, 2001-12-09 at 10:27, Clemm, Geoff wrote:
> Currently there appear to be 3 related projects taking place in the
> VCM project.
> 
> 1) A set of VCM-GUI hooks and callbacks that allows a rich integration
>    between an editor and a team repository provider.  These VCM-GUI
>    hooks defines a set of hooks that an editor/IDE must invoke at the
>    appropriate times, and a set of callbacks that an editor/IDE must
>    implement.  Conversely, a team repository provider must implement
>    the hooks, and must invoke the callbacks at the appropriate times.
>    An example of a hook that an editor/IDE must invoke (these aren't
>    the actual names) is "validateEdit()", when it first modifies a
>    buffer associated with a file.  An example of a callback that an
>    editor/IDE must implement is "fileHasChanged()", when a team
>    repository provider has updated one of the files in the workspace.
> 
> 2) A CVS VCM provider, that provides a CVS implementation of the
>    VCM-GUI hooks and callbacks.
> 
> 3) An implementation of the VCM-GUI hooks that calls a simple generic
>    "TeamProvider" API.  Unlike the VCM-GUI hooks, (which assume that
>    GUIs will pop up when many/most of the hooks are called), the
>    TeamProvider API is a "headless" API, i.e. no GUI's will pop up.
>    The purpose of this implementation is to make it easy to write a
>    simple team repository provider, since all the GUI code has been
>    written, and the team repository provider only implements the
>    TeamProvider interface.  Question: Is the CVS VCM provider based on
>    this generic GUI that invokes the TeamProvider interface, or does
>    it have its own custom GUI that doesn't go through the TeamProvider
>    interface?
> 
> I believe it is very important (both for repository vendors, and for
> users of Eclipse) that we clearly separate these three projects.  In
> particular, the editors and IDEs should only call the VCM-GUI hooks,
> and should not directly invoke the TeamProvider interface.  The reason
> this is important for repository vendors is that the TeamProvider
> interface is incompatible with core functionality of advanced CM
> repositories (e.g. it does not support versioned namespaces, it does
> not support versioning at the project level, it does not support
> change-set based behavior, it does not support sophisticated file area
> management, and it does not support server-side merging).  The reason
> that this is important for an Eclipse user is that if an editor/IDE
> invokes both the VCM-GUI hooks and the TeamProvider interface, then
> the user will be seeing two incompatible sets of GUI's for the same
> repository operations (i.e. the GUI defined by the editor/IDE for the
> TeamProvider interface, and the GUI defined by the repository vendor
> for the VCM-GUI hooks).
> 
> This separation actually simplifies the job of editor/IDE tool writers 
..