rsalz@bbn.com (Rich Salz) (06/16/88)
>I have to disagree with the sentiment that "diff -c" is extremely >useful. I find it only slightly useful. You are in the minority. I base this on my experience as the moderator of comp.sources.unix. >You might have noticed that when I post bug fixes I never do it >via "diff -c". I prefer to give enough information to RELIABLY >patch the code. In any context where I would trust "patch", I >would also trust "ed" using the output of "diff -e", which is >generally much less output. Using diff -e and ed are fine, as long as you are able to (naively) assume that nobody will add or delete a line to what you put out. It's possible to "make up" for this by adding enough information so that someone can sit down and apply changes by hand, but why penalize someone with all that extra work just because they added #define malloc use_my_debugging_malloc at the start of a 500-line file? (Arguments about the software engineering principals behind this are canards and obscure the point.) And, of course, people don't just apply patches, but they also browse through them -- perhaps they've already made the fix, or they're just cautious. Browsing anything other than a context diff for this purpose is a waste of time. Which brings us to: >I recently generated a "diff -c -b" comparison between [Foo Rel1] >sources and [Foo Rel2]. The output was larger than >the concatenation of all the sources. It was useful for the >intended purpose (browsing), but would be ludicrous for "patch"ing. This is known and documented behavior. Heavens, I think any reasonable tool user would write a script to put out the lesser of the two outputs. Glad to see you found it useful, tho. Was it only "slightly" useful this time, however? (See first paragraph.) /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/18/88)
In article <954@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes: >Using diff -e and ed are fine, as long as you are able to (naively) assume >that nobody will add or delete a line to what you put out. What I said was: In any context where I would trust "patch", I would also trust "ed" using the output of "diff -e", which is generally much less output. I would trust NEITHER "ed" nor "patch" when modifications have been made to the original code. "patch" may be somewhat more likely to succeed in such a case, but it obviously cannot be guaranteed to work right.
haugj@pigs.UUCP (The Beach Bum) (06/19/88)
In article <8122@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <954@fig.bbn.com> rsalz@bbn.com (Rich Salz) writes: > >Using diff -e and ed are fine, as long as you are able to (naively) assume > >that nobody will add or delete a line to what you put out. > > What I said was: In any context where I would trust "patch", I would also > trust "ed" using the output of "diff -e", which is generally much less output. > > I would trust NEITHER "ed" nor "patch" when modifications have been made > to the original code. "patch" may be somewhat more likely to succeed in > such a case, but it obviously cannot be guaranteed to work right. I push `patch' and context diffs quite further than even Rich $alz does. The database system we run here (HECI Exploration Co. Inc.) consists of several hundred different Informix 3.30 ACE reports. Of those, many are very similiar to each other with only small differnces due to sort order, page layout, etc. To make my job easier, whenever I fix a bug in one report, I take the context diff from that bugfix and try to apply it to all of the other almost identical reports. This helps to keep the similiar reports more similiar, while fixing bugs where they may not have been known about. While this frequently does not work 100%, I can still look in the rejects file and see what turned up. Also, because of the context information which is present, similiar lines are distinguishable from each other based on the surrounding context. I consider this application of diff and patch to be far from useless, which as I recall was Doug's original objection. - John. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS "You are in a twisty little maze of UUCP connections, all alike" -- fortune
barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (06/19/88)
In article <8122@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: |I would trust NEITHER "ed" nor "patch" when modifications have been made |to the original code. "patch" may be somewhat more likely to succeed in |such a case, but it obviously cannot be guaranteed to work right. Still, I would trust diff -c and patch to install 95% to 99.9999% of the patches correctly (with the rejects documented). If I were given: 1. non-pristine source code 2. Non-context diff output (assume large number of patches) My choices would be: A. Have patch munge up the code so bad I would never know if the patches were installed correctly B. spend hours, or days applying patches manually C. throwing the whole mess away. I usually choose option C. If someone doesn't know how to provide useful patches, then they are incompetent, and the program would probably be more trouble than it is worth. I have installed hundreds of USENET programs, and I don't have the time to fix programs that cannot be upgraded using patch. I left out one of the options: D) send context-diff.c sources to the author of the patch. I strongly suggest that context diff and patch be provided with every Un*x system shipped. If the wizards@research don't provide a context diff program that patch can use, then they are typifying the "ivory tower" syndrome. -- Bruce G. Barnett <barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP> uunet!steinmetz!barnett