66 lines
2.4 KiB
Markdown
66 lines
2.4 KiB
Markdown
Some remotes are too small to sync everything to them.
|
|
|
|
The case of a small remote on a gadget that the user interacts with,
|
|
such as a phone, where they may want to request it get content
|
|
it doesn't currently have, is covered by the [[partial_content]] page.
|
|
|
|
But often the remote is just a removable drive or a cloud remote,
|
|
that has a limited size. This page is about making the assistant do
|
|
something smart with such remotes.
|
|
|
|
## specifying what data belongs on a remote
|
|
|
|
Imagine a per-remote `annex-accept` setting, that matches things that
|
|
should be stored on the remote.
|
|
|
|
For example, a MP3 player might use:
|
|
`smallerthan(10mb) and filename(*.mp3) and (not filename(junk/*))`
|
|
|
|
Adding that as a filter to files sent to a remote should be
|
|
straightforward.
|
|
|
|
A USB drive that is carried between three laptops and used to sync data
|
|
between them might use: `not (in=laptop1 and in=laptop2 and in=laptop3)`
|
|
|
|
In this case, transferring data from the usb repo should
|
|
check if `annex-accept` then rejects the data, and if so, drop it
|
|
from the repo. So once all three laptops have the data, it is
|
|
pruned from the transfer drive.
|
|
|
|
It may make sense to have annex-accept info also be stored in the git-annex
|
|
branch, for settings that should apply to a repo globally. Does it make
|
|
sense to have local configuration too?
|
|
|
|
## repo classes
|
|
|
|
Seems like git-annex needs a way to know the classes of repos. Some
|
|
classes:
|
|
|
|
* enduser: The user interacts with this repo directly.
|
|
* archival: This repo accumulates stuff, and once it's in enough archives,
|
|
it tends to get removed from other places.
|
|
* transfer: This repo is used to transfer data between enduser repos,
|
|
it does not hold data for long periods of time, and tends to have a
|
|
limited size.
|
|
|
|
Add a class.log that can assign repos to these or other classes.
|
|
(Should a repo be allowed to be in multiple classes?)
|
|
|
|
Some examples of using classes:
|
|
|
|
* Want to remove content from a repo, if it's not an archival repo,
|
|
and the content has reached at least one archival repo:
|
|
|
|
`(not class=archival) and (not copies=archival:1)`
|
|
|
|
That would make send to configure on all repos, or even set
|
|
a global `annex.accept` to it.
|
|
|
|
* Make a cloud repo only hold data until all known clients have a copy:
|
|
|
|
`not inall(enduser)`
|
|
|
|
## configuration
|
|
|
|
The above is all well and good for those who enjoy boolean algebra, but
|
|
how to configure these sorts of expressions in the webapp?
|