Here is an example of a situation that led to totally darcs conflict misery. I'm not sure what the lesson here is, but this situation is to be avoided... even though it seems rational to me:

The Set Up

At work, my team uses CVS to manage our source. Not counting 3rd party libraries checked into the tree, there is about 23 Meg of source in 2000 files, and another 150 Meg of stuff in a 1000 files. For various reasons (like really fast branching), I want to use darcs with very frequent checkins for work on my cluster of machines, and commit completed work back to CVS every day or so. Disk space isn't an issue (my machines have tons), but speed is. I want my source operations to be fast. I like to record often, branch often, and find out what currently changed often. These operations are fast in darcs and miserably slow in CVS (especially if there are branches.)

I start by checking out some branch of the CVS tree into a base:

[1]     mkdir ~/base
        cd ~/base
        cvs ... checkout -r Branch_Foo product

Then I build a darcs repo on this

[2]     cd ~/base/product
        darcs init
        darcs add -r .
        darcs record

Then I get that into a working area

[3]     mkdir ~/working
        cd ~/working
        darcs get ~/base/product

Now I can work along for awhile:

[4]     cd ~/working/product
        repeat {
            #edit files
            darcs record
        }

When I need to update my working area to the latest version of the CVS branch (before I can commit my changes to CVS) I do this:

[5]     cd ~/base/product
        cvs update
        darcs record

        cd ~/working/product
        darcs pull

This generally works just fine - even if I commit the sin of not recording some outstanding changes in working first.

When my work is ready for committing back to CVS, I do:

[6]     cd ~/base/product
        darcs pull ~/working/product
        cvs commit

Occasionally, I'll add a darcs tag in product when what I've pulled from CVS is an important release:

[5a]    cd ~/base/product
        cvs update
        darcs record
        darcs tag

        cd ~/working/product
        darcs pull

The Conflict Misery

Yesterday, there is a big shift in which branch will be the one for current development. But, no problem-o I say: This is just a variant of operation [5] above:

[5b]    cd ~/base/product
        cvs update -r Branch_Bar
        darcs record
        darcs tag

        cd ~/working/product
        darcs pull

While this is a big operation, (several hundred files changed), nothing I was working on changed in any significant way, and indeed there were just a few tiny conflicts. Darcs was a little slow to do this, but acceptable given the size of the change, and the infrequency of this kind of thing.

I resolve the conflicts:

[7]     cd ~/working/product
        #edit files with 'v v v v' in them
        darcs record

Now, someone else discovers there is a bit of a mess in Branch_Bar, and fixes something. This amounts to about 30 one line changes each of several files. One of those files is one I've been working on, and there will be conflicts. Indeed about 4 of those lines are in code I've deleted, and about 4 more are lines I've edited. And this is one of the files fixed in step [7]. Remember, all my edits are recorded in the ~/working repo. I'll need this change to get Branch_Bar compiling:

[5]     cd ~/base/product
        cvs update
        darcs record

        cd ~/working/product
        darcs pull

This never completes. Never, nada, not ever. I'm expecting some conflicts in my working area. I'm expecting I'll have to go in a fiddle with a few conflict markers and re-apply those one line changes myself. But it never gets there.

I try about three or four different ways to make this happen: What if I branch the base repo no and pull the working patches into it? What if I do partial repos? Perhaps the Mac port isn't up to the task, so I try it on a fast Windows box and on a fast Linux box. Nothing works.

In the end I resort to doing this:

[6]     cd ~/working
        darcs unpull --patch 'patch-recorded-in-7'

        mkdir ~/old-base
        cd ~/old-base
        darcs get --to-patch 'last-patch-pulled-in-5b' ~/base/product

        diff -r -u ~/old-base/product ~/working/product > ~/work-patch.diff
        #details omitted here in making sure the diff ignores the _darcs dir

        mkdir ~/working2
        cd ~/working2
        darcs get ~/base/product

        cd ~/working2/product
        patch < ~/work-patch.diff

        #manually compare diffs:
        darcs whatsnew
        opendiff _darcs/current .

        #edit and fix as needed

        darcs record

Of course, I loose all my history of my patches that get to my current work state. And if there are any branches of the ~/working repo, they must be abandoned and I must "darcs get" the ~/working2 repo. In my particular case, neither of these is too bad: The branches are just copies on other machines so I can check my work on other architectures and build tools (the code must run on three.), they don't contain code that hasn't already been propagated to ~/working, and now patched into ~/working2.

(I have omitted here that I wanted to and was able to pull some particular patches from ~/working to ~/working2 that I really wanted to keep distinct. It did, of course, complicate the sequence: Once I established that those patches wouldn't send darcs into a tailspin, I had to both pull them into ~/old-base and ~/working2, and *then* generate the patch file.)

-- MarkLentczner

Did you take a sample of darcs while it was locked up? The command is sample darcs. This only works on a Mac, AFAIK.

The file it creates is a complete stack trace of the sampled process (in this case, darcs) during the sample period (which defaults to ten seconds). That should give you, or at least the developers, some idea of what darcs is doing while it's locked up.

--Peter Hosey