>
> I know ENVY only from VA Smalltalk, and I can tell you confidently
> that compared to MC it sucks.
>
>
Cees can you explain me why it sucks. I'm new to MC.

I use ENVY to work every day. We use ENVY in a very particular way (we do
collective code ownership and continuous integration, so we don't use all
those "owner/manager" things, we don't use subapps or configuration
expressions... and we use some in-house tools to handle dependencies and
merging, if you want I can tell you more details -- I don't want to write a
big boring mail--).

In my little experience with MC, I miss some things of ENVY (again maybe
because I'm new to MC, and I use squeak in my spare time), those things are
(in order of importance):

1. The lack of a reified concept of "application". I know that in Squeak are
"categories", but they are only strings. Maybe an example can explain this
point:
In our system we use GemStone. We try to make that our app portable between
VAST and GS (this makes our lives more easy because debugging and developing
directly in GS is a pain in the ass). So we had extended the applications to
respond to the message #gemStoneSynchronizer. So all applications are
polymorphic to this message. Each time that we want to upload the code to
GS, an object simply iterates over all applications in dependency order
(using a topological sort) get its "synchronizer" and executes it. The
synchronization depends on the synchronizer implementation returned by the
application (some applications are not uploaded to GS, some uploads a GS
specific implementation, by default all applications returns a "null"
synchronizer that does nothing).
This would be more difficult in Squeak , because you have to do an object
that maps the category String with the specific synchronizer (for example I
dint found a way to use a particular instance to MCPackage that depends on
the application... oh well category).

2. Is there a way to do something similar to "configuration maps" in MC? (or
Bundles is VW)

3. In ENVY each time that I save a method a version of it is created on the
repository. In MC I can revert the changes on a method but I didn't found a
similar functionality.

4. The "Make image consistent" is really useful when you have an image crash
(I know in the end you have to check the doit.log like in Squeak to ensure
that everything is back again, but I found that this in ENVY is much more
easy: simply "Make image consistent" load or discard different methods, and
then check that there is no Undefined classes in the image --this test is
easy to do because the application object responds to #undefined with the
classes that are missing)

5. I really miss the three way diff :) (we have done an special version that
shows with colors those methods that can be merged without conflicts: the
ancestor and the current version are the same)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060127/7468a7dc/attachment.htm