From cb54d37556bd22e53355a603a801d72dcf228960 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 7 Sep 2017 16:07:28 -0400 Subject: update --- .../comment_2_7fbbc5beb80acf32eff617ec704d5466._comment | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'doc/devblog') diff --git a/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment b/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment index fcd1eb66c..1dfdfe6de 100644 --- a/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment +++ b/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment @@ -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 necessary depending on how it implements copy. -At some point you have to pick simplicity and ability to recover from -problems over totally optimal speed though, and I think your case is a -reasonable place to draw the line. +Anyway, if the user is exporting copys of files, they're probably going to +care more about that being somewhat more efficient than about renames of +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. """]] -- cgit v1.2.3