Whew, the smoke's getting thick in here! >From: [EMAIL PROTECTED]
>[ On Thursday, June 17, 2004 at 13:06:44 (-0700), Paul Sander wrote: ] >> Subject: Re: CVS corrupts binary files ... >> >> Current releases of CVS do the latter. (Don't believe me? Look at >> the function named RCS_merge in the rcscmds.c source file.) It's a >> simple matter to replace the invocation of diff3 with a different tool. >Huh!?!?!? >Since when does the phrase "diff and diff3 algorithms" identify any >particular program that might implement those algorithms? Then you don't object to swapping the diff and diff3 programs out for others that might apply other 2-way and 3-way differencing algorithms that are more appropriate to the data at hand, for purposes other than maintainting the integrity of the RCS file format? If this is true, then we're in violent agreement. But to date, you have argued that making the necessary changes to CVS to give better support for data types not handled well specifically by the diff and diff3 programs would break compatibility with RCS, which is demonstrably false. The maintenance of version history is sufficiently insulated from the user interfaces of the content merge features that there is simply no credible argument on that basis. >Paul, _you_ are the one spreading FUD here. How am I spreading Fear, Uncertainty, or Doubt? I'm claiming that CVS is capable of doing more than it does, with only minor changes (i.e. none that have significant impact on its architecture). There's no FUD here, other than what's in your head. The world won't end if CVS changes its merge tool, Greg. Get over it. >In case you have forgotten I am intimately familiar with exactly how the >GNU diffutils code and the GNU patch code is integrated into the CVS >source. Not so intimate that you fully understand how the CVS design constrains the effects of certain kinds of changes, apparently. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs