add headers for tocs

This commit is contained in:
Joey Hess 2024-05-01 12:18:14 -04:00
parent 4cd2c980d2
commit 0d0c891ff9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 10 additions and 2 deletions

View file

@ -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:

View file

@ -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

View file

@ -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`.

View file

@ -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.