Fossil

View Ticket
Login

View Ticket

Ticket Hash: 375e5703329a743339c3b6399d7c41a8c98c7a24
Title: fossil: bad object id: 0 on up
Status: Fixed Type: Code_Defect
Severity: Critical Priority:
Subsystem: Resolution: Fixed
Last Modified: 2010-11-25 01:52:57
Version Found In: 71ad9b62a7
Description:
Just ran fossil pull and then tried to run fossil up with fossil version [71ad9b62a7] 2009-12-31 14:59:03 UTC on the fossil repository and received this error "fossil: bad object id: 0 on up". I ran fossil rebuild and still get the same error.

jeremy_c added on 2010-01-01 01:31:42:
Does this message still occur? It appeared for me on the fossil repo (none of my own) until I made the last commit. It no longer appears.


jeremy_c added on 2010-01-01 01:32:21:
Oh, I should say, my last commit had nothing to do with this error message, I just noticed that it no longer appears for me making me think the commit caused some type of database cleanup fixing the problem.


anonymous added on 2010-01-01 01:37:09:
I'm still getting it on my already cloned repo. If I do a fresh clone, fossil up works.


anonymous added on 2010-01-11 06:40:35:
I'm also getting it all of a sudden


anonymous added on 2010-01-11 06:44:45:
OK: I just did a "fossil close" and then "fossil open", and that bug is gone; so I assume there is something wrong in the _FOSSIL_ database.


anonymous added on 2010-10-23 23:07:21:
any update on this? it just occured to me with

This is fossil version [b48f78964e] 2010-09-18 15:51:43 UTC

on the fossil repo.


drh added on 2010-10-24 22:55:25:
No updates. An easy workaround is to do one of:

   fossil update --latest
   fossil update trunk
   fossil update version-number

Instead of just:

   fossil update

The problem is here that fossil is having trouble figuring out what version it needs to update to. If you give it a hint, it will normally keep going without trouble.

It would help to have a reproducible test case.


anonymous added on 2010-10-25 20:09:02:
Could this be a result of fossil deciding that an artifact already exists locally because it is in a cluster? If you hit this case, please do a second clone and see if it still shows the problem. If it doesn't, compare the output of

sqlite3 $repo 'select uuid from blob order by uuid'

for both repo files.


anonymous claiming to be viric added on 2010-11-24 22:18:21:
An easy reproducible test case is doing "fossil update" while being in a closed branch.


drh added on 2010-11-25 01:52:57:
Fixed for the case of a "fossil update" on a closed branch. If other cases are found, please reopen the ticket with an explanation of the next case.