Fossil Forum

Database error: database is locked: {COMMIT} -- but why, exactly?
Login

Database error: database is locked: {COMMIT} -- but why, exactly?

Database error: database is locked: {COMMIT} -- but why, exactly?

(1) By jvdh (veedeehjay) on 2022-03-16 18:01:35 [link] [source]

I have encountered the above error recently but do not quite understand the reason:

setup:

  • working on local clone of a remote "server" repo

  • a colleague also accessing the same server repo for collaboration on some text documents

  • instead of cloning the server repo he simply opened it to get his checkout (this was a two person temporary thing anyway and he assumed this would be no problem -- he had generated the server repo himself in the first place). I was not aware of him doing this and believed he used a clone. so actually I was talking to "his" repo, basically, rather than a third instance, via ssh.

I then encountered the error message mentioned in the title when trying to do fossil up and it took me some time to find out that the colleague had left running a call to fossil gdiff with some external graphical diff tool.

here are my questions:

  1. why does running gdiff against the server repo by my colleague block my own fossil up request at all? i.e. why is the database lock created (or, rather, not released after providing the diff content to the gdiff tool)?

  2. why the {COMMIT} identifier? I did not try to checkin anything, just a fossil up.

(2) By Martin Gagnon (mgagnon) on 2022-03-16 18:22:48 in reply to 1 [link] [source]

May be related: d1ef46a81d4ee5e3

why the {COMMIT} identifier?

Here the term "commit" refer to a SQL transaction, not to a fossil checkin. I guess this is directly a SQLite error message that end up on the terminal.

(4) By Martin Gagnon (mgagnon) on 2022-03-16 18:27:48 in reply to 2 [link] [source]

Stephan’s explanation is better ;-)

I don’t think you need to dig in the forum post linked above.

(3) By Stephan Beal (stephan) on 2022-03-16 18:23:10 in reply to 1 [source]

why does running gdiff against the server repo by my colleague block my own fossil up request at all? i.e. why is the database lock created (or, rather, not released after providing the diff content to the gdiff tool)?

Fossil normally doesn't close the db connection until it shuts down, which doesn't happen until after the gdiff returns. You'll see similar locking issues if you do a checkin without the -m flag, fossil opens up your editor, and you leave it sitting. Fossil is generally intended to be used one operation/command at a time, in sequence. Each user really needs their own clone.

why the {COMMIT} identifier? I did not try to checkin anything, just a fossil up.

Commit in the SQL sense, not the SCM sense. An update writes to the db inside a transaction which (on success) gets committed.

(5) By jvdh (veedeehjay) on 2022-03-16 19:18:43 in reply to 3 [link] [source]

thanks to both of you. I get it now :).