terminology

This commit is contained in:
Joey Hess 2012-10-01 18:26:47 -04:00
parent eeaa8dada8
commit 3846c7ae5e

View file

@ -31,10 +31,10 @@ 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
## repo groups
Seems like git-annex needs a way to know the classes of repos. Some
classes:
Seems like git-annex needs a way to know the groups of repos. Some
groups:
* enduser: The user interacts with this repo directly.
* archival: This repo accumulates stuff, and once it's in enough archives,
@ -43,18 +43,17 @@ classes:
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?)
Add a group.log that can assign repos to these or other groups. **done**
Some examples of using classes:
Some examples of using groups:
* 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)`
`(not group=archival) and (not copies=archival:1)`
That would make send to configure on all repos, or even set
a global `annex.accept` to it.
a global `annex.accept` to it. **done**
* Make a cloud repo only hold data until all known clients have a copy: