don't support removing content from export with removeKey
There does not seem to be a use case for supporting that, and it would need a lot of complication to support it in a way that allows eventual consistency when two repositories are updating the same export. This commit was sponsored by Henrik Riomar on Patreon.
This commit is contained in:
parent
ac4c8df2ca
commit
4a45f34fe1
2 changed files with 9 additions and 46 deletions
|
@ -117,20 +117,15 @@ adjustExportable r = case M.lookup "exporttree" (config r) of
|
|||
warning $ "exported content cannot be verified due to using the " ++ formatKeyVariety (keyVariety k) ++ " backend"
|
||||
return False
|
||||
, retrieveKeyFileCheap = \_ _ _ -> return False
|
||||
-- Remove all files a key was exported to.
|
||||
, removeKey = \k -> do
|
||||
locs <- liftIO $ getExportLocation db k
|
||||
ea <- exportActions r
|
||||
oks <- forM locs $ \loc ->
|
||||
ifM (removeExport ea k loc)
|
||||
( do
|
||||
liftIO $ do
|
||||
removeExportLocation db k loc
|
||||
flushDbQueue db
|
||||
removeEmptyDirectories ea db loc [k]
|
||||
, return False
|
||||
)
|
||||
return (and oks)
|
||||
-- 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 files you want to remove"
|
||||
return False
|
||||
-- Can't lock content on exports, since they're
|
||||
-- not key/value stores, and someone else could
|
||||
-- change what's exported to a file at any time.
|
||||
|
|
|
@ -38,38 +38,6 @@ Work is in progress. Todo list:
|
|||
Updating the export db could diff the last exported treeish with the
|
||||
logged treeish. Add/delete exported files from the database to get
|
||||
it to the same state as the remote database.
|
||||
But, removeKey from an export makes the diff approach problimatic;
|
||||
see below.
|
||||
|
||||
* removeKey from an export is problimatic in distributed context
|
||||
|
||||
A file can be removed from an export via removeKey,
|
||||
which updates the export db and location log, but does not update
|
||||
the export log. This is problimatic when multiple repos are updating
|
||||
an export.
|
||||
|
||||
1. In repo A, file F with content K is exported
|
||||
2. In repo B, file F with content K' is exported, since F changed in the
|
||||
exported treeish.
|
||||
3. In repo A, file F is removed from the export, which results in
|
||||
K being removed from the location log for the export.
|
||||
|
||||
Did #3 happen before or after #2?
|
||||
If #3 occurred before #2, then K' is present in the export
|
||||
and the location log is correct.
|
||||
If #3 occurred after #2, and A and B's git-annex branches
|
||||
were not synced, then K' was accidentially removed
|
||||
from the export, and the location log is now wrong.
|
||||
|
||||
Is there any reason to allow removeKey from an export?
|
||||
Why would someone want to drop a single file from an export?
|
||||
Why not remove the file from a tree, and export the new tree?
|
||||
|
||||
(Alternatively, removeKey could itself update the exported tree,
|
||||
removing the file from it, and update the export log accordingly.
|
||||
This would avoid the problem. But that's complication and it would be
|
||||
rather slow and bloat the git repo with a lot of intermediate trees
|
||||
when dropping multiple keys.)
|
||||
|
||||
* git-annex sync to export and export tracking branch
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue