[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] Big changes - should we go for it?
|
At 04:16 PM 12/14/2003, Mark C. Chu-Carroll wrote:
I've got two potentially extremely large changes that I'd like to propose.
First: I think that we should go directly for WVCM, and drop the interim
API.
+1
<snip>
The second big change that I'm proposing is a change in project structure
in the self-hosting repository. I think that it was a mistake to make each
of the Eclipse projects into a separate Eclipse project. With the way that
we'll be changing the repository for WVCM, the number of Eclipse
projects is going to increase significantly - and most of them will almost
always be checked in together.
So I'd like to switch to a single Stellation project in the repository,
with each
of the Eclipse projects as a subdirectory - so in essence, our current
Eclipse workspaces will become the SCM project in Stellation.
This one affects everyone equally, so I'd like to put it to a vote - should
we switch to a single project? Or should we stick with what we're doing now?
I'm not sure exactly what you mean (perhaps there was a typo when you wrote:
"...each of the Eclipse projects into a separate Eclipse project.", I think
you meant "... into a separate Stellation project." ?)
If you're proposing to keep N separate Eclipse plugin projects within a single
Stellation SCM project, that's probably fine (modulo a question or two).
If you're proposing something else, please clarify.
The proposed change will significantly impact the Stellation GUI plugin
design:
The Stellation GUI plugin will need to be revamped to handle sets of
Eclipse plugin projects as a single Stellation CM project. At present,
Eclipse uses a model of one 'Team Provider' instance for each managed
Eclipse project. Each Eclipse project has a hidden .ScmAdmin folder where
Stellation metadata is kept.
To support the proposed scheme, I would probaby use a hidden .ScmAdmin folder
located in the Eclipse root workspace folder, holding metadata for the full
set of managed 'subprojects'. It would probably also be good to tie this in
with the Project Set import/export capability (part of the platform Team
support).
It strikes me that retaining the ability to have individually managed
Eclipse projects (one Eclipse project == one Stellation SCM project)
is still worthwhile. Thus, the revamped Stellation GUI plugin would
need to support both:
1) Exactly zero or one Eclipse-workspace-level "multi-project" Stellation
project.
2) Any number of individual Eclipse-project-level Stellation projects
(the current approach).
This raises another question: should a single Stellation-managed
Eclipse workspace support both a single "multi-project" and one or
more "single-project" entities? Or, should this be an "either/or"
workspace-level choice? (The first option implies a checkbox in the
"Share Project" dialog associated with each managed Eclipse project;
the second option implies a checkbox in an Eclipse workspace-level
Preferences page.
Comments?
-------------------------
Some other observations about the "One Stellation Project To Rule Them All"
proposal:
* This implies every local workspace will contain a copy of all CLI and GUI
code for Stellation. Yes?
* Presumably the STIM and VSF work will remain as separate Stellation SCM
projects?
Regards,
Jim
--------------------------------------------------------------------
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
