info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: cvs update; merge


From: Thornley, David
Subject: RE: cvs update; merge
Date: Thu, 30 Aug 2001 16:03:58 -0500

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> 
> I haven't been following this thread, but this happened to 
> catch my eye:
> 
> >--- Forwarded mail from address@hidden
> 
> >CVS merges using a line-based merge.  This has been found, over years
> >of experience, to work very well on such things as program 
> source files.
> >It isn't the fact that there is such a thing as diff3 that makes CVS
> >work, but the fact that using it gives meaningful, and 
> usually correct,
> >results.  While it is possible to have a diff/merge (aka diff3) for
> >other formats, it at best isn't obvious that the result 
> would be worth
> >having.
> 
> >--- End of forwarded message from address@hidden
> 
> 
> As usual, Greg speaks of CVS as if it's not maliable to the 
> will of its
> users.

I think this is the first time I've been mistaken for Greg.

  There has been a great deal of discussion in the past 
> about the
> possibility of replacing the diff3 merge algorithm with 
> something that's
> useful for merging more than ASCII text files.
> 
Right.  The usual assumption seems to me to be that we need a binary
diff/merge capability, then we can change CVS to use that alternatively
and everything is going to be fine.  One common counterassumption is
that this is going to be overly difficult and break things.

What I want to know is if it is going to work in a way that makes it
useful to do.

To repeat, given two versions of a given original source code file, changed
in different ways in different places, diff3 will usually produce a merged
file that, as is, is a valid source file and which will compile to an
executable that has both behavior changes.

It is entirely possible that this will fail to work.  Suppose that one
change used a global variable in a new place and the other change removed
it from the program.  It is possible to think of text formats in which
this sort of merge would normally produce an unusable result.

The fact that diff3 works so often on the sorts of text files people usually
use with CVS is what makes it possible for CVS to manage concurrent
development so well.  If diff3 usually didn't produce a usable merged file,
CVS wouldn't really work.

So, in order to decide whether adding an extended merge capability is a good
idea, we have to determine whether having that capability is worthwhile;
that is, if the merging saves a great deal of time over manual merging for
types of files people would use often.  Until we have some assurance of
this being worthwhile, I don't think it's wise to spend a whole lot of
work making it possible.

> One possibility is to hook a trinary switch in with the -kb keyword
> expansion mode as a quick implementation to support 
> unmergeable file types.
> Another is to hook in a selection algorithm that examines the file and
> invokes the proper merge tool.
> 
Given a satisfactory diff/merge tool, this would be good.  I don't think
it's the right place to start, though.

> But so far no one has had the wherewithall to implement 
> either of these
> and certain parties have argued vehemently that such features 
> must not be
> added because they don't happen to need them.

I'm not going to claim that everybody here is reasonable all the time, but
this is not a simple issue.  It has the potential to be a black hole for
time and effort, break RCS compatibility (which is still useful for some
people) and accomplish nothing useful.

Without a good deal of work, nothing is going to happen.  I would suggest
that people interested in this ability demonstrate a tool that does a good
job of diff3 on popular file types CVS can't merge, and propose a repository
file format that would retain RCS compatibility as much as possible.  If
this project is shown to be useful and feasible, I think we could drum up
some enthusiasm for it.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]