View Ticket

View Ticket

Ticket Hash: fbea61caf0acfd0a031626c2622ade980a03d7f1
Title: fossil needs a rebuild after receiving a new baseline checkin
Status: Closed Type: Code_Defect
Severity: Important Priority:
Subsystem: Resolution: Open
Last Modified: 2011-11-02 22:39:49
Version Found In: [6f42e76d80]
After using a branch with delta manifests, at some point a new baseline manifest will be created. On sync, other fossil repository copies will fail to show the delta manifest checkins coming after that new baseline manifest.

A 'rebuild' on those fossil repository copies fixes the situation.

(This was discussed in the mailing list here)

anonymous claiming to be viric added on 2011-02-07 18:46:11 UTC:
We are still hitting this problem constantly, both in windows and linux.

Any chance for someone to look at it?

drh added on 2011-02-07 21:43:20 UTC:
I'm still unable to recreate the problem. Trying lots of different combinations of pushing and pulling with a mixture of delta and baseline manifests. It always works for me. Any hints will be appreciated.

anonymous claiming to be viric added on 2011-02-10 20:54:49 UTC:
I found this:

sqlite> .schema orphan
    baseline INTEGER
    CREATE INDEX orphan_baseline ON orphan(baseline);
sqlite> select * from orphan;
sqlite> select * from blob where rid=8024 or rid=8031;

The first, 8024, is the BASELINE manifest artifact, that shows fine in all fossil operations. 8031 is the next DELTA manifest artifact, that does not show. No artifact after that shows, either.

And as I told before, in the many times I've hit this problem, "fossil rebuild" fixes the situation.

I keep on investigating, although of course I don't know much about what fossil should be doing in terms of sql operations/function calls.

I'm only trying to ring a bell to drh.

anonymous claiming to be viric added on 2011-02-10 20:58:36 UTC:
I have two suppositions, meanwhile:

  • The artifacts are interchanged in no particular orther, and if a DELTA manifest is transferred before the BASELINE manifest it refers to, it ends up in the 'orphan' table.
  • The orphan database is written with the rid/baseline members swapped.
          rid = content_new(p->zBaseline);
             "INSERT OR IGNORE INTO orphan(rid, baseline) VALUES(%d,%d)",
             rid, p->rid

anonymous claiming to be viric added on 2011-02-11 12:24:41 UTC:
I've seen the fix in trunk; I'll close the ticket when I'll find the opportunity to test it (on the next baseline commit).