Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stellation-res] Big changes - should we go for it?

On Dec 15, 2003, at 11:53 AM, Jim Wright - IBM Research wrote:

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.

That's right - I meant to say all of the Stellation Eclipse plugins as
a single Stellation project in the repository.

The proposed change will significantly impact the Stellation GUI plugin
design:

Actually, it really shouldn't. WVCM is sufficiently powerful and
flexible that by using it, we can actually solve that problem
gracefully!

WVCM doesn't really have any notion of "projects" as such. In
it's place, it has baselines. And baselines are required to support
sub-baselines.

An Eclipse "project" should be mapped to a Stellation WVCM
baseline. The system shouldn't care that it's actually a sub-baseline.
(In fact, to make things really convenient, there actually is no
namespace requirement on sub-baselines, meaning that you
can have the following setup:

Eclipse projects in an Eclipse workspace:
	workpsace/org.eclipse.stellation.wvcm.client
	workspace/org.eclipse.stellation.wvcm.server
	workspace/org.eclipse.stellation.newstore
	workspace/org.eclipse.stellation.team.ui
	workspace/org.eclipse.stellation.team.model

Each of the above projects corresponds to a baseline.

And then, in the same workspace, have another Eclipse
project "workspace/org.eclipse.stellation", which corresponds to
a baseline which has all of above the plugin projects as sub-baselines.

So in the Eclipse UI, you could just select the "org.eclipse.stellation" project,
and make a baseline of it to capture a total baseline of the system.

And there's no reason for component developers to even need to know
that that's going on: they just retrieve and checkin versions of the
components that they're working on.

	-Mark


Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM Research
***      http://stellation.eclipse.org
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxx



Back to the top