On Feb 25, 2005, at 9:46 PM, Jon Hylands wrote:

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

You're right, I had forgotten that Envy used a (optionally) pessimistic 
locking system, because the last time I used Envy, our team treated it 
as an optimistic system and we ignored the code ownership facilities.

I realize now that there are really two different kinds of pessimistic 
locking... Envy's system with code ownership (a sort of permanent 
locking), and tools such as SourceSafe/PVCS/etc which only let you lock 
a piece of code temporarily while you're actively working on it, 
there's no "ownership".  Then there are optimistic systems such as CVS 
and Monticello with no locking.

Although Envy was flexible enough that you could use any of the above 
models if you really wanted.  (But with optimistic locking it really 
helps to have some sort of merging capability.)  Anyway, as someone 
who's switched back and forth between pessimistic/optimistic systems, 
I'd say that pessimistic systems are generally inferior. :-)  
(Especially the code ownership model.)

One nice thing about temporary pessimistic locking is that it tells you 
when someone else is working on something.  It seems that this ought to 
be possible with an optimistic system, if you were saving the method 
versions in a central repository as Envy did.  Even though a class 
wasn't "locked", it could tell you that so-and-so has been editing the 
class.

Anyway, I'm not sure if Dan really needs to follow all of these 
Versioning-related discussions... :) it seems like a powerful 
versioning/source code management system could be designed relatively 
separately?  A versioning system only requires that there is a 
packages/modules system which defines/partitions source code.

- Doug