mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

v7 bug review and cleanup

Browse source
This commit is contained in:
Joey Hess 2019-08-28 12:13:31 -04:00
parent e804f48f82
commit 6b27fc58d0
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 35 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2019-08-28T16:05:53Z"
content="""
Since it's not clear from the above, git only behaves this way when the
empty file is unlocked. So `git annex lock` is a good workaround too.
(Also, `git annex export` has since gotten the ability to export
non-annexed files, for the record.)
"""]]

6
doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn
View file

@ -60,3 +60,9 @@ Oh yeah, I am still discovering this powerfull git annex tool.
In fact, collegues and I are forming a group during the process to exchange about different use cases, encountered problems and help each other.
[[!meta title="v7: intermittent sqlite ErrorIO crash (especially in WSL)"]]
> This bug still exists, and there's a more recent bug report
> documenting how it behaves in WSL now. <http://git-annex.branchable.com/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/>
>
> So I don't think there's any point leaving this open, closing as a
> duplicate. [[done]] --[[Joey]]

3
doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn
View file

@ -82,3 +82,6 @@ fatal: Out of memory, realloc failed
Git Annex is unique piece of Art, there is nothing like it.
> This bug got fixed in git. I just tested with 2.23 and verified it's
> [[done]] --[[Joey]]

22
doc/todo/v7_path_toward_default.mdwn
View file

@ -46,13 +46,21 @@ Since v5 repos and v7 repos not using unlocked files are functionally
almost identical, this is unlikely to break much. Unlocking files will of
course change behavior though.
The only significant difference is that Annex.Content in v7
reads and writes to the keys database. So any problem with the database
code could prevent using git-annex. WSL has such a problem currently,
but it doesn't seem to affect using v7 repos, only adjusted branches.
<http://git-annex.branchable.com/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/>
(Actually, v5 does read and write to the keys database some too,
though unncessarily so.)
When not using unlocked files, the only significant difference is that
Annex.Content in v7 reads and writes to the keys database. So any problem
with the database code could prevent using git-annex.
* WSL has such a problem currently,
but it doesn't seem to affect using v7 repos, only adjusted branches.
<http://git-annex.branchable.com/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/>
* A 2016 bug reported the keys database not working on lustre,
presumably due to sqlite needing part of POSIX that lustre does not provide
or something.
<http://git-annex.branchable.com/bugs/drop_blows_on_lustre__58___SQLite3_returned_ErrorIO/>
There are also some slight performance differences, but they go both ways,
for example the pre-commit hook is faster in v7 than v5, but v7 runs git
diff in reconcileStaged.
A concern is that a v5 repository may be used by multiple machines,
some not supporting v7 and some that do. If one upgrades to v7