Home » Eclipse Projects » Technology Project and PMC » [Stellation] Why reinvent the wheel?
| [Stellation] Why reinvent the wheel? [message #13165] |
Mon, 29 July 2002 13:49  |
Eclipse User |
|
|
|
Originally posted by: d.theisen.gmx.net
Hi!
It seems like Stellation follows the same goals (being a better cvs) as
subversion, a promising and far developed open source project available at
<http://subversion.tigris.org/>.
So what's the point? Stellation seems to be a waste of resources to me.
Regards,
Dirk
|
|
| | |
| Re: [Stellation] Why reinvent the wheel? [message #13331 is a reply to message #13165] |
Mon, 29 July 2002 20:12  |
 Mark C. Chu-Carroll
Messages: 64
Registered: July 2009 |
Member |
|
|
On Mon, 29 Jul 2002 09:49:42 -0400, Dirk Theisen wrote:
> Hi!
>
> It seems like Stellation follows the same goals (being a better cvs) as
> subversion, a promising and far developed open source project available
> at <http://subversion.tigris.org/>.
>
> So what's the point? Stellation seems to be a waste of resources to me.
Stellation absolutely doesn't have the same goals as SubVersion.
I think that saying Subversion is just trying to be a better CVS is
underselling it a bit. I think Subversion wants to do more than that.
But what they are trying to do is to be a traditional SCM system. In
many ways, the open-source community is a good twenty years out of date
when it comes to SCM; I think Subversion is trying to give the OSS
community a good, solid, modern SCM system.
That's not Stellation's goal. Stellation is a research project which
is trying to create a fundamental change in how programmers view and
manipulate source code, and to create a very different environment
that makes it easier for groups of programmers to work cooperatively
on large projects.
It happens that the first step along the way to our goal is to test
our infrastructure by providing something like a conventional
SCM system.
Because of the difference in goals, we have fundamentally different
architectures. Stellation is an almost bizzarely extensible system. The
core of the Stellation repository doesn't understand files or
directories. It just has a minimal notion of "versioned stuff".
Everything is provided through extension modules. In the command
line SVC tool, we load extension modules for text files, binary
files, symbolic links, and directories.
Subversion is modelled on a versioned file system. The notion of
files and directories is an intrinsic part of Subversion. They are
designed to be extendible, but not to nearly the degree of Stellation.
Stellation uses an RDB for storage. Using the RDB means that it's easy
to add new types of things to the system, and to use SQL queries to
access and retrieve them - but there can be a penalty in terms of
speed and size. Subversion uses BerkeleyDB, which gives them more
compact storage, and potentially greater speed, but at the cost of
making the internal data structures significantly harder to
manipulate.
Stellation is intended to do fine-grained versioning, and what we
call dynamic program organization, giving programmers the ability
to dynamically create new views and organizations of thier code.
Subversion is intended to work with traditional file systems.
Stellation is intended to understand the notion of multiple
projects in a single repository, with heirarchical
subprojects in each project, and with distinct consistent histories
for each project and each nested subproject. Subversion only
recognizes one history for the entire subversion filesystem, with
subprojects existing solely by convention.
Stellation is designed from the ground up with the notion of supporting
a very broad notion of metadata, particularly in the form of
inter-artifact relationships and aggregates. (Take a look at the
publications section of our website for details.) Subversion isn't: it's
intended to do a really good job of managing a versioned filesystem.
None of this is intended as a slam against Subversion. I think
subversion is a very interesting project, and I think very
highly of the people that I know who are working on it.
But I don't see us as working on competing systems. Stellation
isn't trying to do what Subversion is trying to do, and Subversion
can't do what Stellation is trying to do. If I thought our goals were
compatible, I would have joined forces a long time ago, but they
aren't. If I were to submit patches to Subversion to give it Stellation
like capabilities, they would surely (and properly) have been
rejected, because they would have harmed Subversion's ability to
reach its goals in a timely fashion.
-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
|
|
| | | |
| Re: [Stellation] Why reinvent the wheel? [message #14924 is a reply to message #13331] |
Fri, 02 August 2002 13:16 |
| Eclipse User |
|
|
|
Originally posted by: par.emanuelson.softlab.ericsson.se
Hi
I am new to Eclipse, I have looked at the Eclipse website and read a handful
of the reports. One thing that puzzles me is that the plugins seem to
be new developments rather than adaptions of existing tools. Many
organizations try not to change tools too frequently, so there should
be a market for integration of existing tools.
Are there technical or commercial reasons for this, or did I get the
wrong impression?
As I understand Eclipse plugins have to be implemented in Java. Is it
very hard to adapt existing non-Java tools to be plug-ins (using e.g.
JNI)?
Is Stellation going to be THE SCM system of Eclipse or will it be one of
several candidate SCMs together with e.g. CVS and ClearCase?
regards
Par
--
Pär Emanuelson
Ericsson AB - SOL
Core Network Development - PDU Methods & Tools
Tel +46 13 235717, Fax +46 13 235799
par.emanuelson@softlab.ericsson.se
"Mark C. Chu-Carroll" wrote:
>
> On Mon, 29 Jul 2002 09:49:42 -0400, Dirk Theisen wrote:
>
> > Hi!
> >
> > It seems like Stellation follows the same goals (being a better cvs) as
> > subversion, a promising and far developed open source project available
> > at <http://subversion.tigris.org/>.
> >
> > So what's the point? Stellation seems to be a waste of resources to me.
>
> Stellation absolutely doesn't have the same goals as SubVersion.
> I think that saying Subversion is just trying to be a better CVS is
> underselling it a bit. I think Subversion wants to do more than that.
> But what they are trying to do is to be a traditional SCM system. In
> many ways, the open-source community is a good twenty years out of date
> when it comes to SCM; I think Subversion is trying to give the OSS
> community a good, solid, modern SCM system.
>
> That's not Stellation's goal. Stellation is a research project which
> is trying to create a fundamental change in how programmers view and
> manipulate source code, and to create a very different environment
> that makes it easier for groups of programmers to work cooperatively
> on large projects.
>
> It happens that the first step along the way to our goal is to test
> our infrastructure by providing something like a conventional
> SCM system.
>
> Because of the difference in goals, we have fundamentally different
> architectures. Stellation is an almost bizzarely extensible system. The
> core of the Stellation repository doesn't understand files or
> directories. It just has a minimal notion of "versioned stuff".
> Everything is provided through extension modules. In the command
> line SVC tool, we load extension modules for text files, binary
> files, symbolic links, and directories.
>
> Subversion is modelled on a versioned file system. The notion of
> files and directories is an intrinsic part of Subversion. They are
> designed to be extendible, but not to nearly the degree of Stellation.
>
> Stellation uses an RDB for storage. Using the RDB means that it's easy
> to add new types of things to the system, and to use SQL queries to
> access and retrieve them - but there can be a penalty in terms of
> speed and size. Subversion uses BerkeleyDB, which gives them more
> compact storage, and potentially greater speed, but at the cost of
> making the internal data structures significantly harder to
> manipulate.
>
> Stellation is intended to do fine-grained versioning, and what we
> call dynamic program organization, giving programmers the ability
> to dynamically create new views and organizations of thier code.
> Subversion is intended to work with traditional file systems.
>
> Stellation is intended to understand the notion of multiple
> projects in a single repository, with heirarchical
> subprojects in each project, and with distinct consistent histories
> for each project and each nested subproject. Subversion only
> recognizes one history for the entire subversion filesystem, with
> subprojects existing solely by convention.
>
> Stellation is designed from the ground up with the notion of supporting
> a very broad notion of metadata, particularly in the form of
> inter-artifact relationships and aggregates. (Take a look at the
> publications section of our website for details.) Subversion isn't: it's
> intended to do a really good job of managing a versioned filesystem.
>
> None of this is intended as a slam against Subversion. I think
> subversion is a very interesting project, and I think very
> highly of the people that I know who are working on it.
>
> But I don't see us as working on competing systems. Stellation
> isn't trying to do what Subversion is trying to do, and Subversion
> can't do what Stellation is trying to do. If I thought our goals were
> compatible, I would have joined forces a long time ago, but they
> aren't. If I were to submit patches to Subversion to give it Stellation
> like capabilities, they would surely (and properly) have been
> rejected, because they would have harmed Subversion's ability to
> reach its goals in a timely fashion.
>
> -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
|
|
|
| Re: [Stellation] Why reinvent the wheel? [message #15816 is a reply to message #14924] |
Fri, 02 August 2002 20:36 |
Mark C. Chu-Carroll
Messages: 32
Registered: July 2009 |
Member |
|
|
On Fri, 02 Aug 2002 09:16:31 -0400, Pär Emanuelson wrote:
> Hi
>
> I am new to Eclipse, I have looked at the Eclipse website and read a
> handful of the reports. One thing that puzzles me is that the plugins
> seem to be new developments rather than adaptions of existing tools.
> Many organizations try not to change tools too frequently, so there
> should be a market for integration of existing tools.
>
> Are there technical or commercial reasons for this, or did I get the
> wrong impression?
I'm the wrong person to ask about this. I'm not particularly
well-informed about the marketing ideas or commercial ideas
behind Eclipse.
There *are* plugins that are wrappers for existing tools. For example,
Rational provides plugins for some version of Rose, and for ClearCase.
I'm not sure, but I think a lot of the JDT code in Eclipse was ported
from earlier versions of VAJava.
> As I understand Eclipse plugins have to be implemented in Java. Is it
> very hard to adapt existing non-Java tools to be plug-ins (using e.g.
> JNI)?
I have no experience with this, so I don't know.
> Is Stellation going to be THE SCM system of Eclipse or will it be one of
> several candidate SCMs together with e.g. CVS and ClearCase?
There is no way that anything could be *THE* SCM system for
Eclipse. Eclipse is designed so that there is an abstract
API called TeamProvider, which is used to provide SCM services.
Anyone who wants to can provide a team plugin to allow their
SCM system to be used inside of Eclipse. There are literally dozens
of Team plugins in progress for Eclipse. Stellation is one among
the many. To see the list, go to Eclipse.org, and follow the link for
community projects. In that page, there's a list of Team providers.
It's our hope that Stellation might grow to be the preferred
SCM system for open-source development in Eclipse. But if that
happens, it will happen because people like using it, and choose
it as their system, not because Eclipse somehow adopts it as the
official Eclipse SCM system and forces Eclipse users to use it.
One thing to realize is that things under the Technology PMC for
Eclipse are not official parts of Eclipse. They're projects that
build on Eclipse in interesting ways. So the existence of
Stellation in no way implies that Eclipse is trying to create
an official SCM system, or that Eclipse believes that the other
SCM systems are inadequate in any way. We're just a project that
builds on Eclipse, and is sufficiently interesting that the
Technology PMC decided to accept us as a hosted project.
-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
|
|
|
| Re: [Stellation] Why reinvent the wheel? [message #18241 is a reply to message #13331] |
Thu, 22 August 2002 06:40 |
| Eclipse User |
|
|
|
Originally posted by: guehene.info.emn.fr
Hello,
I read with great interest the discussion about Stellation and other
related projects. I am sorry if my question is out of scope or has already
been answered: Is Stellation a kind of ENVY/Developer for Eclipse?
Thank you very much in advance.
Greetings,
Yann-Ga
|
|
| | | |
| Re: [Stellation] Why reinvent the wheel? [message #23533 is a reply to message #23362] |
Fri, 13 September 2002 00:03 |
| Eclipse User |
|
|
|
Originally posted by: jed.wesley-smith.remove.remove.combined.com.au
Mark,
the address below was mistyped, it should have been ashkelon.sf.net, and
that will just redirect you to http://www.uptodata.com/
cheers,
- jed.
"Mark C. Chu-Carroll" <markcc@bestweb.net> wrote in message
news:alq4hr$ir6$3@rogue.oti.com...
> On Mon, 29 Jul 2002 15:48:57 -0400, Jim Sculley wrote:
>
> > Jon Skeet wrote:
> >> Dirk Theisen <d.theisen@gmx.net> wrote:
> >>
> >>>It seems like Stellation follows the same goals (being a better cvs) as
> >>>subversion, a promising and far developed open source project available
> >>>at <http://subversion.tigris.org/>.
> >>>
> >>>So what's the point? Stellation seems to be a waste of resources to me.
> >>
> >>
> >> Stellation and Subversion don't have the same goals. Subversion really
> >> *does* have the goal of being a better CVS - and that's about it. From
> >> the way I understand it, Stellation is aiming at an altogether more
> >> revolutionary approach in terms of what gets stored where and how.
> >
> >
> > As an interesting sidenote, I spent most of the weekend fiddling with
> > dbdoc (a.k.a. ashkelon)
> >
> > http://askelon.sf.net
> >
> > It seems to be doing for Javadoc what Stellation does for Java code.
> > I've imported the J2SE 1.4.1 API and I already feel more productive. The
> > search function alone makes it worthwhile. Perhaps the Stellation folks
> > should get together with the dbdoc folks and compare notes. A dbdoc
> > plugin for Eclipse would be a nice tool. I'd start it but I'm three
> > projects behind as it is......
>
>
> I tried to take a look, but their website is currently returning a 404.
>
> -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
>
|
|
| | |
| Re: [Stellation] Why reinvent the wheel? [message #570946 is a reply to message #13165] |
Mon, 29 July 2002 20:12 |
Mark C. Chu-Carroll
Messages: 64
Registered: July 2009 |
Member |
|
|
On Mon, 29 Jul 2002 09:49:42 -0400, Dirk Theisen wrote:
> Hi!
>
> It seems like Stellation follows the same goals (being a better cvs) as
> subversion, a promising and far developed open source project available
> at <http://subversion.tigris.org/>.
>
> So what's the point? Stellation seems to be a waste of resources to me.
Stellation absolutely doesn't have the same goals as SubVersion.
I think that saying Subversion is just trying to be a better CVS is
underselling it a bit. I think Subversion wants to do more than that.
But what they are trying to do is to be a traditional SCM system. In
many ways, the open-source community is a good twenty years out of date
when it comes to SCM; I think Subversion is trying to give the OSS
community a good, solid, modern SCM system.
That's not Stellation's goal. Stellation is a research project which
is trying to create a fundamental change in how programmers view and
manipulate source code, and to create a very different environment
that makes it easier for groups of programmers to work cooperatively
on large projects.
It happens that the first step along the way to our goal is to test
our infrastructure by providing something like a conventional
SCM system.
Because of the difference in goals, we have fundamentally different
architectures. Stellation is an almost bizzarely extensible system. The
core of the Stellation repository doesn't understand files or
directories. It just has a minimal notion of "versioned stuff".
Everything is provided through extension modules. In the command
line SVC tool, we load extension modules for text files, binary
files, symbolic links, and directories.
Subversion is modelled on a versioned file system. The notion of
files and directories is an intrinsic part of Subversion. They are
designed to be extendible, but not to nearly the degree of Stellation.
Stellation uses an RDB for storage. Using the RDB means that it's easy
to add new types of things to the system, and to use SQL queries to
access and retrieve them - but there can be a penalty in terms of
speed and size. Subversion uses BerkeleyDB, which gives them more
compact storage, and potentially greater speed, but at the cost of
making the internal data structures significantly harder to
manipulate.
Stellation is intended to do fine-grained versioning, and what we
call dynamic program organization, giving programmers the ability
to dynamically create new views and organizations of thier code.
Subversion is intended to work with traditional file systems.
Stellation is intended to understand the notion of multiple
projects in a single repository, with heirarchical
subprojects in each project, and with distinct consistent histories
for each project and each nested subproject. Subversion only
recognizes one history for the entire subversion filesystem, with
subprojects existing solely by convention.
Stellation is designed from the ground up with the notion of supporting
a very broad notion of metadata, particularly in the form of
inter-artifact relationships and aggregates. (Take a look at the
publications section of our website for details.) Subversion isn't: it's
intended to do a really good job of managing a versioned filesystem.
None of this is intended as a slam against Subversion. I think
subversion is a very interesting project, and I think very
highly of the people that I know who are working on it.
But I don't see us as working on competing systems. Stellation
isn't trying to do what Subversion is trying to do, and Subversion
can't do what Stellation is trying to do. If I thought our goals were
compatible, I would have joined forces a long time ago, but they
aren't. If I were to submit patches to Subversion to give it Stellation
like capabilities, they would surely (and properly) have been
rejected, because they would have harmed Subversion's ability to
reach its goals in a timely fashion.
-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
|
|
| | | |
| Re: [Stellation] Why reinvent the wheel? [message #571717 is a reply to message #13331] |
Fri, 02 August 2002 13:16 |
| Eclipse User |
|
|
|
Originally posted by: par.emanuelson.softlab.ericsson.se
Hi
I am new to Eclipse, I have looked at the Eclipse website and read a handful
of the reports. One thing that puzzles me is that the plugins seem to
be new developments rather than adaptions of existing tools. Many
organizations try not to change tools too frequently, so there should
be a market for integration of existing tools.
Are there technical or commercial reasons for this, or did I get the
wrong impression?
As I understand Eclipse plugins have to be implemented in Java. Is it
very hard to adapt existing non-Java tools to be plug-ins (using e.g.
JNI)?
Is Stellation going to be THE SCM system of Eclipse or will it be one of
several candidate SCMs together with e.g. CVS and ClearCase?
regards
Par
--
Pär Emanuelson
Ericsson AB - SOL
Core Network Development - PDU Methods & Tools
Tel +46 13 235717, Fax +46 13 235799
par.emanuelson@softlab.ericsson.se
"Mark C. Chu-Carroll" wrote:
>
> On Mon, 29 Jul 2002 09:49:42 -0400, Dirk Theisen wrote:
>
> > Hi!
> >
> > It seems like Stellation follows the same goals (being a better cvs) as
> > subversion, a promising and far developed open source project available
> > at <http://subversion.tigris.org/>.
> >
> > So what's the point? Stellation seems to be a waste of resources to me.
>
> Stellation absolutely doesn't have the same goals as SubVersion.
> I think that saying Subversion is just trying to be a better CVS is
> underselling it a bit. I think Subversion wants to do more than that.
> But what they are trying to do is to be a traditional SCM system. In
> many ways, the open-source community is a good twenty years out of date
> when it comes to SCM; I think Subversion is trying to give the OSS
> community a good, solid, modern SCM system.
>
> That's not Stellation's goal. Stellation is a research project which
> is trying to create a fundamental change in how programmers view and
> manipulate source code, and to create a very different environment
> that makes it easier for groups of programmers to work cooperatively
> on large projects.
>
> It happens that the first step along the way to our goal is to test
> our infrastructure by providing something like a conventional
> SCM system.
>
> Because of the difference in goals, we have fundamentally different
> architectures. Stellation is an almost bizzarely extensible system. The
> core of the Stellation repository doesn't understand files or
> directories. It just has a minimal notion of "versioned stuff".
> Everything is provided through extension modules. In the command
> line SVC tool, we load extension modules for text files, binary
> files, symbolic links, and directories.
>
> Subversion is modelled on a versioned file system. The notion of
> files and directories is an intrinsic part of Subversion. They are
> designed to be extendible, but not to nearly the degree of Stellation.
>
> Stellation uses an RDB for storage. Using the RDB means that it's easy
> to add new types of things to the system, and to use SQL queries to
> access and retrieve them - but there can be a penalty in terms of
> speed and size. Subversion uses BerkeleyDB, which gives them more
> compact storage, and potentially greater speed, but at the cost of
> making the internal data structures significantly harder to
> manipulate.
>
> Stellation is intended to do fine-grained versioning, and what we
> call dynamic program organization, giving programmers the ability
> to dynamically create new views and organizations of thier code.
> Subversion is intended to work with traditional file systems.
>
> Stellation is intended to understand the notion of multiple
> projects in a single repository, with heirarchical
> subprojects in each project, and with distinct consistent histories
> for each project and each nested subproject. Subversion only
> recognizes one history for the entire subversion filesystem, with
> subprojects existing solely by convention.
>
> Stellation is designed from the ground up with the notion of supporting
> a very broad notion of metadata, particularly in the form of
> inter-artifact relationships and aggregates. (Take a look at the
> publications section of our website for details.) Subversion isn't: it's
> intended to do a really good job of managing a versioned filesystem.
>
> None of this is intended as a slam against Subversion. I think
> subversion is a very interesting project, and I think very
> highly of the people that I know who are working on it.
>
> But I don't see us as working on competing systems. Stellation
> isn't trying to do what Subversion is trying to do, and Subversion
> can't do what Stellation is trying to do. If I thought our goals were
> compatible, I would have joined forces a long time ago, but they
> aren't. If I were to submit patches to Subversion to give it Stellation
> like capabilities, they would surely (and properly) have been
> rejected, because they would have harmed Subversion's ability to
> reach its goals in a timely fashion.
>
> -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
|
|
|
| Re: [Stellation] Why reinvent the wheel? [message #571823 is a reply to message #14924] |
Fri, 02 August 2002 20:36 |
Mark C. Chu-Carroll
Messages: 32
Registered: July 2009 |
Member |
|
|
On Fri, 02 Aug 2002 09:16:31 -0400, Pär Emanuelson wrote:
> Hi
>
> I am new to Eclipse, I have looked at the Eclipse website and read a
> handful of the reports. One thing that puzzles me is that the plugins
> seem to be new developments rather than adaptions of existing tools.
> Many organizations try not to change tools too frequently, so there
> should be a market for integration of existing tools.
>
> Are there technical or commercial reasons for this, or did I get the
> wrong impression?
I'm the wrong person to ask about this. I'm not particularly
well-informed about the marketing ideas or commercial ideas
behind Eclipse.
There *are* plugins that are wrappers for existing tools. For example,
Rational provides plugins for some version of Rose, and for ClearCase.
I'm not sure, but I think a lot of the JDT code in Eclipse was ported
from earlier versions of VAJava.
> As I understand Eclipse plugins have to be implemented in Java. Is it
> very hard to adapt existing non-Java tools to be plug-ins (using e.g.
> JNI)?
I have no experience with this, so I don't know.
> Is Stellation going to be THE SCM system of Eclipse or will it be one of
> several candidate SCMs together with e.g. CVS and ClearCase?
There is no way that anything could be *THE* SCM system for
Eclipse. Eclipse is designed so that there is an abstract
API called TeamProvider, which is used to provide SCM services.
Anyone who wants to can provide a team plugin to allow their
SCM system to be used inside of Eclipse. There are literally dozens
of Team plugins in progress for Eclipse. Stellation is one among
the many. To see the list, go to Eclipse.org, and follow the link for
community projects. In that page, there's a list of Team providers.
It's our hope that Stellation might grow to be the preferred
SCM system for open-source development in Eclipse. But if that
happens, it will happen because people like using it, and choose
it as their system, not because Eclipse somehow adopts it as the
official Eclipse SCM system and forces Eclipse users to use it.
One thing to realize is that things under the Technology PMC for
Eclipse are not official parts of Eclipse. They're projects that
build on Eclipse in interesting ways. So the existence of
Stellation in no way implies that Eclipse is trying to create
an official SCM system, or that Eclipse believes that the other
SCM systems are inadequate in any way. We're just a project that
builds on Eclipse, and is sufficiently interesting that the
Technology PMC decided to accept us as a hosted project.
-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
|
|
|
| Re: [Stellation] Why reinvent the wheel? [message #573458 is a reply to message #13331] |
Thu, 22 August 2002 06:40 |
| Eclipse User |
|
|
|
Originally posted by: guehene.info.emn.fr
Hello,
I read with great interest the discussion about Stellation and other
related projects. I am sorry if my question is out of scope or has already
been answered: Is Stellation a kind of ENVY/Developer for Eclipse?
Thank you very much in advance.
Greetings,
Yann-Ga
|
|
| | | |
| Re: [Stellation] Why reinvent the wheel? [message #581700 is a reply to message #23362] |
Fri, 13 September 2002 00:03 |
| Eclipse User |
|
|
|
Originally posted by: jed.wesley-smith.remove.remove.combined.com.au
Mark,
the address below was mistyped, it should have been ashkelon.sf.net, and
that will just redirect you to http://www.uptodata.com/
cheers,
- jed.
"Mark C. Chu-Carroll" <markcc@bestweb.net> wrote in message
news:alq4hr$ir6$3@rogue.oti.com...
> On Mon, 29 Jul 2002 15:48:57 -0400, Jim Sculley wrote:
>
> > Jon Skeet wrote:
> >> Dirk Theisen <d.theisen@gmx.net> wrote:
> >>
> >>>It seems like Stellation follows the same goals (being a better cvs) as
> >>>subversion, a promising and far developed open source project available
> >>>at <http://subversion.tigris.org/>.
> >>>
> >>>So what's the point? Stellation seems to be a waste of resources to me.
> >>
> >>
> >> Stellation and Subversion don't have the same goals. Subversion really
> >> *does* have the goal of being a better CVS - and that's about it. From
> >> the way I understand it, Stellation is aiming at an altogether more
> >> revolutionary approach in terms of what gets stored where and how.
> >
> >
> > As an interesting sidenote, I spent most of the weekend fiddling with
> > dbdoc (a.k.a. ashkelon)
> >
> > http://askelon.sf.net
> >
> > It seems to be doing for Javadoc what Stellation does for Java code.
> > I've imported the J2SE 1.4.1 API and I already feel more productive. The
> > search function alone makes it worthwhile. Perhaps the Stellation folks
> > should get together with the dbdoc folks and compare notes. A dbdoc
> > plugin for Eclipse would be a nice tool. I'd start it but I'm three
> > projects behind as it is......
>
>
> I tried to take a look, but their website is currently returning a 404.
>
> -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
>
|
|
|
Goto Forum:
Current Time: Thu Dec 26 13:44:46 GMT 2024
Powered by FUDForum. Page generated in 0.08230 seconds |
] 
Search
Help
Register
Login
Home
