[email protected] (Shmuel Metz , Seymour J.) writes: > A normal reading of "diff3 allows a 3 way merge" would be that there > are options to diff3 that cause it to perform the merge. Did you read > it as "diff3 creates output that you are allowed to feed into an > external program in order to do the merge"? If so, pretty much any > program "allows" you to do pretty much anything.
re: http://www.garlic.com/~lynn/2013e.html#66 Sequence Numbrs (was 32760? trivia ... when were were doing the original multi-level updating at the science center for cp67/cms (would eventually morph into what is found in vm370/cms and the various editors) ... the person that later would go on to "invent" DNS (domain name system) was at MIT and had job working at science center. he did a bit of software that would merge multiple two or more independent update streams for the same source ... attempting to do as much as possible automagically and flagging all possible areas of conflicts. this routine was never carried forward into standard support. the issue was if two (or more) groups/individuals were indenpendently generating changes/updates for the same source module ... how to merge/combine the independent operations. the problem (at least) would be common when vm370 would ship a new release. standard PLC (monthly enhancements & fixes) were shipped as accumulated source updates. New monthly PLC tape is was much more straight-forward to identify changes since last PLC tape and do the integration of any local source code changes with standard product enhancements/fixes. However, for new release, the product group would apply all accumulated PLC fixes/enhancements updates to the base source plus all new changes specifically for the new release and resequence the new base source module. customers then had a much harder time migrating local source code changes from prior release to the new release (with all IBM updates applied to base source routine and resequenced). note diff3 ... but later, I did do trivial program that helped in the process. one was given two similar sources with old & new sequence numbers ... would generate an update for the old sequence numbers that represented the difference between the two sources (effectively created what was in new resequenced source release that applied to the previous release updated old sequenced source would generate the same code). This made integration of local source changes against new release much simpler (since it localized just the actual source code changes w/o the impact of the resequencing). when the local installation was done resolving conflicts (except for sequence numbers) ... run the program in reverse; two nearly identical source routines (except different sequence numbers) ... old release using old sequence numbers with both update applied to turn it into new release (with old sequence numbers) and local updates ... against new release with new sequence numbers ... would generate local updates converted to new release sequence numbers. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
