On Fri, 25 Feb 2005 01:27:55 -0500, "Colin Putney" <cputney at 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