<br>

<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I know ENVY only from VA Smalltalk, and I can tell you confidently<br>that compared to MC it sucks.
<br><br></blockquote></div>
<br>
Cees can you explain me why it sucks. I'm new to MC.<br>
<br>
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 &quot;owner/manager&quot; 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--).<br>
<br>
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):<br>
<br>
1. The lack of a reified concept of &quot;application&quot;. I know that in
Squeak are &quot;categories&quot;, but they are only strings. Maybe an example
can explain this point:<br>
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
&quot;synchronizer&quot; 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 &quot;null&quot;
synchronizer that does nothing).<br>
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).<br>
<br>
2. Is there a way to do something similar to &quot;configuration maps&quot; in MC? (or Bundles is VW)<br>
<br>
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.<br>
<br>
4. The &quot;Make image consistent&quot; 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 &quot;Make image consistent&quot; 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)<br>
<br>
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)<br>
<br>
<br>