Mark J. Nelson wrote: > 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?
Please, no. This looks reasonable only because it externalizes your costs. Safely automating this (or at least, as safe as teamware) should be fairly straightforward to implement and easy to use. On the other hand, solving the problem by letting people check in useless crap is something *every* consumer of the repo has to deal with, forever. > 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 the desired behavior is Teamware-like obliviousness to inter-file conflict, then just write the tool that implements that. I don't see the need for a new process that has ongoing costs. > 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.) I think this argues against itself. The bigger this problem this is, the more noise this solution adds to the repository. Or to turn it around, if the amount of noise this adds is small, then the original problem was also small. Dave
