This is my second attempt to post this question. The first has not appeared on the list; neither have I received a bounce message. Please accept my apology if you receive it twice.
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/>.) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
