Hi,

I probably did something stupid (trying to move my source files into a 
'src' directory), but it might be worth a bug report anyway.

My input:

darcs move . src

The output:

darcs: bug at src/Darcs/Repository/Internal.hs:339 compiled Oct  2 2010 
10:07:31
There was an attempt to write an invalid pending!
If possible, please send the contents of _darcs/patches/pending_buggy
along with a bug report.
See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.

Please find attached the pending_buggy file.

My darcs version is 2.4.4 (release).

Thank you and best of luck making darcs fool-proof :)

Best regards,
Jeroen Vrijkorte

Attachments

• pending_buggy
• unnamed

Hi Jeroen,

Sorry my late reply (I went on holiday but failed to arrange for
somebody to take over the customer service + triage end of issue
management).

On Fri, Oct 08, 2010 at 21:47:45 +0000, Jeroen Vrijkorte wrote:
> I probably did something stupid (trying to move my source files into a 
> 'src' directory), but it might be worth a bug report anyway.

> My input:
> 
> darcs move . src

Sounds like a very plausible thing to want to do.

Were you able to get unstuck?

It should be a matter of deleting the buggy pending file and
(importantly) the _darcs/index file that goes with it.  If you omitted
the last step, it may be a good idea to run a darcs check now, just to
be safe.

> darcs: bug at src/Darcs/Repository/Internal.hs:339 compiled Oct  2 2010 
> 10:07:31
> There was an attempt to write an invalid pending!
> If possible, please send the contents of _darcs/patches/pending_buggy
> along with a bug report.
> See http://wiki.darcs.net/BugTracker/Reporting for help on bug reporting.
> 
> Please find attached the pending_buggy file.
> 
> My darcs version is 2.4.4 (release).

Next action required: create a minimal test case.

Jeroen: if you'd like to take part in the darcs development process a
bit more, this is something I think you may be able to do fairly easily.
Don't feel obliged!  http://wiki.darcs.net/Development/RegressionTests
I just like to farm this out to users as much as possible in the hopes
of saving time, and one day hooking somebody and getting a developer out
of it.

For the interested, I can reproduce this with a minimal repository.
In HEAD darcs, it says

darcs: Bug in descent in modifyTree.

Regardless of what meaning (if any) we should attach to darcs move . foo,
this sort of thing is not what we want.  So many thanks to Jeroen for
reporting this corner case to us!

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey@jabber.fr (Jabber or Google Talk only)

For what it's worth, being able to "rename the root" is a very 
interesting use case that it'd be great to be able to support, but it's 
rather tricky. You can work around with "darcs add src ; darcs mv * src" 
but that won't capture new files added in the root on a different branch 
after the rename operation.

The basic problem is what do you do when merging two repos that have 
each had a root rename done to them. e.g. Repo 1 = "darcs add wibble ; 
darcs mv . src1", and repo 2 = "darcs add wobble ; darcs mv . src2". 
darcs patch semantics means this is indistinguishable from "darcs add 
wibble ; darcs add wobble ; darcs mv . src1 ; darcs mv . src2", and 
indeed the other way round, so the operation is ambiguous.

If we were to implement http://wiki.darcs.net/Ideas/AddAddConflicts, we 
could support this scenario by giving the root directory a unique GUID 
when you do darcs init. That'd resolve the ambiguity because each file 
would be attached to a unique root. But, I don't know how to do that 
without losing the nice property of darcs that darcs init followed by 
pulling all the patches from somewhere is equivalent to darcs get.

Hmm, thinking about it, if we allowed multiple directory guids to be 
mapped to the same directory name without it being a conflict, it might 
just work. "darcs mv . src" would then have to rename each guid 
currently in use for "." in the repo.

All this is quite a long way off.