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

more todo

Browse source
This commit is contained in:
Joey Hess 2019-03-05 14:55:22 -04:00
parent f7be2e9d37
commit 9df9a3f82b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 20 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
doc/todo/import_tree.mdwn
View file

@ -10,6 +10,26 @@ this.
## implementation notes
* startExport uses checkPresentExport, but when there's a modified file,
it's not unexported, so it present, so checkPresentExport succeeds,
and so startExport does the wrong thing. Seems to indicate checkPresentExport
needs to be replaced too.
* Is renameExport safe to use with an import?
When a rename() is done, it could result in a modified file being
renamed. But this would not result in data loss; the next import would
see the modification and import it from the new name. The only
potentially confusing thing is that there was essentially a conflict, and
it got resolved in a way the user may not expect.
But.. S3 implements rename as a copy followed by a
delete. But if there's a race, that means that the modified content does
get deleted.
So, it seems it's not safe.
Probably simplest to just make it not be provided for import remotes.
* Should the ContentIdentifier db be multiwriter? It would simplify
the situation with the long-lived lock of it in adjustExportImport