https://sqlite.org/src fossil update stuck at 2025-04-07
(1) By G. David Butler (gdb) on 2025-05-12 18:24:32 [link] [source]
I had not done an update on SQLite stuff for a month and today did a fossil update fossil-sim.org and have:
04b9b0136daec1bcb6b5e088e8f091203d7c84b1 2025-05-12 12:17:45 UTC
Did a compile, rebuild -ifneeded then verified timeline and update. Then used this fossil to do a rebuild -ifneeded and an update on sqlite.org/src and am stuck on:
25d936b7b27d33b18bdac245bb193f7fbeaa9a7e 2025-04-07 18:29:57 UTC
I renamed my repository and checkout with a .bak extension then did a fossil clone and open and have:
f0054cc0bce4ed735796da1ea68b7773a582042b 2025-05-12 11:48:39 UTC
Why did the new fossil not update the previous repository?
(2) By Stephan Beal (stephan) on 2025-05-12 18:35:44 in reply to 1 [link] [source]
Then used this fossil to do a rebuild -ifneeded and an update on sqlite.org/src and am stuck on:
You're not the only person that's happened to. We had a "system event" on the SQLite server around that time which messed up the repo, and certain clones pulled shortly afterwards got into a "stuck" state, behaving exactly as you describe. No amount of rebuilding or using "pull -verily" gets them out of it. The only known workaround is to re-clone the SQLite repository (which you've already done).
We're unfortunately not clear on how they got stuck in that state, and this incident is the only one of its kind that we're aware of.
(3) By G. David Butler (gdb) on 2025-05-12 22:28:49 in reply to 2 [link] [source]
This seems to be something to really dig into. What kind of "system event" can "mess up the repo" when it is implemented in SQLite, which is supposed to be immune to such things?
(4) By Stephan Beal (stephan) on 2025-05-13 00:12:47 in reply to 3 [source]
What kind of "system event" can "mess up the repo" when it is implemented in SQLite, which is supposed to be immune to such things?
Our hypothesis is that corruption was introduced while copying the repo during a server migration. Shortly after that, two commits independently got the repo into an unusable state, presumably as side effects of the earlier presumed corruption. We ended up restoring from a copy which hadn't exhibited any odd symptoms, and have been oddity-free since then.
which is supposed to be immune to such things?
Not immune, but strongly resistant. One time in nearly 18 years is still a pretty solid record, IMO.
(5) By Bo Lindbergh (_blgl_) on 2025-05-13 08:42:25 in reply to 4 [link] [source]
Do you still have copies of the corrupted repo? It sounds like a case for somebody with no deadlines to worry about....
(7) By Stephan Beal (stephan) on 2025-05-13 11:19:27 in reply to 5 [link] [source]
Do you still have copies of the corrupted repo?
i'm not 100% sure, actually - Richard did the surgery at the time, while Dan and myself acted as the nurses. (It would surprise me if a copy isn't stashed away somewhere.) We have copies of one of the clones which silently fails to pull and an integrity check on that one reveals two unexpected blob hashes (i.e. corruption), but it otherwise seems to behave as expected (which is what makes corruption so insidious).
It sounds like a case for somebody with no deadlines to worry about....
No deadlines and an abundance of energy.
Are you volunteering? :)
(8) By Bo Lindbergh (_blgl_) on 2025-05-13 13:40:28 in reply to 7 [link] [source]
Are you volunteering?
Only on conditions of no deadline and no completion guarantee. :-)
(9) By Stephan Beal (stephan) on 2025-05-13 13:44:03 in reply to 8 [link] [source]
Only on conditions of no deadline and no completion guarantee. :-)
Completely fair! i'll contact you off-list later today or tomorrow about it.
@The originator of that clone (you know who you are): your remaining info (only the account name) will be scrubbed from it before passing it on.
(6) By Richard Hipp (drh) on 2025-05-13 11:04:33 in reply to 3 [link] [source]
The SQLite database was fine. It passes "PRAGMA integrity_check". But the Fossil data contained therein was slightly inconsistent, which created some subtle problems. Probably we could have figured that out and fixed it, but that would have involved taking down the website for hours, or more, and it is a busy website.