Nathaniel Smith <[EMAIL PROTECTED]> writes: [...]
> The plan right now is to start by disallowing conflicted trees into > the database -- because if you allow them, then you run into the > interesting question of, what happens if people merge two conflicted > trees, and there are conflicts... You could just forbid such things: you allow merging of conflicted revisions only if the sets of conflicted files in each revision are disjoint (the idea being that conflicts disappear during the merge, with possibly new conflicts created by previously non-conflicted files). That captures what I imagine would be the common usage, where you try and remove conflicts really quickly, so such mergers tend to be close together (perhaps of revisions formed by a couple of people working on the conflicts in independent sets of files). On the other hand, if (as I suggested) such conflicted revisions were kept out of the way of users not looking for them, then they *would* sometimes last for long periods. And anyway, users do unexpected things. > ...this is the sort of question one would like to keep out of the > critical path. Yes. On the whole, merge in workspace potentially offers most of what people will want, I suspect (it's what most systems provide, anyway). Presuming there are options to get conflicts embedded in files, then people *could* commit such things (on separate branches, one hopes) if they wanted. [...] _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
