RE: [platform-vcm-dev] Re: Envy config map like feature for Eclip se

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

To make this comment more concrete, the WVCM API models an Eclipse
project as a "configuration" (it avoids the term "project" because of
potential confusion with "project planning", such as is done in
"Microsoft Project").  A "project version" is called a "baseline".

In addition, if project naming is being maintained on the server, and
especially if that naming is being version controlled (i.e. you can
ask the server what a project used to be named), then the namespace
versioning being done by the server is intimately connected with an
effective config-map like feature for Eclipse.

Cheers,
Geoff


-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@xxxxxxxxxxxx]

I suggest that this problem be solved in the context of a 
general "standard versioning API" context, since it is intimately
connected with issues such as versioned namespaces and baselines
(aka "project versions").


-----Original Message-----
From: Kevin McGuire [mailto:Kevin_McGuire@xxxxxxx]

General note:  This is a discussion that was started in the newsgroup.
Rolf says that he's now also posted it here, but I haven't seen it, so I am
posting here my answers to his comments from the newsgroup.

=====================

Hi Rolf,

This is a good discussion.  My comments below.

> > Q: Are you talking about config maps for any repository type, or just
for
> > CVS?  If any, how did you envision it would work (ie. what would the
API
> > look like for providers?).
>
> The plan is to use the IProjectSetSerializer to reference / load
projects.
> If this is possible, all repository types providing an
> org.eclipse.team.core.projectSets extension should work.
> If this is not possible, we'd have to implement our own mechanism to
> reference / load projects. We would implement one for CVS and might
provide
> an extension point so that other repository types could add their
reference
> / load mechanism.

It would be interesting to springboard off of IProjectSetSerializer since
there are already implementations of it. That's assuming we could as a
community come to an agreement over how it should work.  There are of
course complications inherent in trying to extend the existing use of an
interface (if you want to maintain API compatibility), but I am hoping we
can resolve that.  We can then decide if it should be part of the SDK or
not.  In general we've avoided putting into VCM things that provide a
different workflow than the underlying repository.  In the case of project
sets, we put them in because it was clear that many repositories don't
provide a solution that can be used by the IDE and that this was a real
pressing problem for many, in particular for our early Clearcase adopters.
But this area is a slippery slope and I want to avoid trying to make all
repositories work like Envy because that's what we are familiar with,
unless again we can argue that a specfic area is a deficiency of all
repositories and that the community of provider writers want this.

An alternative is that we just solve it for CVS, which is a lot easier and
requires a lot less discussion :)


> After all, the planned "config map like feature" is not that different
from
> TeamSets. It would basically add management of  TeamSet files in their
own
> projects, nesting/recursive loading, showing conflicts and differences to
> the loaded state.


Issues
=======

What is missing currently:

1. project sets cannot refer to each other
2. each entry is opaque and can only be interpreted by the provider
3. consequently, the entries can't be generically printed or manipulated
(e.g. edit/merge of a project set)
4. the project set itself is not versioned, but rather is a file that can
be under version control (this affects semantics of recursive
referencing/loading which we can discuss).
5. because of (3), you can only ask for the project set entry for a project
currently in the workspace.  There is no facility for asking for "other
editions" of a project.  This restricts your ability to construct and edit
project sets.
6. there is no PDE client of project sets for describing required binary
projects (but perhaps could be).  The idea here is that you would have stop
description that would both load projects from the repo and import the
binary ones.

Most of these are not hard to solve, although its not clear how to do that
without API breakage to IProjectSetSerializer.  We should perhaps ignore
that issue for the moment, design what we believe to be the right solution
assuming we could change IProjectSetSerializer, then return to that problem
once we believe we've solved the general problem.

Issue #2, #5:

The inherent problem is that there is no cannonical description of a
project in a repository, or its history.  We spent some time trying to come
up with an API for this but its just too difficult because the 'context' in
which a project lives in a repository can be vastly different depending on
the repository type.  For example, in CVS projects live in modules and you
have branches, while as in Clearcase you have VOB's, development streams
vs. integration streams and accompanying workflows/lifecycle, etc., and
PVCS is different again.  This is why you can't ask the question in point
#5 above.


Issue #1, #3:  ProjectSet recursive referencing:

One solution (which I think Rolf mentioned) was that "Config Maps" could be
special projects, perhaps marked so via a nature. Since Project Sets have
references to projects in repository, one can imagine loading one project
set, examining the resulting projects to see if they ProjectSetProjects,
and loading them recusively.

However, one nice thing about current ProjectSets is that they are just a
file and so can be shared in a variety of ways.  For example, I can email
someone a project set which has "everything they need to get started".  In
addition, you can avoid cluttering your project name space by having all
your project sets in one project under version control.

I think its pretty clearly a requirement that a "ProjectSetReference" must
resolve itself to a particular revision of the file.  That is, its not
enough to just name the required project set, but you need to point to an
exact revision/state of it so that you can build un-ambiguous maps.



> > Q: Are you interested in doing this work as part of the Eclipse open
> source
> > effort, perhaps as part of the SDK or perhaps as an add-in?
>
> Yes, we are interested in doing this work as part of the Eclipse open
source
> effort and we do have management support for this.

Excellent!  As I said, we are interested in this so having external
contributors will increase the chances of a solution occuring.

> The plan is to provide
> one or more plug-ins which can simply be added. If these plug-ins could
be
> moved into the SDK, even better.


> > Q: As you know, project's can have references to other projects.  Do
these
> > factor in in any way?
>
> Not necessarily. In the first place I would see config maps and project
> references as independent. But there may be exceptions, i.e. when adding
> projects to a config map, it might be a useful option to automatically
add
> referenced projects to that map.
>
> I also do not think that project references need to influence the project
> load order. After a load has been completed, a build can be done.

I suspect this is the right approach.  Originally (pre 0.9) we expected
that the project references would/could be qualified to specific project
versions.  Thus we didn't need config maps, just projects and version
qualified references.  However, we didn't understand how to do this
generically (ie. describe and load them, as per discussion above).
Secondly, we used to have something similar in early Envys ("application
compatibility") but it turned out to be a problem, and these problems might
reappear.  I suspect its better to have the versioning referencing above
that of the projects involved, since it allows you to modify the lineups
without modifying the actually projects. This reflects better the typical
development process, where for example the current version of say the VCM
Core projects are dependent on the current version of the rest of the SDK,
which isn't yet versioned.  That is, when I version VCM Core for a build,
the SDK Core and UI projects probably aren't versioned at that moment so I
can't refer to the specific versions in my project.  Its only when
everything is versioned, built, and tested that you can say "Yes, all these
specific project versions work together".

That said, we have:

- project references
- project "versions" (or branches, or whatever)
- plugin version #s
- plugin requires references
- (and now proposed:) project map references

and we need to keep a careful eye to how these should work together in an
understandable and 'harmonious' manner.