Eclipse Community Forums: Technology Project and PMC » Is Stellation ready for production use ?

Help

Home

Home » Eclipse Projects » Technology Project and PMC » Is Stellation ready for production use ?

Show: Today's Messages :: Show Polls :: Message Navigator

Is Stellation ready for production use ? [message #2576]

Sun, 07 July 2002 18:34

Eclipse User

Originally posted by: markus_kohler.gmx.net

Hi,
It seems that given Stellation's list of features that it could be already
a good replacement for CVS.

I would be interested to hear about how stable and how scalabale
Stellation is today (any experiences with larger projects ?) and if we
will have to expect incompatible changes within the near future.

I would also like to know wether Stellation is specfic to Java or if it
could also handle C++,XML or other text based source code.

Regards,
Markus

Report message to a moderator

Re: Is Stellation ready for production use ? [message #2605 is a reply to message #2576]

Sun, 07 July 2002 07:39

Mark C. Chu-Carroll

Messages: 64
Registered: July 2009

Member

On Sun, 07 Jul 2002 14:34:35 -0400, Markus Kohler wrote:

> Hi,
> It seems that given Stellation's list of features that it could be
> already a good replacement for CVS.

Thanks! That's what we hope.

> I would be interested to hear about how stable and how scalabale
> Stellation is today (any experiences with larger projects ?) and if we
> will have to expect incompatible changes within the near future.

We still consider Stellation to be pre-alpha code. We're just starting to
use it ourselves, inside of the IBM lab. (We're going to be reconciling
our changes with the public CVS repository daily.)

It's close to the point where a small group could use it. But I'd give us
a month or two of testing the self-hosting before I'd really declare it
ready for anyone else.

I know that a month of two sounds ambitious, but because of the way that
we use an RDB for storage, we gain a huge amount of trustworthiness. We've
had Stellation working for over a year, and in a full year of testing,
including tests deliberately designed to trip up the system, we've never
lost a byte of data. I don't mean that to praise us as being particularly
smart or skillful (not that we're not!) - but that's really coming from
the way that we're using a structured set of RDB tables to store things.
Because of that structure, and the fact that a checkin is an atomic unit,
it's very hard for us to lose data. So for potential users, data loss
shouldn't be a serious worry. I'd still make careful periodic backups
of the database, just in case...

For future incompatibilities: our storage structure has been very stable.
In the last year, we haven't made any backwards incompatible database
changes. I anticipate one upcoming change, now that we have metadata
properties working. For that, we'll provide a conversion script to copy and
convert repositories for the change.

As far as scalability: we've done tests with checking in the entire Linux
kernel, with all the modules. No problem. It took a while, because we're
still a bit slow. But it worked, cleanly, without any problem.

We have *not* yet tried out any tests involving large numbers of users. My
one concern in that area is that we're still a bit on the slow side, so
there could be scalability issues in dealing with lots of blocked waiting
connections on the repository.

> I would also like to know wether Stellation is specfic to Java or if it
> could also handle C++,XML or other text based source code.

The current state of the system, with file granularity, is a completely
generic SCM system. It can store both text and binary data, regardless of
format.

The fine-grained support that we'll be starting on next will be language
specific. But the way that we'll be doing it, the language specific code
will be part of a semantic component, and it will be relatively easy to
implement semantic components for new programming languages.

(Of course, C++ will be a problem. Because of the syntax, and the way that
macros work, getting fine-grained support implemented for C++ will be
quite difficult to do correctly.)

-Mark

--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: mcc@watson.ibm.com ------- Personal Email: markcc@bestweb.net

Report message to a moderator

Re: Is Stellation ready for production use ? [message #2634 is a reply to message #2605]

Mon, 08 July 2002 08:59

Markus Kohler

Messages: 3
Registered: July 2009

Junior Member

Thanks a lot for the detailed answer.

Sounds great !

Regards,
Markus

Mark C. Chu-Carroll wrote:
> On Sun, 07 Jul 2002 14:34:35 -0400, Markus Kohler wrote:
>
>
>>Hi,
>>It seems that given Stellation's list of features that it could be
>>already a good replacement for CVS.
>
>
> Thanks! That's what we hope.
>
>
>>I would be interested to hear about how stable and how scalabale
>>Stellation is today (any experiences with larger projects ?) and if we
>>will have to expect incompatible changes within the near future.
>
>
> We still consider Stellation to be pre-alpha code. We're just starting to
> use it ourselves, inside of the IBM lab. (We're going to be reconciling
> our changes with the public CVS repository daily.)
>
> It's close to the point where a small group could use it. But I'd give us
> a month or two of testing the self-hosting before I'd really declare it
> ready for anyone else.
>
> I know that a month of two sounds ambitious, but because of the way that
> we use an RDB for storage, we gain a huge amount of trustworthiness. We've
> had Stellation working for over a year, and in a full year of testing,
> including tests deliberately designed to trip up the system, we've never
> lost a byte of data. I don't mean that to praise us as being particularly
> smart or skillful (not that we're not!) - but that's really coming from
> the way that we're using a structured set of RDB tables to store things.
> Because of that structure, and the fact that a checkin is an atomic unit,
> it's very hard for us to lose data. So for potential users, data loss
> shouldn't be a serious worry. I'd still make careful periodic backups
> of the database, just in case...
>
> For future incompatibilities: our storage structure has been very stable.
> In the last year, we haven't made any backwards incompatible database
> changes. I anticipate one upcoming change, now that we have metadata
> properties working. For that, we'll provide a conversion script to copy and
> convert repositories for the change.
>
> As far as scalability: we've done tests with checking in the entire Linux
> kernel, with all the modules. No problem. It took a while, because we're
> still a bit slow. But it worked, cleanly, without any problem.
>
> We have *not* yet tried out any tests involving large numbers of users. My
> one concern in that area is that we're still a bit on the slow side, so
> there could be scalability issues in dealing with lots of blocked waiting
> connections on the repository.
>
>
>>I would also like to know wether Stellation is specfic to Java or if it
>>could also handle C++,XML or other text based source code.
>
>
> The current state of the system, with file granularity, is a completely
> generic SCM system. It can store both text and binary data, regardless of
> format.
>
> The fine-grained support that we'll be starting on next will be language
> specific. But the way that we'll be doing it, the language specific code
> will be part of a semantic component, and it will be relatively easy to
> implement semantic components for new programming languages.
>
> (Of course, C++ will be a problem. Because of the syntax, and the way that
> macros work, getting fine-grained support implemented for C++ will be
> quite difficult to do correctly.)
>
> -Mark
>
>

Report message to a moderator