Merging is not magic. Where I see the biggest risk is merging items like IEASYS00 or other critical members where a review is needed to ensure the system comes up versus I’ve merged code changes and are less likely to have an impact. So, I agree with your statements below … not magic, but requires an adult for certain merges.
Matt Hogstrom m...@hogstrom.org +1-919-656-0564 PGP Key: 0x90ECB270 Facebook <https://facebook.com/matt.hogstrom> LinkedIn <https://linkedin/in/mhogstrom> Twitter <https://twitter.com/hogstrom> “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Aug 29, 2018, at 8:20 PM, Andrew Rowley <and...@blackhillsoftware.com> > wrote: > > On 30/08/2018 12:16 AM, Jerry Callen wrote: >> The whole idea of holding a lock on a file while a human being slowly edits >> it is so 1960s. >> >> Since at least the mid 1970s, editors like emacs have loaded the file for >> editing and noted the timestamp. When the user attempts to save the file. >> the timestamp is checked again, and if it changed, the user is asked what to >> do. > I always thought this was a result of being unable to effectively prevent > simultaneous edits, not a feature. The user is asked what to do - do you want > to throw away your changes or the other guy's changes? The answer is always > the other guy's changes, right? >> And, of course, if you use a distributed source control system like git, >> handling merge conflicts is a built-in and normal part of the process. > You can of course do this on z/OS if you want to. > > I have been using source control for long enough that making any change > without source control feels like climbing without a rope. But merging isn't > magic. > > Merging: > 1) Gives you a version that has never been verified by a human. The people > who wrote the merge process assumed the person doing the merge will verify it > is correct. The people doing the merge far too often assume the merged > version is correct. Merging is OK for compiled code where the compiler does a > lot of verification. For something like SYS1.PARMLIB I'm not so sure. > 2) Often you get versions that cannot be automatically merged. Sorting out > these issues can be a monumental mess. Particularly if one or both of the > merged versions were themselves the result of a merge, it can be difficult to > which conflicting pieces are required. In this situation you wish for the > simplicity of a single thread of sequential changes. > > Merging is necessary and useful when you have multiple branches of > development. It's not a substitute for the prevention of simultaneous edits. > > > -- > > Andrew Rowley > Black Hill Software > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
