The other big advantage of Envy is that it makes it really easy to connect
to existing libraries and port them to another platform (which is also why I
get a little alarmed by some of the syntax proposals I have seen in this
list). I would like it to be easy to one day port our application frameworks
from VW and GS to Squeak.

Envy itself performs rather poorly over slow network connections (although I
am sure this would not be a problem with the new improved PWS option!)

By making the "unit of work" method changes, then no matter where you are in
the middle of a "task", if your image crashes, you can recover. Envy is as
much a source management system as it is a lifeline.

But I am not sure that a central repository would work very well in a
distributed project like this one.

It would sure lighten Dan's work load though :-)

Steve

> -----Original Message-----
> From: Robin Gibson [mailto:ironsignbob at we.mediaone.net]
> Sent: October 21, 1999 5:51 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: TeamTool/Version-Management for Squeak?
>
>
> Excuse me butting in, and Hi.
>
>
> Doug Way <dway at mat.net> 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.
>
> ENVY's advantages over a CVS type repository, namely:
> * the speed at which the precompiled bytecode can be linked into
> your image
> * the Smalltalk-centric way of doing things (non-intrusive - once
> you're familiar)
> * (very)Comprehensive and flexible UI
>
>
> can be matched by CVS - look at Team/V - but by that stage you've
> reimplemented ENVY.
>
> > 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.
>
> That's true - however gluing it to Squeak in a way that doesn't
> kill the rapid-feedback thrill of Smalltalk or bloat your image
> may mitigate the advantage of available source.
>
> How about pushing more of the grunt work down to the client's
> image? Squeak has some remarkable and promising abilities in
> terms of Object<->Disk and ImageSegment<->Disk storage. If we
> could leverage those and others, we could have the server be as
> dumb/lean/simple as possible - a la Tensegrity or Objectivity.
> Even adapting CVS may be possible - without the overhead of
> Team/V, hopefully - but I imagine that the storage mechanism
> could be pluggable; all it needs is to be shareable, lockable,
> commitable and back-out-able. And many client-based OODBMSs are
> quite lightweight...
>
> ...yeah, I know. I'm suggesting we tackle the complexity of
> building an OODBMS to avoid the complexity of building a CVS
> wrapper - it's just that an OODB would be useful for SO many
> other things  : )
>
> >
> > Also, I'm not totally stuck on doing things purely the ENVY way... I was
> > mainly advocating versioning (tracking) down to the method
> level.  (So, if
> > you wanted to, you could look up all the versions/editions of a
> particular
> > method in the repository, via a tool of course.)  You could still have
> > changesets, which are then a list of pointers to method versions.
> >
> > > >And this is what I was heading for. I thought of an
> ENVY-like server in
> > > >a LAN or even WAN written completely in Squeak that manages
> one change
> > > >file (with some additional information and pointering) and thus
> > replaces
> > > >the image and changes files of all its clients.
> > >
> > > I don't like the idea to replace something that works.  One of ENVY's
> > > drawbacks is that you need a permanent connection to its
> repository.  I
> > > prefer a checkout/optionally lock/checkin approach which allows you to
> > work
> > > "unplugged".  Assume you simply want to try something out which shall
> > not
> > > affect any other code.
>
> (Actually, ENVY lets you do exactly that, really easily.)
>
> > I agree with you here... there should definitely at least be a mode in
> > which the repository connection is optional.
> >
> > Also, ENVY does that thing where every method which is ever accepted is
> > stored in the repository... that's nice to have sometimes, but
> definitely
> > not a crucial feature.
>
> Ahh, there's one advantage of ENVY I forgot:
> * Totalitarian control over the shred image
>
> You're right, it can be a drag - but I've never seen anything
> strip a deployable image down to nothing like ENVY - it tracks
> every message send - and it's dead easy.
>
> > > Keep in mind, these are minimal requirements but I'd like to see these
> > > relalized then endless talking about what the complete set of features
> > is -
> > > if I'm allowed to choose ;-)
> >
> > Fair enough... perhaps a CVS-based repository which stored changesets as
> > files would be an okay start.  (Storing methods as the smallest unit is
> > still the ultimate goal, though, I'd say.)
> >
>
> Yes, it's a big question - lots of work whichever way you go. Is
> there an open forum for discussing this? Perhaps there's someone
> with access to resources that could help cross a few bridges.
> (MinneStore? JCVS? mySql and Mini-External-ImageSegments?) I'd
> sure like to be involved.
>
> ...just my 2.165 cents worth...
>
>  - Robin
>
>
> > - Doug Way
> >   EAI/Transom Technologies, Ann Arbor, MI
> >   http://www.transom.com
> >   dway at mat.net, @eai.com
>