It is possible to make a patch that lists some directory both as added and
removed (there is "adddir" line, then "rmdir" line). Such patches could easely
lead to lock during the patch pulling.

I had two patches: one "broken", that added and removed "A" directory and other
"correct" patch, that added "A" directory. The first patch was applied. I've
looked at the working directory - it did not contained the "A" directory, so
second patch should been applied well. But when I tried to pull it, the darcs
hanged. After some investigation I found that first patch is "broken" and after
fixing it (re-recording it) I pulled second patch successfully.

On Tue, Sep 19, 2006 at 17:36:12 +0000, Ivan S. Dubrov wrote:
> I had two patches: one "broken", that added and removed "A" directory and other
> "correct" patch, that added "A" directory. The first patch was applied. I've
> looked at the working directory - it did not contained the "A" directory, so
> second patch should been applied well. But when I tried to pull it, the darcs
> hanged. After some investigation I found that first patch is "broken" and after
> fixing it (re-recording it) I pulled second patch successfully.

This is very interesting for us.  We have had a similar problem in
issue264 and we are still looking for a reproducable example.

Could case-sensitivity be related?

Do you think you could help us to reproduce this?

Unfortunately, I can't reproduce it neither provide the my repositories. I use
Linux, so the case should not be problem.

I can remember that I've done something like this:

1. I have a repo with upstream version 20060913.
2. I've copied it (with "darcs get") to the branch named 20060918
3. When I removed all files (besides the _darcs) from this directory and
uploaded new upstream sources there.
4. I've recorded the changes.
5. I found that new upstream sources are not "clean", there is directory named
"other" with binary data there.
6. So I deleted the "other" directory and unrecorded the last patch (that
upgrades 20060913->20060918).
7. I've recorded the patch again. This patch becomes "broken", it lists the
"other" directory both as added and as removed.

And now, when I try to pull my patch from 20060913-customized directory, I'm
getting a lock (my "customizing" patch contains a "other" directory with binary
files).

I'm marking this as "need example".  It is described as being similar to
issue264, which is resolved. 

Also, I couldn't create such a patch with darcs 1.0.9 or 2.0.0pre2 on test repos. 

In any case, work on this is likely stalled until there is a reproducible example. 

   Mark

I believe I have fixed a bug that led to behavior such as this, so I'll mark
this resolved-in-unstable.

I tested now to see if I could create such a patch by "adding" the directory in
one patch, and then using "amend-record" to add the remove command. 

This didn't trigger the issue, either, but rather created an empty patch, which
I seems like the appropriate result, even though its an edge case.