Terry J. Reedy added the comment: +lots on ending News Merge Hell. After too many bad experiences, I now avoid pushing non-Idle patches that require a News entry. Even for those who do not mind merge conflicts, there is still the waste of time.
The premise of non-checkout code management is that code expands with the number developers, so merge conflicts should stay rare. Making everyone edit the same few areas of one file subverts this premise. The switch to hg introduced push races. A merge conflict lengthens the time required to fix things after losing a race. This increases the chance of loosing the race a second time. This has happened to me. These problems would be worse if there were more active developers, which we need. Some possible solutions. 1. Get hg to ignore lower context, which is the source of conflicts. The upper context of ============== Section Title ------------- ============== is never a problem. 2. Generate news entry from commit message on an *opt-in* basis using a section tag line **Section, where Section is one of Code, Lib, Text, Doc, Idle. Only pay attention to the first letter. Only text before the tag line would go in News. Example commit message: Issue #12345: fix the bug. This is also the news entry. Patch by New Contributor **Lib Comment for developers only. This would work for at well over half of existing commits. I consider the elimination of duplication a bonus. A developer who preferred to write an independent News entry still could. 3. I though of separate News.3.3, News.3.4. While this would prevent forward merge conflicts (very helpful), it would not solve within version pull-merge conflicts, as when loosing a push race. 4. I thought of putting adding enough blank lines between header and first entries so that if more blanks were added with entries, the lower context could be 3 blank lines, and hence no conflict. However, when hg does diffs and must choose, it sees upper blank lines as context and lower blank lines as new, whereas the opposite would be needed for this to work. But this choice enables the following idea. 5. Add a new Log file with each entry consisting of a tag line, the entry, and 3 blank lines. If ========== **Lib Issue #12345. Fix bug. This is News entry. Patch by New Contributor =========== were augmented to ========== **Lib Issue #12345. Fix bug. This is News entry. Patch by New Contributor **Code Issue #12348. Add feature. This is another News entry. ================= the diff would start with three blank lines of context. =================== **Code Issue #12348. Add feature. This is another News entry. + + + ============== 6. Have a directory of personal log files, one for each developer, that get periodically merged into news and emptied (or deleted when a release is tagged). The advantage, and only advantage, over a joint log file is not having to enforce the spacing of a joint log file. ---------- nosy: +terry.reedy _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18967> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
