Darcs is broken. I found it out the hard way yesterday, while I was trying to commit my patches to the main trunk of GHC.
Essentially, my patches were living in a separate branch. Of course the Darcs model does not need the concept of branches, as traditional SCMs do, but the analogy works fine here.
The debugger is complete just in time for the 6.6 GHC release, and we were planning to include it in the candidate release yesterday Monday.
But Darcs planned otherwise. While my patches were on a branch, I had been careful to keep this branch sync'ed to the main trunk. This means pulling patches from the main trunk once a week or so and fixing any conflicts with my code. Since my patches are spread around several subsystems in the compiler, conflicts have arisen three or four times during these three months.
It turns out that since the last sync with the main trunk I did around the 22nd of August, a new patch has been commited which conflicts with my work. But this time Darcs has decided against simply doing the merge and calling conflict. Instead, it will diverge exponentially and hang.
I have tried everything! I switched to Linux, to Windows, to older versions, I tried all sort of Darcs tricks... to no avail.
What is more embarrassing, it turns out that this is a well-known issue of Darcs, and looks like there is no hope for a solution in the near future.
So now what? The maintainers of the Ghc repo are aware of this Darcs issue, and they have sensibly requested me to avoid pushing patches with conflicts into the main repo. Which means I have to manually re-record all my patches, by hand (with help of diff/patch), into the main trunk. This could take me several evenings, and is boring as hell!
Of course I could record a One Big Patch, but that's a less desirable solution.
I wish I had known about this issue of Darcs before.
I wish Darcs patch theory wasn't so broken in the first place.
[posted with ecto]
