[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Re: Envy config map like feature for Eclipse
|
Same for me, I'll be off until the 30st of September. We'll probably not
start anything before, so lots of time to re-think, but then something will
happen either way...
Ciao,
Rolf
"Kevin McGuire"
<Kevin_McGuire@xxxxxxx> To: platform-vcm-dev@xxxxxxxxxxx
Sent by: cc:
platform-vcm-dev-admin@e Subject: Re: [platform-vcm-dev] Re: Envy config
clipse.org map like feature for Eclipse
05.09.02 23:09
Please respond to
platform-vcm-dev
I will be away on vacation until Tuesday Sept. 17. I am very interested in
continuing this discussion and seeing if we can actually make something
happen. I just wanted to make sure that my silence in the next 12 days
wasn't interpreted as disinterest :)
Cheers,
Kevin
"Rolf Wilms"
<rwilms@xxxxxxxxxxxxxx> To:
platform-vcm-dev@xxxxxxxxxxx
Sent by: cc:
platform-vcm-dev-admin@ Subject: Re:
[platform-vcm-dev] Re: Envy config map like
eclipse.org feature for Eclipse
09/03/2002 02:32 PM
Please respond to
platform-vcm-dev
Hi Kevin,
thank you for your analyis. Let me first respond to specific issues and
then propose an approach.
1. Solution for all repository types or CVS-specific
As far as it concerns our efforts, we can only support CVS. This doesn't
mean that it must be a CVS-specific solution, we just do not have the
resources, knowledge or funding to support non-CVS right now. But it is in
our interest to keep the solution open to other repository types. We
probably could live with the restrictions imposed by only using
IProjectSetSerializer (with a few extensions) as the least common
denominator.
2. How to specify project set references
I like to 'defend'/refine the proposed solution of using a special project
type (nature) for the specification of recursive project sets. This
special project would contain a single team set file (maybe with extensions
to the existing format) with a fixed name.
Thus, a reference to this team set file would just be a reference to the
project and project references already exist by the IProjectSetSerializer.
In terms of CVS, if I want an un-ambiguous reference, i'd reference a
version of the project. And, again in terms of CVS, I can also reference a
team set file on HEAD or a branch this way (similar to unversioned editions
of config maps in Envy).
In contrast, if I wanted to make a reference to a particular
revison/version of a team set file directly, this would be a substantial
extenstion to the existing APIs. Additionally, if different versions of
team set files residing within the same project were referenced / loaded,
versioning the project itself would make little sense.
The effect of cluttering the project name space is there, however
- the amount of extra projects should be a fraction of the existing
projects only
- so repositories should have no problem dealing with the extra projects
- using filters and working sets the impact on what the user sees can be
kept small
A compromise could be to allow references to team set files which reside in
the same project as the referencing file, additional to a 'main' team set
file. The revision/version of these additional files would be defined by
the project they reside in (just as the 'main' team set file), the
reference wouldn't carry version information.
The existing import and export of team set files can be kept as it is.
3. Project set entries are opaque
This is in fact a problem. What we need at least is test two project
references for equality. This is required to check for conflicts, to check
if a project in the workspace is the same as the project reference in a
team set file and for merging. A project reference string produced by
asReference might itself be tested for equality, but this would only be an
assumption, so here we'd need an extension to the APIs.
If we keep the restriction that only loaded projects can be added to a
team set file, we could also add the project name for display purposes
along with the reference. However, i.e. version information would be
missing then, which is not practical when merging, displaying conflicts or
displaying project references for projects not in the workspace.
Thus another API extension needed would be to get a printable string for a
project reference. This can be specific to the repository type and include
the kind of information a user would need to identify the project in the
respective repository. So no need to have a canonical description.
4. Binary projects
I cannot really comment on this right now. Is it correct that binary
projects cannot be included in a team set today?
5. Moving a repository to another server could invalidate project sets
From my VASt Envy experience I know that configuration maps were an
important part of projects. It would be bad to lose them just because the
repository has been moved to another server, but this would happen with the
current way team set files / IProjectSetSerializer work, at least with CVS.
I haven't thought about this issue too much though.
6. An appoach
Using special projects holding team set files and two new API functions -
test project references for equality, obtain a (repository type specific)
display string for a project reference - we could make one first step. This
step would include:
- defining project sets as special projects
- displaying the contents of a project set including 'version' information
- (recursive) loading of projects defined in project sets
- displaying conflicts
- adding / replacing projects in a project set using projects existing in
the workbench
- removing projects from a project set
- merging project sets
Later steps could add:
- adding / replacing projects in a project set using projects existing in a
repository
- import / load of binary projects
- "qualified versioning", means a team set can only be 'versioned' if all
referenced projects are 'versions' (needs a test if a project reference is
a "version")
As to the implementation of the first step, the required API extension
could be provided as an extension point in the 'project set' plugin. For
CVS, this could easily be done. This way we could implement the first step
without any necessary changes to the existing APIs. After the first step
has been completed, we can decide if it should go into the SDK or
whereever.
To me this approach seems to be appealing because it seems to be low-risk.
But, no risk no fun, so please be critical. I.e. I dont't know how
difficult it would be to implement the two API extensions for other
repository types.
Regards,
Rolf
"Kevin McGuire"
<Kevin_McGuire@xxxxxxx> To:
platform-vcm-dev@xxxxxxxxxxx
Sent by: cc:
platform-vcm-dev-admin@e Subject:
[platform-vcm-dev] Re: Envy config map
clipse.org like feature for
Eclipse
30.08.02 22:00
Please respond to
platform-vcm-dev
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.
Kevin
=====================
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.
Kevin
_______________________________________________
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
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
