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
CREATE TABLE orphan(
  rid INTEGER PRIMARY KEY,
    baseline INTEGER
    );
    CREATE INDEX orphan_baseline ON orphan(baseline);
sqlite> select * from orphan;
8024|8031
sqlite> select * from blob where rid=8024 or rid=8031;
8024|26|257565|5d6a9957808c417aae6f41c8c9cda1dc6e3bffbb|
8031|26|347|66514ffdad03438ddda7145dbedbed7f2e72a294|

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);
        db_multi_exec(
           "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).