Re: cvs diff, proposal for change

[Paul Sander]

The CVS design is not so married to the diff program that it could not be
swapped out at a low level for more appropriate tools.  (Keep in mind that
somewhere in the CVS implementation it effectively invokes a "diff" or
"diff3" command.  That command could really be anything, as long as it's
appropriate for the data type.  However, RCS is strongly dependent on the
diff program, so any change made there must have an extremely high degree of
compatibility.  Fortunately, RCS is only one of several places where diff is
used within CVS, and the other places can use different tools.)

Deciding which tool to invoke is a bit of a trick, and opinions vary as to
what is the best way to do it.  I believe that the data type should be
embedded in the RCS file, to be consulted by cvs to select the proper diff
tool on the client side from a table.  But this is an imperfect solution
if a single RCS file contains multiple data types, which suggests that
CVS should be sensitive to the content of the file when deciding which diff
tool to use.  And then there's simple filename pattern matching, which is
easy to implement and is often "good enough".

I demonstrated the viability of my claim by implementing a simple
type-specific merge capability for the "cvs update" command.  That patch
was posted to this forum around Sept. 18, 2001.

--- Forwarded mail from address@hidden

I keep seeing questions and comments in the list about cvs
diff, especially about how it is not useful for files holding
data other than plain text.  I see even Andreas Klauer's
recent question "normalizing files and old revisions"
(<http://mail.gnu.org/archive/html/info-cvs/2003-08/msg00194.html>)
as a variation on this theme.

In general, the concensus of those in the know has been
negative: cvs diff is so far from working with arbitrary files
that it is not even worth thinking about changing it.
Nevertheless, I beg your indulgence as I put forward this
preliminary proposal for changes.

[proposal omitted]

--- End of forwarded message from address@hidden