On Fri, 25 Feb 2005 01:27:55 -0500, "Colin Putney" cputney@wiresong.ca said:
On Feb 23, 2005, at 1:47 AM, Florin Mateoc wrote:
Now, method versions are not interesting just for themselves. A different kind of code organization is a patch, or a unit of work which happens after the packaging structure has been defined, and is perhaps cross-cutting through many different packages. This is a changeset in a non-packaged, non-versioned, and limited-collaboration universe. In a versioned, packaged world, the changesets themselves should be versioned entities, and be composed of versioned sub-entities. It is especially for changesets that method-level versioning comes in handy, because here the finer, method-level granularity is needed. If you are forced to create new (entire) class versions for inclusion in a versioned patch, this not only adds noise, but it creates a much higher incidence of merging conflicts.
Absolutely, although I think with very fine-grained version history, spurious conflicts aren't really a problem. I've never used Envy, but I understand that it doesn't do merges well.
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.
- Doug