Ticket UUID: | 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] | ||
Description & Comments: | |||
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: Any chance for someone to look at it? drh added on 2011-02-07 21:43:20 UTC: anonymous claiming to be viric added on 2011-02-10 20:54:49 UTC: 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:
anonymous claiming to be viric added on 2011-02-11 12:24:41 UTC: |
Attachments:
- deltas.patch [download] added by anonymous on 2011-02-10 21:04:31. [details]