On Feb 25, 2005, at 9:46 PM, Jon Hylands wrote:
On Fri, 25 Feb 2005 19:27:30 -0500, "Doug Way" dway@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