It enables multi-user software development.
It is a configuration management tool. It allows to freeze code (called "versioning"), and retrieving that version later.
It is an in the image solution for "modules as run-time manifestations of packages", addressing issues like prerequisites and atomic load
It contains a complete tool set for browsing and comparing versions.
How it solves the problem
Envy stores all changes in a central repository (called "library").
All developers may either work with "live" connections to the library, for teams working close together (like, same building), or developers may work in standalone mode, on local repositories that can later be synchronized with the central one.
The most important concepts are "applications", "classes", "methods", and "configuration maps".
All of those exist in multiple "editions", which are identified with a timestamp.
An application contains classes and methods, plus loading and removing code.
The shape of the class is defined by one application, so it is a "defined" class in this application.
A class can be "extended" by other applications, which means that the application contains just additional methods for that class.
A single edition of an application can be "loaded" into the image.
A state indicator tells you whether the edition you have is identical with the edition in the library (because somebody else may have changed it meanwhile).
Configuration maps bundle specific editions (or versions) together so you can load them in one go.
They are completely orthogonal, so an application can be part of many different configuration maps.
You can have dependencies between application, and between configuration maps (required applications, required configuration maps).
There are different schools for how to structure your code in configuration maps, which is a story of its own.
You get the full history of all development, which is good to have.
When you load a version (i.e. frozen code), you get the same thing you got last time, guaranteed.
The browsers are very usable.
It is very reliable, and its notion of atomic load (where you can select specific editions of multiple applications to be either completely loaded as a whole or to fail, leaving everything unchanged) avoids leaving the image in an inconsistent state
What's not
It takes some discipline to use the concepts and tools in the right way.
You just can't just hack away, you have to decide first about where you put your code (create application, make editions, etc).
Arguably, the previous point may actually be considered cool (plus, it has the notion of default application where it puts the newly created code, if not otherwise specified)
