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

Added a comment

Browse source
This commit is contained in:
Ilya_Shlyakhter 2019-03-26 18:27:04 +00:00 • committed by admin
parent 9b4e06d8c2
commit 1c334f74d6
1 changed files with 11 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/todo/simpler__44___trusted_export_remotes/comment_5_aeefb4803340ff993a1d6673c8e5e97b._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 5"
date="2019-03-26T18:27:04Z"
content="""
Another approach would be to let a key-value remote and an export remote be combined into one \"combo\" remote. To the user, this would look like one trusted, versioned remote supporting both key-value and export operations. Keys overwritten in the export remote would be stored in the key-value remote. Either keys or trees could be copied to the combo remote, keys going to the key-value remote and trees to the export remote. The downside is that files could not be moved directly between the backing remotes. But the inefficiency might not always matter. Also, TRANSFER and TRANSFEREXPORT could be extended to optionally accept URIs in lieu of content, and to do the transfer in the cloud.
More generically, maybe repository groups could be treated as special remotes? You'd configure the minimum number of copies of a key in a group. You could then put a key-value remote and an export remote in a group. When copying a tree to the group, if this would cause old keys to be overwritten, git-annex would first copy them to a key-value remote in the group, to preserve the per-group minimum number of copies constraint.
"""]]