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

update

Browse source
This commit is contained in:
Joey Hess 2017-09-07 16:07:28 -04:00
parent a55b2045ad
commit 165725b9df
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 22 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

13
doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment
View file

@ -13,7 +13,14 @@ efficiently, by moving to the single temp file and copying. Although it
might still involve the special remote doing more work than strictly might still involve the special remote doing more work than strictly
necessary depending on how it implements copy. necessary depending on how it implements copy.
At some point you have to pick simplicity and ability to recover from Anyway, if the user is exporting copys of files, they're probably going to
problems over totally optimal speed though, and I think your case is a care more about that being somewhat more efficient than about renames of
reasonable place to draw the line. pairs of those copies being optimally efficient..
Handling it fully optimally, with only one temp file per key,
would require analizing the change and finding pairs of renames
that swap filenames and handling each pair in turn. I suppose that
is doable, just needs a better data structure than I have now.
I've added a note to my todo list and the design document, but
no promises.
"""]] """]]

12
doc/todo/export.mdwn
View file

@ -26,3 +26,15 @@ Work is in progress. Todo list:
to get populated based on the export log in these cases. to get populated based on the export log in these cases.
* Support export to aditional special remotes (S3 etc) * Support export to aditional special remotes (S3 etc)
* Support export to external special remotes. * Support export to external special remotes.
Low priority:
* When there are two pairs of duplicate files, and the filenames are
swapped around, the current rename handling renames both dups to a single
temp file, and so the other file in the pair gets re-uploaded
unncessarily. This could be improved.
Perhaps: Find pairs of renames that swap content between two files.
Run each pair in turn. Then run the current rename code. Although this
still probably misses cases, where eg, content cycles amoung 3 files, and
the same content amoung 3 other files. Is there a general algorythm?