I'm concerned that resorting to a version control system that is not written 
in Squeak itself would be a big mistake.  Why would we want to lose control 
of such an important Squeak feature?  If version control is written in C for 
performance (if it isn't fast enough in Smalltalk), that C code should be 
generated by Squeak itself from Smalltalk sources.  Of course, nobody here 
needs my permission to do whatever they like, but I just have to say it 
while the burner is still hot.  ;-)

As it says on the squeak.org homepage: "How is Squeak important? Squeak 
extends the fundamental Smalltalk philosophy of complete openness -- where 
everything is available to see, understand, modify, and extend for whatever 
purpose -- to include even the VM"

Just my humble opinion,

-Carl

>On Thu, 21 Oct 1999 Doug Way wrote:
>
> >On Thu, 21 Oct 1999, Stefan Matthias Aust wrote:
>
> > The result looks very much like ENVY - if done right.  Where's the
> > advantage?  Well, you can build on proven technology which already has a
> > working client server mode.  You omit envy's
>one-big-unknown-contents-file.
> >  It's no closed source and -- hopefully - less expensive.
> >
> > And if you don't go for ENVY (Doug, I'd really like to hear your
>arguments
> > why you think ENVY's approach is better) but follow by ideas about what
> > sharing units of work means, CVS looks even better.
>
>I didn't rule out that an implementation based on CVS was possible.  I was
>mainly concerned about the implementation issue of using a file to
>represent each method... this would result in tens of thousands of files
>to represent a regular Squeak image.  This seemed like it might be a
>problem... although maybe it wouldn't be a big deal.  (I suppose there are
>CVS repositories out there containing tens of thousands of files...)
>
>The fact that CVS is open source and already handles client server stuff
>is a big plus.

<snip>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com