Fossil Forum



(1) By andygoth on 2020-07-18 00:59:45 [source]

The following commands:

mkdir fossil-crash
cd fossil-crash
fossil open ~/repos/fossil.fossil f8d210aa1c150d13d6ca9d58abf9cec461e4b8c4
./fossil clone fossil.fossil

result in this error:

SQLITE_MISUSE(21): API call with NULL database connection pointer
SQLITE_MISUSE(21): misuse at line 128813 of [067291143a]
Database error: out of memory
SELECT value FROM config WHERE name='sync-url:'

The same failure happens with other protocols besides http.

Bisection reveals the failure was introduced by f11c863d91c251d0, which is a shame because I could use that feature on this project.

(2) By andygoth on 2020-07-18 01:34:37 [link] [source] in reply to 1

For now I've backed out the commit in question, along with a few things downstream of it. Here's the backout:

(3) By andygoth on 2020-07-18 04:28:19 [link] [source] in reply to 2

(4) By Marcelo Huerta (richieadler) on 2020-07-18 16:36:15 [link] [source] in reply to 3

I am glad, one of my personal projects really benefits of the multi-remotes autosyncing all at once.

(5) By andygoth on 2020-07-30 00:13:08 [link] [source] in reply to 1

Turns out there's another problem now, introduced either by the original change f11c863d91c251d0 or by the correction 857777f117eb0d5a. I used a bisect to confirm this is when things went wrong.

Cloning from one filesystem file to another results in the following:

$ fossil clone a.fossil b.fossil
SQLITE_ERROR(1): no such table: global_config in "DELETE FROM global_config WHERE name  = 'repo:/home/andy/test/b.fossil';"
Database error: no such table: global_config: {DELETE FROM global_config WHERE name  = 'repo:/home/andy/test/b.fossil';}

For now, I brought back the temporary-fix to include everything but the multi-remote capability.