> Even for those who do not mind merge conflicts,
> there is still the waste of time.

If you know what you are doing the waste is minimal.  I sometimes import, check, commit, merge, and push a patch on 3 branches in less than a minute (it was a trivial patch that didn't require to run the test suite), and fixing conflicts in Misc/NEWS is something that can be done in a few seconds, even when the merge goes completely wrong (ctrl+2, ctrl+1, ctrl+s, ctrl+q when it goes right; ctrl+q, hg revert Misc/NEWS, copy/paste the entry when it goes wrong).

If you are trying to figure out how to use a merge tool or understanding why there is a merge conflict, what branches are involved, what should be merged and in what order, what should be committed/reverted/updated, then it will take more time (even more if you get it wrong and you have to start over), but the pattern is always the same once you learn it.

> 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.

There are two kind of conflicts:
1) conflicts while merging files between branches on the same machine;
2) conflicts with changesets pushed by other developers;

The first kind is usually trivial to fix (see above).  The second kind (i.e. push race) might indeed be more complex [0], but it can still be solved in less than a minute.  Of course in that minute someone else might push again, but you must be very unlucky (or very slow).

> These problems would be worse if there were more active developers,
> which we need.

Even if we get twice as many active developers, I think push races would still be quite rare since there are usually hours between each push.  Once 2.7 is closed the chances of conflict will further decrease.


> Some possible solutions.

> 1. Get hg to ignore lower context, which is the source of conflicts. 

This could possibly be done with a merge hook (see one of my previous message).  I'm not sure it can be done by ignoring the lower context, but something should be doable.

> 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.

I'm -1 on adding tags and use them to generate Misc/NEWS.

> 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.

Also if I fix a bug in 3.3 and 3.4, will I have to add the news manually in two different files?  Now HG does it for me automatically since there's only one file -- having to edit separate files seems like a step backward.
I don't know if creating News.3.4 by using "hg cp" on News.3.3 will automatically add the entry on both, but even if it does it won't probably solve the original problem.

> 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.

This sounds like an hack, and I'm not sure it will work (hg might try to include more context in the diff if there are only empty lines).

> 5. Add a new Log file with each entry consisting of a tag line, the
> entry, and 3 blank lines.

See previous point.

> 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.

IIRC the Twisted devs do something similar, but with a separate file for each NEWS entry.  Something similar was also discussed when this came up on python-dev a few months ago.

[0]: http://docs.python.org/devguide/faq.html#i-got-abort-push-creates-new-remote-heads-while-pushing-what-do-i-do