Attached is a simple rep with 1 patch containing an mkdir. If I create a
checkpoint and then unrecord it the repo is left in an inconsistent state
because of the hanging entry in _darcs/checkpoints/inventory. Removing the entry
makes the repo consistent.

- To reproduce within dir foo0 in the tarball..
# Check that things are ok at the start
$ darcs check
<repo is consistent>
$ darcs tag --checkpoint 2347
$ darcs unrecord
$ darcs check
<now repo is inconsistent>

---

The following quote from the manual seems relevant:

"All patches are global, so don't ever [unrecord].. an already ``shipped''
patch.. If other developers have already made patches or tags in their
repositories that depend on the old patch, things will get complicated."
http://www.darcs.net/manual/node6.html#SECTION00623000000000000000

I've noticed that some cases of checkpoint-then-unrecord are indeed handled,
such as when there's no adddir in relevant patches. Perhaps the simplest fix is
to add documentation saying checkpoint-then-unrecord is bad? Then the unrecord
can simply fail rather than leave the repo in an inconsistent state.

Attachments

• darcs_bug.tgz

On Sat, Sep 30, 2006 at 10:53:36PM +0000, Kartik Agaram wrote:
> [...] If I create a
> checkpoint and then unrecord it the repo is left in an inconsistent state
> because of the hanging entry in _darcs/checkpoints/inventory. Removing the entry
> makes the repo consistent.

Yes, removing the tag also from _darcs/checkpoints/inventory
must be the right thing to do, and so the bug is that unrecord /
unpull / obliterate forgets to do that.

David's recent refactoring of the Repository code should make a
fix clean and elegant, and things like this much less likely to
happen in the future. But there might be a couple of months
before they are ready to enter darcs stable, so if this bug is
serious enough, the fix must be made to darcs stable and adopted
to unstable with a resolve patch (which should be quite safe, no
exponential hangs anticipated).

I think the problem with Check is _not_ serious enough because
Check is in error when stating the repo is inconsistent, and a
Check --complete will correctly state the repo is consistent.
However, Get --partial and Repair will also use the "wrong"
inventory in _darcs/checkpoints, and will at best fail. Get
--partial will at worst copy the inconsistent checkpoints
information. I tried to get Repair recreate the unrecorded
patches, but was unable to; it seems it only "recreates" the
very tag, which is not at all visible in pristine.

Well, I don't know. This might be good to have fixed in the
upcoming release after all, but on the other hand the bug
doesn't seem to have happened very often. What do others think?

On Sun, Oct 01, 2006 at 12:37:40PM +0000, Tommy Pettersson wrote:
> Well, I don't know. This might be good to have fixed in the
> upcoming release after all, but on the other hand the bug
> doesn't seem to have happened very often. What do others think?

I only glanced at this, but it looks serious to me.  Sounds like a bug in
unrecord (and probably obliterate?), which doesn't properly handle the
unrecording of a checkpoint tag or something like that?

David

fixed in 1.0.9