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.

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.

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.

> 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.)

- Doug Way
  EAI/Transom Technologies, Ann Arbor, MI
  http://www.transom.com
  dway at mat.net, @eai.com