oops, I misread, still happens for adjusted branches

This commit is contained in:
Joey Hess 2021-10-20 13:45:56 -04:00
parent 3f3a2d290f
commit 2801528eb2
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 8 additions and 9 deletions

View file

@ -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 * git-annex get when run as the first git-annex command in a new repo
did not populate all unlocked files. did not populate all unlocked files.
(Reversion in version 8.20210621) (Reversion in version 8.20210621)
* Avoid a sqlite crash on Windows SubSystem for Linux (WSL) * Avoid a some sqlite crashes on Windows SubSystem for Linux (WSL).
when entering an adjusted branch.
-- Joey Hess <id@joeyh.name> Mon, 11 Oct 2021 14:09:13 -0400 -- Joey Hess <id@joeyh.name> Mon, 11 Oct 2021 14:09:13 -0400

View file

@ -3,14 +3,14 @@
subject="""comment 7""" subject="""comment 7"""
date="2021-10-20T17:04:09Z" date="2021-10-20T17:04:09Z"
content=""" 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 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 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 involved in whatever locking problem there is on WSL.
fixed the main one, the fact that fix works makes me even more suspicious
about situations where there are multiple database connections.
Commit [[!commit d0ef8303cf8c4f40a1d17bd134af961fd9917ca4]] eliminates that Commit [[!commit d0ef8303cf8c4f40a1d17bd134af961fd9917ca4]] eliminates that
second connection. But there's some chance I'll have to revert it. second connection. But there's some chance I'll have to revert it.

View 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. like Sqlite.ErrorIO is handled, waiting for up to 1/10th of a second.
But perhaps that would not be enough of a wait. But perhaps that would not be enough of a wait.
Anyway, this is a note to myself: If concurrent git-annex processes on Windows Anyway, this is a note to myself: If all else fails,
still have this problem, try catching Sqlite.ErrorProtocol and experiment try catching Sqlite.ErrorProtocol and experiment
with different ways to handle it. with different ways to handle it.
"""]] """]]