thoughts on handling renames efficiently
This gets complicated, but I think this design will work! This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
parent
a1cc9ec0fd
commit
1ec3a9eb05
2 changed files with 39 additions and 9 deletions
|
@ -19,7 +19,11 @@ Work is in progress. Todo list:
|
|||
|
||||
* `git annex get --from export` works in the repo that exported to it,
|
||||
but in another repo, the export db won't be populated, so it won't work.
|
||||
Maybe just show a useful error message in this case?
|
||||
Maybe just show a useful error message in this case?
|
||||
However, exporting from one repository and then trying to update the
|
||||
export from another repository also doesn't work right, because the
|
||||
export database is not populated. So, seems that the export database needs
|
||||
to get populated based on the export log in these cases.
|
||||
* Efficient handling of renames.
|
||||
* Support export to aditional special remotes (S3 etc)
|
||||
* Support export to external special remotes.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue