add headers for tocs
This commit is contained in:
parent
4cd2c980d2
commit
0d0c891ff9
4 changed files with 10 additions and 2 deletions
|
@ -1,5 +1,7 @@
|
|||
[[!toc ]]
|
||||
|
||||
## motivations
|
||||
|
||||
Say we have 2 drives and want to fill them both evenly with files,
|
||||
different files in each drive. Currently, preferred content cannot express
|
||||
that entirely:
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
[[!toc ]]
|
||||
|
||||
## motivations
|
||||
|
||||
When [[balanced_preferred_content]] is used, there may be many repositories
|
||||
in a location -- either a server or a cluster -- and getting any given file
|
||||
may need to access any of them. Configuring remotes for each repository
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
[[!toc ]]
|
||||
|
||||
## motivating examples
|
||||
|
||||
Preferred content expressions can be complicated to write and reason about.
|
||||
A complex expression can involve lots of repositories that can get into
|
||||
different states, and needs to be written to avoid unwanted behavior.
|
||||
|
@ -8,8 +10,6 @@ It would be very handy to provide some way to prove things about behavior
|
|||
of preferred content expressions, or a way to simulate the behavior of a
|
||||
network of git-annex repositories with a given preferred content configuration
|
||||
|
||||
## motivating examples
|
||||
|
||||
For example, consider two reposities A and B. A is in group M and B is in
|
||||
group N. A has preferred content `not inallgroup=N` and B has `not inallgroup=M`.
|
||||
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
[[!toc ]]
|
||||
|
||||
## motivations
|
||||
|
||||
If the total space available in a repository for annex objects is recorded
|
||||
on the git-annex branch (by the user running a command probably, or perhaps
|
||||
automatically), then it is possible to examine the git-annex branch and
|
||||
|
@ -13,6 +15,8 @@ it can be redirected to be stored on another repository in the same group.
|
|||
This was actually a fairly common feature request early on in git-annex
|
||||
and I probably should have thought about it more back then!
|
||||
|
||||
## implementation
|
||||
|
||||
`git-annex info` has recently started summing up the sizes of repositories
|
||||
from location logs, and is well optimised. In my big repository, that takes
|
||||
8.54 seconds of its total runtime.
|
||||
|
|
Loading…
Reference in a new issue