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

["Clemm, Geoff" <gclemm@xxxxxxxxxxxx>]

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 ...
they implement just the VCM-GUI hooks and callbacks, and don't
have to even be aware of the TeamProvider API.  A repository provider
would probably want to look at the TeamProvider API and if it maps
reasonably well to their repository, they might be able to re-use part
or all of the "generic" VCM-GUI implementation, and just implement
themselves the TeamProvider API.  Alternatively, a repository provider
might decide to just ignore the TeamProvider interface and just
implement the VCM-GUI hooks and callbacks directly (that is for
example, what we will be doing for ClearCase).

Do folks agree with this characterization of the VCM work?  If so, I
think it is very important to clearly distinguish the VCM-GUI
hook/callback interface from the generic and CVS VCM-GUI hook/callback
implementations, and make it clear to editor/IDE writers that they
MUST implement the VCM-GUI hook/callbacks, and MUST NOT invoke the
TeamProvider API (the TeamProvider API is only for repository
implementors).  One possibility would be to actually separate these
three projects (or make the generic and CVS implementations be
sub-projects of the VCM project).

Cheers,
Geoff Clemm
Chief Engineer, ClearCase Business Unit, Rational Software