Simon Peyton-Jones writes: > 4. At intervals, he pulls changes from the HEAD > Puling these changes causes conflicts here and there, where he > has modified the same code as in the HEAD. But that's fine. He > fixes the conflicts and records. The exact mechanism isn't > important, but Joe ends up with a repository that has all the > HEAD patches, plus some of his own > > He needs to do step 4 regularly, partly because he doesn't want > to diverge too far (conflicts are easier to resolve earlier) > and partly to get bug-fixes and features from the HEAD that he > needs. > > 5. Now he's ready to submit! He does a final pull from the HEAD, > to ensure there are no remaining conflicts, and then pushes > to the HEAD > > The trouble is that, unless I misunderstand, darcs simply does not > support this scenario, at least not for projects as big as GHC. > Step 4 doesn't work, and there is no viable work-around.
As far as I can tell, Darcs partially supports *this* scenario. First, all the pushes *must* come after all of the pulls, and then the branch is abandoned. Second, there must be few iterated conflicts (which I call the "ChangeLog problem", because all changes take place at byte 0 in a ChangeLog, so every change results in an iterated conflict). I think one practical problem is that Darcs has no way to recognize and automatically resolve iterated conflicts. Eg, a very primitive resolver is what git calls the "ours" merge: you simply declare that in all cases of conflict between local branch and remote branch, the local branch wins in this merge. This has the effect of "sealing" the local branch because the parent-finding algorithm will find the node and treat that as the most recent common ancestor, and no iterated conflicts (based on pre-merge conflicts) will occur in future pulls. As I say this is very primitive, but what it does is to allow development to continue, and then you must do a diff by hand at the end to complete the merge. But this diff is "small", as it will be restricted to locations where conflicts were permanently resolved by force and a new conflict arose. These locations are genuine long-term conflicts, because continuing development is occurring on both branches, so probably you do want to review them just before the final merge. And, of course, history is preserved. This does not address the pull-before-push issue, so I don't know whether it would actually be useful to GHC Joe. It shouldn't be that hard to implement, though. N.B. I may not be understanding how this works in git since the operational model is quite different, and I am not able to implement in Darcs so I haven't actually tried it. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
