avoid interrupted push leaving remote without a manifest
Added a backup manifest key, which is used if the main manifest key is not present. When uploading a new Manifest, it makes sure that it never drops one key except when the other key is present. It's entirely possible for the two manifest keys to get out of sync, due to races. The main one wins when it's present, it is possible for the main one being dropped to expose the backup one, which has a different push recorded.
This commit is contained in:
parent
594ca2fd3a
commit
3a38520aac
4 changed files with 67 additions and 67 deletions
|
@ -4,9 +4,10 @@ repository to a special remote, and later cloning from it.
|
|||
This adds two new key types to git-annex, GITMANIFEST and a GITBUNDLE.
|
||||
|
||||
GITMANIFEST--$UUID is the manifest for a git repository stored in the
|
||||
git-annex repository with that UUID.
|
||||
git-annex repository with that UUID. When that is not present,
|
||||
GITMANIFEST--$UUID.bak is a backup copy that can be used instead.
|
||||
|
||||
GITBUNDLE--$UUID-sha256 is a git bundle.
|
||||
GITBUNDLE--$UUID-$sha256 is a git bundle.
|
||||
|
||||
# format of the manifest file
|
||||
|
||||
|
@ -23,11 +24,10 @@ and are in the process of being deleted.
|
|||
In an exporttree=yes remote, the GITMANIFEST and GITBUNDLE objects are
|
||||
stored in the remote, under the `.git/annex/objects/` path.
|
||||
|
||||
# multiple GITMANIFEST files
|
||||
# multiple special remotes in the same place
|
||||
|
||||
Usually there will only be one per special remote, but it's possible for
|
||||
multiple special remotes to point to the same object storage, and if so
|
||||
multiple GITMANIFEST objects can be stored.
|
||||
It's possible for multiple special remotes to point to the same
|
||||
object storage.
|
||||
|
||||
This is why the UUID of the special remote is included in the GITMANIFEST
|
||||
key, and in the annex:: uri.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue