On 08/06/11 12:47, Kevin Quick wrote: > $ fossil sync PATH-TO-REPO > Bytes Cards Artifacts Deltas > Sent: 3897 82 0 0 > Error: Database error: database is locked > DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private) > Received: 118 1 0 0 > Total network traffic: 2225 bytes sent, 813 bytes received > $ > > This happens every time. I found the suggestion for "PRAGMA > journal_mode=WAL;" in sqlite mode, but that had no effect.
Actually, I've found that that happens when you have/try to open the same .fossil multiple times? I.e. I have a server (fossil server ...) on host server; I use clients typically on boxens clientX (for X in ...); The procedure always was: - fossil clone http://user@server:port/repo ~/open/repo.fossil - mkdir ~/open/repo - cd ~/open/repo - fossil open ~/open/repo.fossil - setup fossil remote-url (again;so that fossil actually asks for the pwd). No problem ever. Auto-sync in all directions works charms. But when I open the original fossil on server (say, it's lying in ~/fossilien, so I do: - mkdir ~/open/repo - cd ~/open/repo - fossil open ~/fossilien/repo.fossil ) the open works fine, but any sync / update / whatever afterwards either comes up with COMMIT : DB locked or the sql you have above: DB locked. If, on the other hand, on the server, I replicate the clientX approach (that is, fossil clone http://user@localhost:port/repo ~/open/repo.fossil; fossil open repo.fossil) everything is fine. So I think it's an issue with having file:/// level access open to a fossil repository multiple times / from multiple fossil instances? I'm just fishing the muddy waters here, but it's pretty obvious how to force the "Database error: database is locked" to appear to me. Regards, -Martin _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
