Hi,

I noticed that while a clone was going on another could not be done due to
the global config being locked:

fossil: database is locked: {DELETE FROM global_config WHERE name  =
'repo:/xxx';}
SQLITE_ERROR: statement aborts at 1: [ROLLBACK] cannot rollback - no
transaction is active

Both clone and open are blocked by a clone, which is rather annoying.

I think I tracked it down to that in clone_cmd this happens:
Config database is opened.
A db_swap_connections pair happens.
This leaves the config db as main db since the last swap does nothing.
Repo database is opened, attached to the config db.
Then it seems the config db gets locked with the repo db in the clone
transaction.

The patch below makes it work, but I can't really say if it's the right way
to do it.

/Peter

Index: src/clone.c
==================================================================
--- src/clone.c
+++ src/clone.c
@@ -166,12 +166,15 @@
     }else{
       g.zLogin = db_text(0, "SELECT login FROM user WHERE cap LIKE
'%%s%%'");
     }
     fossil_print("Repository cloned into %s\n", g.argv[3]);
   }else{
+    /* Close config while opening main database */
+    db_close_config();
     db_create_repository(g.argv[3]);
     db_open_repository(g.argv[3]);
+    db_open_config(0, 0);
     db_begin_transaction();
     db_record_repository_filename(g.argv[3]);
     db_initial_setup(0, 0, zDefaultUser);
     user_select();
     db_set("content-schema", CONTENT_SCHEMA, 0);
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to