From 0d0c891ff9ee72fca6f9c9dd6dff186d1727f06a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 1 May 2024 12:18:14 -0400 Subject: [PATCH] add headers for tocs --- doc/design/balanced_preferred_content.mdwn | 2 ++ doc/design/passthrough_proxy.mdwn | 2 ++ doc/todo/proving_preferred_content_behavior.mdwn | 4 ++-- doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn | 4 ++++ 4 files changed, 10 insertions(+), 2 deletions(-) diff --git a/doc/design/balanced_preferred_content.mdwn b/doc/design/balanced_preferred_content.mdwn index c69f92fd04..cd93d89313 100644 --- a/doc/design/balanced_preferred_content.mdwn +++ b/doc/design/balanced_preferred_content.mdwn @@ -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: diff --git a/doc/design/passthrough_proxy.mdwn b/doc/design/passthrough_proxy.mdwn index fc88648e04..3b41821af1 100644 --- a/doc/design/passthrough_proxy.mdwn +++ b/doc/design/passthrough_proxy.mdwn @@ -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 diff --git a/doc/todo/proving_preferred_content_behavior.mdwn b/doc/todo/proving_preferred_content_behavior.mdwn index 4ad7c04187..b98166fade 100644 --- a/doc/todo/proving_preferred_content_behavior.mdwn +++ b/doc/todo/proving_preferred_content_behavior.mdwn @@ -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`. diff --git a/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn b/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn index 1211335f8d..d4ffbd3f75 100644 --- a/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn +++ b/doc/todo/track_free_space_in_repos_via_git-annex_branch.mdwn @@ -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.