-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

if you unpack the enclosed repository and do a

  darcs pull

and say "y" for at least the first patch which is described as

Sat May 31 21:42:29 CEST 2008  Nils Anders Danielsson
<nils.anders.danielsson@gmail.com>
  * Improved the precedence graph interface.
  ...

then darcs loops.  This happened with version 1.1.0pre.  Then I upgraded
to 2.0.0, but no change in behavior.

What can be done about it?

Cheers,
Andreas

- --
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
http://www.tcs.informatik.uni-muenchen.de/~abel/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIR6ZxPMHaDxpUpLMRAtqdAKCxLGChS5cSi2NNT4yR4XJha7grqwCg3Xtg
OrbMrMgzOZ4MZVu/VA/C9Hg=
=vFK2
-----END PGP SIGNATURE-----

Hi,

Assigning to myself to reproduce.

I'm still getting a 404 on http://www.tcs.ifi.lmu.de/~abel/Agda2-local-repo.tgz

Best,

Hmm,

This sounds like a conflict-resolution problem with unrecorded changes.  I have
not looked too deeply into this, but I'll note that you can pull the changes
without the unrecorded changes.

One intervention you could take is to save your work by doing
 darcs record
 darcs send -O

This gives you a bundle with your unrecorded changes.  If you try to apply them
to the repository (with that first patch) pulled, you'll notice that darcs
appears to hang too.  But perhaps you could 'rewrite' the patch in a simpler way?

The nature of the patches is interesting.  They contain something like
 move A -> B
 rm B
 add A

Did you intend to 'swap' two pre-existing files, A and B?

Continuing that thought, if swapping the two files was your intention, you might
be able to get away with something like
 darcs mv A A-tmp
 darcs mv B A
 darcs mv A-tmp B

which reduces the risk of conflicts if you modify either A or B.  Now, the
question of whether darcs2 should handle these conflicts or not (i.e. without
taking forever) I cannot really help with.  For instance, maybe switching to the
darcs2 format would help.

I'll have to ask David when we have a few more details about what happened.

> The question for the developers is:  How can remote changes be falsely
> assumed to be local changes?

Is it possible that you did a darcs mv, and then changed your mind,
but used regular mv to move the files back?

Otherwise, darcs may have some issues with the pending patch.  David
keeps fixing pending-related bugs, so it may be something that was
already fixed between 1.1.0pre and 2.0.0, even with the old format.

Also, your case shows a place where darcs2 does not deal well with
conflicts on darcs1 repositories.  Maybe the new format does better.
We'd have to poke at it to find out.

Sorry for the late reply.

To work around this situation, you can remove the pending patch
(_darcs/patches/pending).

The hanging is because the repository is still using the old darcs 1 format (you
would need to convert to the darcs 2 format to avoid the exponential merge problem).

The reason there was an exponential merge was because of the mv A -> B; rm A;
add B local changes.  I believe these were caused by a bug in handling the
pending patch -- one that has been fixed.

I'm marking this as resolved.  If anybody can show me an instance of this bug
being creating in darcs 2, please open a new issue.

Ah! Actually, I can confirm that this was fixed in darcs 2 (around 2007-08). 
Likely your version of darcs 1.1.0pre was from before last August.

Please have a look at http://bugs.darcs.net/issue494

Very sorry for the vagueness, folks.  I was having trouble searching through the
history.