[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [stellation-res] Big changes - should we go for it?
|
1. I only saw value in the interim API if it was going to be a significant
time-saver. So far as I am concerned, go for it.
2. The current multi-project structure causes me a lot of pain so I am in
favour of the single Stellation project proposal as well.
Regards
Jonathan
----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: <stellation-res@xxxxxxxxxxxxxxx>
Sent: Sunday, December 14, 2003 4:16 PM
Subject: [stellation-res] Big changes - should we go for it?
>
> 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.
>
> After spending the last few months working on schemas and
> semantics, I've learned a whole lot about how a WVCM-ish
> repository should work. And now, looking at starting to implement,
> I'm realizing that there may be no need for an interim API - once
> you take what I proposed for the interim API, and make the necessary
> adjustments for the SCL comm layer, you wind up with something
> that is semantically, if not operationally, extremely close to WVCM.
>
> WVCM is more complicated than the interim API - but not dramatically
> so. Starting with basic support only for client workspaces, I think it
> will
> take a bit longer to do WVCM than to do the interim API, but because
> they are operationally so different, I would guess that of the code
> that implements the client API level of the system, less than 20%
> would be reusable for WVCM. (The operational layer is really
> quite different, but the same command language can be used
> underneath both.)
>
> So I see very little point in the interim API anymore - WVCM really is
> better,
> and I don't think that we'll gain much by switching from the current API
> to an interim API, and then switching again from an interim to WVCM. I'd
> rather just do the one switch.
>
> I'm pretty convinced that this is the right way to go. Any objections?
>
>
> 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?
>
> -Mark
>
>