Hi Greg & Paul, Greg, Could you answer the following restricted question...
IF we assume that the 'cvs update' of a particular file in a user's sandbox needs to do a three-way merge (checked-out version, latest-version and locally modified version) AND we assume that there is a "hint" for the CVS server to use some program that looks just like diff3 as to arguments, but (possibly) interprets (say a canonical HTML structure ignoring whitespace) the file differently than the default diff3, AND the "diff3-like-progam" for the checked-out version and the latest-version specifies the same diff3-like program, THEN Paul's request for an extension seems reasonable to allow this kind of an extension. The 'cvs commit' that might result from this merge is not related to this discussion and continues to use the built-in gnudiff utils. The lack of support for a per-delta newphrase that tells some version of CVS to use this other diff3 equivalent would not impact RCS nor would it impact older versions of CVS. In this world view outlined above, are there other problems that are not being considered? I really do want to know your opinion. I do not see the fundamental conflict you seem to see here. Paul, Could you answer the following restricted question... IF we assume that the 'cvs update' of a particular file in a user's sandbox needs to do a three-way merge (checked-out version, latest-version and locally modified version) AND we assume that there is a "hint" for the CVS server to use some program that looks just like diff3 as to arguments, but (possibly) interprets (say a canonical HTML structure ignoring whitespace) the file differently than the default diff3, BUT the "diff3-like-progam" for the checked-out version and the latest-version specifies DIFFERENT diff3-like programs, THEN Greg's objections to adding a "diff3-like-program" per delta runs into a problem with not really having a good solution to jump from one diff3 alternative to another, so the default diff3 would need to be used. However, the propagation of "diff3-like-program" adds extra complexity to generation of new deltas and would seem to add a lot of overhead for a given file. If a file really does change "types" over time, there are boundary conditions that are difficult to handle and dealing with extra information such as the file "character set" or "mime-type" which may lead to the heuristic selection of a diff3-like prgram is rendered more complex. If a simplifying assumption is made to use a diff3-like program for all revisions of a file, then putting that hint into the admin section for the file (just like keyword expansion) might make more sense, but is it a general enough solution to really deal with the situation correctly? What if your diff3-like program needs to be interactive, how much impact does that make to locked directories and the like? Would it make more sense to just use something like this: cvs -n status foo.ext ...notice that it is in need of being updated cvs up -rBASE -p foo.ext > foo.ext.base mv foo.ext foo.ext.mine cvs up foo.ext mv foo.ext foo.ext.new diff3-like-program \ -E -am -L foo.ext -L <BASE-REV> -L <HEAD-REV> \ -- foo.ext.mine foo.ext.base foo.ext.new \ "by hand" rather than trying to have cvs do it for you behind your back? In this world view outlined above, are there other problems or solutions that are not being considered? I can sympathize with your desire for a non-diff3 program to do user-level merges, but I am still looking to find such programs as might exist. There are still a lot of unknowns about how such a new feature should be implemented and there are not a plethora of programs that can do what is needful unless I have missed them. Thanks, -- Mark _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs