| 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 ... > 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 > _______________________________________________ > platform-vcm-dev mailing list > platform-vcm-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev -- Mark Craig Chu-Carroll, IBM T.J. Watson Research Center <mcc@xxxxxxxxxxxxxx> *** The Synedra project: http://domino.research.ibm.com/synedra/synedra.nsf *** GPG Public key available at keyserver.net
Attachment:
pgpSyYaGUq68P.pgp
Description: PGP signature