Folks:

This is the first serious bug I've encountered in darcs-2.  I  
recorded a patch, and it offered me the "rm file" change without  
first offering me the "delete every line of the file change".  I  
thought this was mildly unusual, but I assumed that darcs knew what  
it was doing and recorded that patch and pushed it into the central,  
append-only repository for my project:

http://allmydata.org/trac/tahoe/changeset/2504

However, now certain operations on this repository yield darcs errors:

> allmydata/tahoe/trunk-bug$ darcs query contents --quiet --match  
> "hash 20071207003658- 
> e01fd-9c5c4455756f14fb24bf465869d43a9b78e7d1e0.gz" "src/allmydata/ 
> client.py"
>
> darcs failed:  Error applying hunk to file ./misc/hatch-eggs.py

Or equivalently:

http://allmydata.org/trac/tahoe/browser/src/allmydata/client.py?rev=1656

This is a major problem for me -- the central, canonical repository  
for the open source project and company seems to have some corruption  
now (although the consequences of this corruption are minor).

So I have a few questions:

1.  Why did darcs-2 offer to record removal of a file without  
recording removal of its contents?

2.  How can I repair my central repository with minimal disruption to  
the other programmers who rely on it?

Regards,

Zooko

attached is the offending patch file:

Attachments

• 0000000142-8a9a56b2d267a619e1931053128a1edc6db2da2fd9545ef33dfa789ce71c261e

duplicate of issue815

The following patch updated the status of Issue817 to be resolved in the =
unstable branch:

* resolve Issue817: fix bug in conflict-handling with darcs-2 semantics.=20
This bug was due to the buggy use of a buggy function called
depends_uponFL.  I've removed this function, and am making this note
explicit so that noone else (including myself) will make the mistake of
resurrecting this function from the past.

Hm.  So if that patch resolved Issue817, then why did unrelated Issue816 (which
is a mail-causes-duplicates duplicate of Issue815, which is an
independently-reported duplicate of Issue693) receive this update?

Perhaps the bug in our roundup that causes mail to generate duplicates also
causes "resolve IssueXYZ:" patches to poke the wrong issue numbers ??