2022-07-20 17:19:06 +00:00
|
|
|
This is a todo for collecting changes that could lead to a v11 repository
|
|
|
|
|
version.
|
|
|
|
|
|
|
|
|
|
* Append to journal files even when annex.alwayscompact=true.
|
|
|
|
|
This can make it a lot faster in some cases.
|
|
|
|
|
See note in Annex.Branch.changeOrAppend.
|
|
|
|
|
|
|
|
|
|
It's important that this only happen when no git-annex version
|
|
|
|
|
older than 10.20220724 can plausibly be running in a repository
|
|
|
|
|
after upgrading to the repo version that enables this. Depending on the
|
|
|
|
|
timing of v11, this may need to be put in a v12 upgrade that is delayed
|
|
|
|
|
some amount of time (eg 1 year) after v11.
|
fix transfer lock file for Download to not include uuid
While redundant concurrent transfers were already prevented in most
cases, it failed to prevent the case where two different repositories were
sending the same content to the same repository. By removing the uuid
from the transfer lock file for Download transfers, one repository
sending content will block the other one from also sending the same
content.
In order to interoperate with old git-annex, the old lock file is still
locked, as well as locking the new one. That added a lot of extra code
and work, and the plan is to eventually stop locking the old lock file,
at some point in time when an old git-annex process is unlikely to be
running at the same time.
Note that in the case of 2 repositories both doing eg
`git-annex copy foo --to origin`
the output is not that great:
copy b (to origin...)
transfer already in progress, or unable to take transfer lock
git-annex: transfer already in progress, or unable to take transfer lock
97% 966.81 MiB 534 GiB/s 0sp2pstdio: 1 failed
Lost connection (fd:14: hPutBuf: resource vanished (Broken pipe))
Transfer failed
Perhaps that output could be cleaned up? Anyway, it's a lot better than letting
the redundant transfer happen and then failing with an obscure error about
a temp file, which is what it did before. And it seems users don't often
try to do this, since nobody ever reported this bug to me before.
(The "97%" there is actually how far along the *other* transfer is.)
Sponsored-by: Joshua Antonishen on Patreon
2024-03-25 18:47:38 +00:00
|
|
|
|
|
|
|
|
* Avoid locking old transfer lock file. transferFileAndLockFile
|
|
|
|
|
currently returns two lock files for Download transfers,
|
|
|
|
|
and locking both of them is unncessary work, which is only needed to
|
|
|
|
|
interoperate with old git-annex versions that only lock the old lock file
|
|
|
|
|
and not the new one.
|
|
|
|
|
|
2024-03-25 18:51:36 +00:00
|
|
|
See [[!commit f04d9574d6a56cfdf034a974f9714f0a3b8c49fa]].
|
|
|
|
|
|
fix transfer lock file for Download to not include uuid
While redundant concurrent transfers were already prevented in most
cases, it failed to prevent the case where two different repositories were
sending the same content to the same repository. By removing the uuid
from the transfer lock file for Download transfers, one repository
sending content will block the other one from also sending the same
content.
In order to interoperate with old git-annex, the old lock file is still
locked, as well as locking the new one. That added a lot of extra code
and work, and the plan is to eventually stop locking the old lock file,
at some point in time when an old git-annex process is unlikely to be
running at the same time.
Note that in the case of 2 repositories both doing eg
`git-annex copy foo --to origin`
the output is not that great:
copy b (to origin...)
transfer already in progress, or unable to take transfer lock
git-annex: transfer already in progress, or unable to take transfer lock
97% 966.81 MiB 534 GiB/s 0sp2pstdio: 1 failed
Lost connection (fd:14: hPutBuf: resource vanished (Broken pipe))
Transfer failed
Perhaps that output could be cleaned up? Anyway, it's a lot better than letting
the redundant transfer happen and then failing with an obscure error about
a temp file, which is what it did before. And it seems users don't often
try to do this, since nobody ever reported this bug to me before.
(The "97%" there is actually how far along the *other* transfer is.)
Sponsored-by: Joshua Antonishen on Patreon
2024-03-25 18:47:38 +00:00
|
|
|
(Note that the old lock file should still be deleted when cleaning up the
|
|
|
|
|
new lock file, to make sure that all the old lock files get deleted.)
|
|
|
|
|
|
|
|
|
|
It would not be great if this change were made when a git-annex version
|
|
|
|
|
10.20240227 or older was running in the repository. But it wouldn't be
|
|
|
|
|
the end of the world either, because the effect would be effectively
|
|
|
|
|
the same as the bug that the second transfer lock was added to fix.
|
|
|
|
|
Still, it would make sense to put this in a v12 upgrade that is delayed
|
|
|
|
|
some amount of time (eg 1 year) after v11.
|