oops, I misread, still happens for adjusted branches
authorJoey Hess <joeyh@joeyh.name>
Wed, 20 Oct 2021 17:45:56 +0000 (13:45 -0400)
committerJoey Hess <joeyh@joeyh.name>
Wed, 20 Oct 2021 17:45:56 +0000 (13:45 -0400)
CHANGELOG
doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_8_cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment
doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_9_b0700fdf101f6cc883857b293cd35267._comment

index 9d8052c2e8e3cf6a0a7094c141bb9b37c00654c2..d47b374dd50315e83413ad953c677365d34e6fe1 100644 (file)
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -17,8 +17,7 @@ git-annex (8.20211012) UNRELEASED; urgency=medium
   * git-annex get when run as the first git-annex command in a new repo
     did not populate all unlocked files.
     (Reversion in version 8.20210621)
-  * Avoid a sqlite crash on Windows SubSystem for Linux (WSL)
-    when entering an adjusted branch.
+  * Avoid a some sqlite crashes on Windows SubSystem for Linux (WSL).
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 Oct 2021 14:09:13 -0400
 
index 88a1727d0e4755f75f58a1cd40e033cd2dee73af..f7a78a6a5071554dff2a257534631f74457ce18e 100644 (file)
@@ -3,14 +3,14 @@
  subject="""comment 7"""
  date="2021-10-20T17:04:09Z"
  content="""
-@asakurareiko oh excellent news!
+@asakurareiko oh that's encouraging that I seem to be on the right track.
 
-Before I saw that it's apparently fixed, I noticed that
+Adjusted branches still have the same error?
+
+I noticed that
 git-annex opened a second connection to the database for writes, in
 addition to the connection it used for reads. That seems likely to be
-involved in whatever locking problem there is on WSL. While maybe I already
-fixed the main one, the fact that fix works makes me even more suspicious
-about situations where there are multiple database connections.
+involved in whatever locking problem there is on WSL.
 
 Commit [[!commit d0ef8303cf8c4f40a1d17bd134af961fd9917ca4]] eliminates that
 second connection. But there's some chance I'll have to revert it.
index d86b66e14609b07bac616489323c9c902e991dfe..3761132d4b87aa5370cc3044de25816cab676bce 100644 (file)
@@ -17,7 +17,7 @@ which would not be helpful. So perhaps it would be better to handle it
 like Sqlite.ErrorIO is handled, waiting for up to 1/10th of a second.
 But perhaps that would not be enough of a wait.
 
-Anyway, this is a note to myself: If concurrent git-annex processes on Windows
-still have this problem, try catching Sqlite.ErrorProtocol and experiment
+Anyway, this is a note to myself: If all else fails,
+try catching Sqlite.ErrorProtocol and experiment
 with different ways to handle it.
 """]]