I broadened this to gatekeeper, because I'm hoping that one or more members of the core team will chime in.
I don't think we want to literally automate the pull, merge, commit, recommit cycle. Anything we do, in that regard, will still be subject to repeated collisions. The need for this cycle stems from the requirement that onnv-gate changesets have only one parent. We can either try to solve this by keeping that requirement intact or by relaxing it. Before we get too far down the road to a solution, what is the general gatekeeper reaction to relaxing this requirement, and allowing merge changesets under carefully constrained circumstances? I suspect that such constraints are somewhat obvious: the changegroup to be integrated must apply cleanly at the tip. If we keep our strict requirement, then we're looking at one of two different approaches: live with the cycle, and automate it as much as possible to ease developer pain; or introduce a queuing mechanism, limiting developers to a single trip through the cycle when their changes require only trivial merges. If we relax the requirement, then we're looking at a secondary set of questions about policies and tools. I think the primary argument against allowing merge changesets in Mercurial is that, when SCCS merge deltas were allowed in Teamware, they resulted in reduced signal to noise in the metadata. I don't think, if merge changesets are limited to trivial/uninteresting cases, that concern is particularly valid. (By definition, an SCCS merge was interesting--it only happened with file conflicts.) Thoughts? --Mark
