>>>>> "Jim" == James Carlson <james.d.carlson at sun.com> writes:
Jim> it'd be nice if Mercurial could itself do something to support the Jim> "changesets with non-overlapping sets of files don't actually Jim> require merge" model The model that Matt Mackall endorses is one where someone pulls from the repos that have the fixes. This is described at http://www.selenic.com/pipermail/mercurial/2008-July/020116.html http://www.selenic.com/pipermail/mercurial/2008-July/020131.html I'm skeptical that this would scale if the pulls were done by an individual on a codebase as large as ON. But maybe it could be automated? If, as meem contends, most developers don't pay attention to other changes in the gate unless forced to by a file conflict, then I don't see much risk with an automated pull approach. I'm not convinced that's the case, though. Assuming a pull model, I wonder if some additional automation might help bound the risk of non-detected conflict. Maybe something like requiring that the incoming changeset have a parent that is within N changesets of the gate's tip? Or some sort of automated subtree check, e.g., something that detects a header file change and counts it as a conflict with any other changesets that affect the same subtree? There'd also need to be some sort of queueing mechanism for fairness. We should also explore moving stuff out of ON that doesn't really need to be there. mike
