cvs diff, proposal for change

[Terrence Enger]

Greetings, all.

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.

Note that different parts of the proposal address different
situations.  Indeed, I expect that I shall write contradictory
or incompatible statements as I transcribe this message from
the scribblings on my whiteboard.  Hey, this proposal is
*very* preliminary.


One common situation is a file which can be converted to plain
text on which the output of diff is informative.  Such a case
is my current excuse for procrasting about programming
<grin/>, and Herr Klauer's problem could be addressed this
way, too.  So ...

(*) "cvs diff" and "cvs rdiff" accept optional arguments
    --filter1=<programname>, --filter2=<programname>,
    --filter-both=<programname>.

(*) Then, in the introduction to the diff output of each file,
    after the line "retrieving revision <whatever>", cvs
    prints a line "filtering <whatever> through <programname>"
    if applicable.

(*) In the introduction to the diff output of each file,
    within the line "diff <rev1> <rev2>", cvs inserts after
    <rev1> or <rev2> " (filtered <programname>)" as
    appropriate.

(*) For each rev with <programname> specified, cvs invokes
    <programname> as a filter before going getting into the
    meat of the diff.


Often, the above is not adequate, and I agree that cvs cannot
then do a useful comparison.  Still, we could exploit existing
code (and its documentation) to help user-supplied programs
interpret command-line arguments in the expected way ...

(*) "cvs diff" and "cvs rdiff" accept optional argument
    --diffproc=<programname>.

(*) Then, for each pair for files which are bitwise different,
    cvs calls <programname> with arguments naming (checked
    out) files to be compared plus all the information which
    existing program displays in the per-file header of diff
    output.


I can easily imagine wanting to avoid option fatigue by
defaulting filters based on the filename.  The syntax of the
administrative file commitinfo seems to recommend itself.  But
where, oh where, should the user put her preferences?  I have
assumed implicitly that filters and comparison programs are
distinct from cvs itself, so they may not exist or may not
work on any particular client machine, so they do not belong
among the administrative files.  One can imagine file formats
where one would want to develop a filter or comparison program
as part of the project, but I think this case is more the
exception than the rule.  The quantity of information is
greater than what one commonly assigns to an environment
variable.  .cvsrc applies to one user on one client machine,
which seems good; but the existing syntax does not allow
options to be sensitive to filename.  Perhaps we have to
define a new run-control file?  Anyway ...

(*) "cvs diff" and "cvs rdiff" accept optional argument
    --no-filter to prevent invocation of otherwise applicable
    filters or comparison programs.


I am not nearly ready to start work on changes of this scope,
but I would appreciate your comments, questions, et cetera.


Thank you all for your attention.

Terry.
Available for contract programming.
(As if you couldn't guess from the length of this message
<grin/>.)