The repository in this tarball was only ever used as a central push depot,
nobody ever added anything to this by any other means than darcs push.  Yet, if
you do a darcs whatsnew, you see some changes...

Attachments

• TSNLP-darcs-corruption.tgz

I'll also add that darcs check on the corrupted repository shows the inverse of
the darcs whatsnew

On Tue, Jan 17, 2006 at 04:33:59PM +0000, Eric Kow wrote:
> I'll also add that darcs check on the corrupted repository shows the
> inverse of the darcs whatsnew

Indeed, it looks here like darcs failed in the middle of an operation,
leaving the pristine cache in a corrupt state.  The good news is that the
pristine cache in a push-only repo is only ever used as a check, so this
couldn't cause corruption elsewhere (unless the push-only repo was local,
in which case a local get would copy the corrupt pristine cache).

I'm afraid it looks like it would be very hard to track down the origin of
this corruption without knowing when it failed.  It would be nice to
introduce a secondary lock to darcs which would indicate a corrupt
repository.  I imagine a file that we create when we start modifying the
pristine cache and delete when the operation is done.
-- 
David Roundy
http://www.darcs.net

That's a relief... but I might mention also that we only noticed this
'corruption' when we tried to do a darcs push and it wrongly told us that there
was a conflict.  But from what you're saying, once we darcs repair and move on,
everything should be fine?

On Wed, Jan 18, 2006 at 04:53:35PM +0000, Eric Kow wrote:
> That's a relief... but I might mention also that we only noticed this
> 'corruption' when we tried to do a darcs push and it wrongly told us that
> there was a conflict.  But from what you're saying, once we darcs repair
> and move on, everything should be fine?

Yes, that's precisely it.  Darcs wrongly told you there was a conflict
because the consistency check was wrong, but that was all that was wrong.
-- 
David Roundy
http://www.darcs.net