comment
This commit is contained in:
parent
5b2caf30ae
commit
059ff44e8b
1 changed files with 29 additions and 0 deletions
|
@ -0,0 +1,29 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 1"""
|
||||
date="2019-03-19T17:06:50Z"
|
||||
content="""
|
||||
This is essentially using namespacing on the remote to implement an
|
||||
equivilant of S3 versioning, though with less efficiency.
|
||||
|
||||
A remote's implementation could do the same thing and claim it supports
|
||||
versioning, without any change to the current remote interface or user
|
||||
interface.
|
||||
|
||||
Except for removing versioned content, which indeed would need to update
|
||||
the tree to reflect the removal. From Remote.Helper.ExportImport:
|
||||
|
||||
-- Removing a key from an export would need to
|
||||
-- change the tree in the export log to not include
|
||||
-- the file. Otherwise, conflicts when removing
|
||||
-- files would not be dealt with correctly.
|
||||
-- There does not seem to be a good use case for
|
||||
-- removing a key from an export in any case.
|
||||
, removeKey = \_k -> do
|
||||
warning "dropping content from an export is not supported; use `git annex export` to export a tree that lacks the
|
||||
return False
|
||||
|
||||
I think that there are two separate things here that of course would work
|
||||
well together, but neither depends on the other. Generic versioning via
|
||||
namespacing could be done with or without support for removeKey (and vice-versa).
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue