On Monday 08 July 2002 12:13 am, Karl Fogel wrote:
> Brian Behlendorf <brian@collab.net> writes:
> > Sorry if this essay (eek!) seems melodramatic. I wish both Stellation
> > and OpenCM well, as one would wish any volunteer effort well. I just
> > wish I knew why there was a reluctance to combine efforts, especially if
> > it's due to constraints we imposed that aren't necessary.
>
> It may not be obvious from Mark Chu-Carroll's announcements, but
> Stellation has a significantly different approach to versioning than
> Subversion's. For one thing, it versions units smaller than a single
> file; I think it does this by having syntactic knowledge of the data
> it's versioning. So it "knows" about all the functions in a C file,
> for example, and could assemble a new C file out of functions taken
> from various revisions, etc.
We don't do that yet, but that is our goal.
In my announcement, I did not mean to imply that SubVersion is
non-configurable, non-extensible, or anything like that. I wouldn't criticize
Subversion at all: I consider it an extremely interesting project, which I've
followed with great interest from the first day I heard about it.
But Stellation has a very different set of design goals from SubVersion - and
the direct impact of those design goals is a very different architecture. The
key architectural design goal of Stellation is a particular, almost bizzare,
kind of flexibility. Stellation clients and servers dynamically configure
themselves to an extreme degree. (For example, a Stellation server, when it
starts up, knows nothing about what it's going to store. It figures that out
by talking to the repository to find out what's there, and then dynamically
loading code to handle it. A stellation server, in bare form, doesn't
even know what a file or directory is. Those are dynamically loaded
extensions, dynamically configured extensions.)
As for the whole duplication of effort thing goes, I've been working
on Stellation (under a different name - we had to change the name
several times due to name conflicts, which makes things confusing)
for 3 or 4 years, depending on when you draw the line. (I gradually
transitioned from an earlier project into this, and I can't draw a precise
line and say "That day was when I started Stellation.") My first contact
with SubVersion was at the 2001 ICSE SCM workshop, where I met
Karl and Jim Blandy. By that time, I already had a first working prototype,
and was starting to recruit other IBMers for the real system. We started
roughly concurrently, with neither side knowing about the other.
And we've proceded with very different goals. SubVersion is intended
to be a production-quality system as soon as possible. The SubVersion
project is intensely practical: nothing is allowed to distract from the goal
of getting to that production-quality level.
Stellation is a research system. Our goal is to explore how we can
change SCM systems to make them into more effective tools for programming.
One of the primary goals of open-sourcing Stellation is to create
a platform for SCM researchers to try out ideas. And all of our
design decisions have been targetted towards creating the
particular kind of flexibility needed for that: the extreme dynamic
configurability, the fact that it's written in Java, the integration with
Eclipse, the particular way that it uses databases for storage, the
branching and versioning model... They're all done for the
specific goal of making the system work as a research platform. The
fact that it's useful in its current form is, for us, gravy.
The work we've done for Stellation would never have been welcomed
by the SubVersion project: they're in direct conflict with the project's
goals. And I don't mean that as a criticism: a key factor in making
a project successful is choosing your goals, and sticking to them.
Stellation functionality doesn't belong in SubVersion - at least, not
yet.
> Well, I could be getting something wrong here (Mark, please correct me
> by private mail if so; meanwhile, this disclaimer should be sufficient
> to prevent anyone from taking my word as gospel when it comes to
> Stellation!).
>
> But anyway, my point is, the reason these two projects aren't
> combining efforts is because they're very different, and the gain is
> not at all clear at this stage. Yes, their goals do intersect
> somewhat, but the non-intersecting space is large and interesting too.
Exactly. I've been on the SubVersion list since the day I first
heard about it. (Literally: I heard Karl and Jim's talk at the
conference, and when I went back to my hotel room, I subscribed
to the mailing list.) I've done my best to be a helpful member of the
mailing list, even if I couldn't contribute to the code. But combining
efforts just didn't make sense.
> I don't think there's some big missed opportunity here. Could be
> wrong, but based on what I've seen, the effort of unifying the
> projects would be large, and the gain hard to predict.
In fact, at this point, I think unifying the projects would be completely
impossible. Our goals are too different.
In the long run, there may well be value in combining efforts. And
one of the things that we're working on is a way of embedding
Stellation fine-grained support into other repositories, so that if
you wanted to add fine-grained support to SubVersion, you could
do it *without* adopting any Stellation code into your codebase.
> (I think the same is true of OpenCM, but that's a guess based on one
> download and playing-around with it. It just has different
> priorities.)
I've yet to even look at OpenCM. I know a bit about its goals
because Jonathan used to work at IBM, and he told me about it before
he left. It's goals are sufficiently different, and I'm overworked enough
already. So I haven't taken to time to look at it in detail.
-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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 8 14:24:54 2002