Derek Robert Price writes: > > Do you have a good reason we shouldn't allow this, other than it isn't > accompanied by appropriate test cases and maybe documentation? It seems > to me that there isn't any good reason for rdiff to fail this way. It > would seem to me to be best to match the diff behavior here.
I don't necessarily object to the principle, but I'm not so sure about the mechanism. It seems to me that it would be better to detect the message from diff (like patch_file in update.c does) rather than just punting any binary file (some binary files *are* diffable, after all). > Also, do you know of any issues where rdiff behavior intentionally > differs from that of diff? I fixed diff some time ago to generate > proper patches, so it seems to me that any behavior differences should > perhaps be merged as much as possible in the vein of tag & rtag. If you > don't know the answer off of the top of your head, don't worry about it, > of course. I should get around to reading the source later. Not off the top of my head, other than the significantly different command line parsing. I think merging patch.c into diff.c and unifying as much code as possible would be a very good thing. I have mixed feelings about unifying the command lines. On the one hand, it would be handy to have a real rdiff that accepts all the diff options, but there are conflicts with the existing patch (aka rdiff) options which are themselves quite useful. -Larry Jones I think we need to change the rules. -- Calvin _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
