Ok, let me summarize where I think we are with this discussion:
1. We should NOT relax our policies to allow merge changesets.
2. We need tools support to allow "trivial" merge/commit/recommit cycles
to happen automatically.
I believe that the bar on #2 is being set a little bit too low: most
folks seem to think it's sufficient to script/automate this cycle on the
client side (ie inside cdm.py). I think that only addresses part of the
problem: the tedium of typing "hg pull ; hg merge ; hg commit ; hg
recommit" arbitrarily many times. It does nothing to eliminate the need
for the dance in the first place.
To actually tackle the underlying cause of this problem, I think we need
to update our integration model. Instead of being subject to
arbitrarily many collisions, and theoretically to starvation, we should
be allowing any integration that meets our criteria for "trivial merge."
Which should mean, essentially, "any set of patches that will apply
cleanly at tip." (Where you may read "patches" as "changesets" if you
so desire.)
This is a hybrid between our current push model, and the pull model
espoused by many smaller-scale, open source projects. We're identifying
a set of conditions under which the gatekeeper ("pull") model devolves
into something that can be reliably scripted. We're still rejecting
anything that fails to meet those criteria.
Still keeping implementation out of the picture, at least for a little
longer: do folks agree with 1 and 2 above? If so, do they agree with my
casting of the problem statement (ie tackle the underlying problem,
rather than the symptomatic cycle)?
--Mark
