On Fri, 25 Feb 2005 19:27:30 -0500, "Doug Way" <dway at mailcan.com> wrote:

> Envy actually has no automatic merging capability whatsoever.  Which is
> odd, since you have fine-grained versioning (down to the method level)
> in Envy, so it wouldn't have been hard to write an Envy tool which would
> at least do a 3-way merge on a class and merge the non-conflicting
> methods for you.  You wouldn't need a text-based merge algorithm for
> that.  I think the Envy designers just never thought to add merge
> capability.

Envy uses an operational model that makes it easier to avoid getting in the
situation where you need to do a merge. You can't make changes to a class
without creating an edition of it, and that shows up in the repository, so
anyone else can see that you are working on it.

Its basically like the difference between optimistic locking (Store/MC) and
pessimistic locking (Envy). They never bothered handling it because if you
follow the class ownership model, and use the tools the way they are
supposed to be used, you almost never need to do merges.

Later,
Jon

--------------------------------------------------------------
   Jon Hylands      Jon at huv.com      http://www.huv.com/jon

  Project: Micro Seeker (Micro Autonomous Underwater Vehicle)
           http://www.huv.com