update
Decided not to use the annexobjects location for exportTempName. There doesn't seem to be any actual benefit to doing that, because an export that renames to exportTempName always renames it back from that to another location. Also the annexobjects directory won't actually help with the paired rename issue.
This commit is contained in:
parent
ee076b68f5
commit
6b63449133
2 changed files with 7 additions and 6 deletions
|
@ -16,9 +16,6 @@ keys, in order to support exporttree=yes remotes.
|
|||
Another place this would be useful is
|
||||
[[proxying to exporttree=yes special remotes|design/passthrough_proxy]].
|
||||
|
||||
This could also solve [[todo/export_paired_rename_innefficenctcy]]
|
||||
cleanly.
|
||||
|
||||
With this change, a user could just `git-annex copy --to remote`
|
||||
and copy whatever files they want into it. Then later
|
||||
`git-annex export master --to remote` would efficiently update the tree
|
||||
|
@ -90,7 +87,7 @@ If the annexobjects directory only gets keys uploaded to it, and never had
|
|||
exported files renamed into it, its content will always be as expected, and
|
||||
perhaps the remote does not need to be untrusted.
|
||||
|
||||
OTOH, if an exported file that is being deleted (or pairwise renamed) in an
|
||||
OTOH, if an exported file that is being deleted in an
|
||||
updated export gets renamed into the annexobjects directory, it's possible
|
||||
that the file has in fact been overwritten with other content (by git-annex
|
||||
in another clone of the repository), and so the object in annexobjects
|
||||
|
|
|
@ -33,8 +33,12 @@ Planned schedule of work:
|
|||
* Working on `exportreeplus` branch which is groundwork for proxying to
|
||||
exporttree=yes special remotes.
|
||||
|
||||
* `git-annex export` when renaming an exported file to a temporary name
|
||||
should use the annexobjects location.
|
||||
* `git-annex export` when unexporting a deleted file from the tree should
|
||||
rename it to the annexobjects location. This would avoid needing to
|
||||
re-upload it again in the case where it's preferred content of the
|
||||
remote. Currently eg, a sync will unexport the file and then re-upload
|
||||
it. If it's not preferred content, sync will drop it from the
|
||||
annexobjects location.
|
||||
|
||||
## items deferred until later for p2p protocol over http
|
||||
|
||||
|
|
Loading…
Reference in a new issue