Re: CVS bashing?

[Paul Sander]

The algorithm that CVS and RCS use to identify the ancestor is pretty
simple:  Scanning the version numbers of the contributors, find the
longest common prefix with respect to the component numbers.  If the
merge were to augment the CVS metadata to enable shortening the distances
between the common ancestor and the contributors, then prior results
of merges will not appear in new merges.

But in the absence of such metadata, one could examine each difference,
and omit any identical ones that appear in both contributors.  But this
has the limitation that it doesn't work with arbitrary file types, like
a registered merge tool could.

--- Forwarded mail from address@hidden

> address@hidden on 2001.04.12 14:34:33
> >>>>>> "Mike" == Mike Castle <address@hidden> writes:
> >
> > Mike> On Wed, Apr 11, 2001 at 06:06:22PM -0700, Paul Sander wrote:
> > >> - If a branch is merged multiple times to an ancestor, don't count
> > >> the result of the prior merge as a conflict.  (Remember, CVS
> > >> performs a
> >
> > Mike> As I said in an earlier post, this can be scripted around.
> >
> >can you give me an idea as to what such a script might look like?
> >wouldn't there have to be some sort of 'database' which kept track of
> >when/where the prior merges happened?

> Yes, the script will need to keep track of the merge.  This info can be kept
> within the CVS directory.

> But back to the main topic of this thread.  The issue isn't whether there are
> workarounds for CVS's limitations.  The issue /is/ CVS's limitations.  In any
> three-way merge, the files supplied are two versions of the file and their
> ancestor.  If, as was suggested in prior email, CVS is to allow use of an
> external merging utility, CVS needs to supply the ancestor, which means that 
> CVS
> will need to know the ancestor version for each merge.

--- End of forwarded message from address@hidden