diff options
author | 2013-03-20 14:23:32 -0400 | |
---|---|---|
committer | 2013-03-20 14:23:32 -0400 | |
commit | 7eb37d0ef24d2db1e6080775e90b89e778e78fb9 (patch) | |
tree | 4d5787d9c3885676124e982d5d1ef539f10b5530 | |
parent | a6d26237a0f7b61d1aee4ea7b6e8b854435899cd (diff) |
thoughts
-rw-r--r-- | doc/design/assistant/syncing.mdwn | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/doc/design/assistant/syncing.mdwn b/doc/design/assistant/syncing.mdwn index 79c12d312..d27a50bec 100644 --- a/doc/design/assistant/syncing.mdwn +++ b/doc/design/assistant/syncing.mdwn @@ -1,6 +1,27 @@ Once files are added (or removed or moved), need to send those changes to all the other git clones, at both the git level and the key/value level. +## efficiency + +Currently after each file transfer (upload or download), a git sync is done +to all remotes. This is rather a lot of work, also it prevents collecting +presence changes to the git-annex branch into larger commits, which would +save disk space over time. + +In many cases, this sync is necessary. For example, when a file is uploaded +to a transfer remote, the location change needs to be synced out so that +other clients know to grab it. + +Or, when downloading a file from a drive, the sync lets other locally +paired repositories know we got it, so they can download it from us. +OTOH, this is also a case where a sync is sometimes unnecessary, since +if we're going to upload the file to them after getting it, the sync +only perhaps lets them start downloading it before our transfer queue +reaches a point where we'd upload it. + +Do we need all the mapping stuff discussed below to know when we can avoid +syncs? + ## TODO * Test MountWatcher on LXDE. |