| > 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).
The scenario I have in mind is:
get
(edit, record)*
pull -a
<resolve conflicts>
(edit, record*)
pull -a
<resolve conflicts>
...etc...
finally: push
I believe that the difficulty comes in the conflict part. Resolving a conflict
means recording another patch, which darcs somehow knows is a conflict
resolver. I believe that the trouble is that darcs can't handle conflict
patches. I forget what goes wrong, but the darcs people know. I think it just
crashes. I know that solving this problem is (a) a high priority for the darcs
developers but alas (b) very difficult.
In any event, what we have learned is that our main repository must contain NO
conflict resolver patches. None.
(I don't know what an iterated conflict is, nor what git is; I'm very much a
Joe here!)
Simon
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
