thoughts
This commit is contained in:
parent
6cae27dcf6
commit
e6a3ea3ece
1 changed files with 21 additions and 0 deletions
|
@ -1,6 +1,27 @@
|
||||||
Once files are added (or removed or moved), need to send those changes to
|
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.
|
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
|
## TODO
|
||||||
|
|
||||||
* Test MountWatcher on LXDE.
|
* Test MountWatcher on LXDE.
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue