only delete bundles on pushEmpty
This avoids some apparently otherwise unsolveable problems involving races that resulted in the manifest listing bundles that were deleted. Removed the annex-max-git-bundles config because it can't actually result in deleting old bundles. It would still be possible to have a config that controls how often to do a full push, which would avoid needing to download too many bundles on clone, as well as needing to checkpresent too many bundles in verifyManifest. But it would need a different name and description.
This commit is contained in:
parent
f544946b09
commit
3e7324bbcb
6 changed files with 53 additions and 103 deletions
|
@ -43,6 +43,13 @@ stored in such a special remote, this procedure will work:
|
|||
(Note that later bundles can update refs from the versions in previous
|
||||
bundles.)
|
||||
|
||||
When the special remote is encrypted, the GITMANIFEST and GITBUNDLE will
|
||||
also be encrypted. To decrypt those manually, see this
|
||||
[[fairly simple shell script using standard tools|tips/Decrypting_files_in_special_remotes_without_git-annex]].
|
||||
Note that, if a GITBUNDLE listed in the GITMANIFEST turns out not to exist,
|
||||
a clone should treat this the same as if the GITMANIFEST were empty.
|
||||
bundle objects are deleted when a push is made to the remote that
|
||||
deletes all refs from it, and in a race between such a push and another
|
||||
push of some refs, it is possible for the GITMANIFEST to refer to deleted
|
||||
bundles.
|
||||
|
||||
When the special remote is encrypted, both the names and content of
|
||||
the GITMANIFEST and GITBUNDLE will also be encrypted. To
|
||||
decrypt those manually, see this [[fairly simple shell script using standard tools|tips/Decrypting_files_in_special_remotes_without_git-annex]].
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue