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.

<hr><i>jeremy_c added on 2010-01-01 01:31:42:</i><br>
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.

<hr><i>jeremy_c added on 2010-01-01 01:32:21:</i><br>
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.

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

<hr><i>anonymous added on 2010-01-11 06:40:35:</i><br>
I'm also getting it all of a sudden

<hr><i>anonymous added on 2010-01-11 06:44:45:</i><br>
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.

<hr /><i>anonymous added on 2010-10-23 23:07:21:</i><br />
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.

<hr /><i>drh added on 2010-10-24 22:55:25:</i><br />
No updates.  An easy workaround is to do one of:

<pre>
   fossil update --latest
   fossil update trunk
   fossil update <i>version-number</i>
</pre>

Instead of just:

<pre>
   fossil update
</pre>

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.

<hr /><i>anonymous added on 2010-10-25 20:09:02:</i><br />
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.

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

<hr /><i>drh added on 2010-11-25 01:52:57:</i><br />
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.