doc updates for groupwanted
This commit is contained in:
parent
417aea25be
commit
3a9a1b9f63
3 changed files with 53 additions and 27 deletions
1
debian/changelog
vendored
1
debian/changelog
vendored
|
@ -21,6 +21,7 @@ git-annex (5.20140307) UNRELEASED; urgency=medium
|
||||||
expressions. For example "standard or (include=otherdir/*)"
|
expressions. For example "standard or (include=otherdir/*)"
|
||||||
* Avoid encoding errors when using the unused log file.
|
* Avoid encoding errors when using the unused log file.
|
||||||
* vicfg: Allows editing preferred content expressions for groups.
|
* vicfg: Allows editing preferred content expressions for groups.
|
||||||
|
* groupwanted can be used in preferred content expressions.
|
||||||
|
|
||||||
-- Joey Hess <joeyh@debian.org> Thu, 06 Mar 2014 16:17:01 -0400
|
-- Joey Hess <joeyh@debian.org> Thu, 06 Mar 2014 16:17:01 -0400
|
||||||
|
|
||||||
|
|
|
@ -2,7 +2,7 @@ git-annex tries to ensure that the configured number of [[copies]] of your
|
||||||
data always exist, and leaves it up to you to use commands like `git annex
|
data always exist, and leaves it up to you to use commands like `git annex
|
||||||
get` and `git annex drop` to move the content to the repositories you want
|
get` and `git annex drop` to move the content to the repositories you want
|
||||||
to contain it. But sometimes, it can be good to have more fine-grained
|
to contain it. But sometimes, it can be good to have more fine-grained
|
||||||
control over which repositories prefer to have which content. Configuring
|
control over which content is wanted by which repositories. Configuring
|
||||||
this allows the git-annex assistant as well as
|
this allows the git-annex assistant as well as
|
||||||
`git annex get --auto`, `git annex drop --auto`, `git annex sync --content`,
|
`git annex get --auto`, `git annex drop --auto`, `git annex sync --content`,
|
||||||
etc to do smarter things.
|
etc to do smarter things.
|
||||||
|
@ -11,13 +11,13 @@ Preferred content settings can be edited using `git
|
||||||
annex vicfg`, or viewed and set at the command line with `git annex wanted`.
|
annex vicfg`, or viewed and set at the command line with `git annex wanted`.
|
||||||
Each repository can have its own settings, and other repositories will
|
Each repository can have its own settings, and other repositories will
|
||||||
try to honor those settings when interacting with it.
|
try to honor those settings when interacting with it.
|
||||||
So there's no local `.git/config` for preferred content settings.
|
(So there's no local `.git/config` for preferred content settings.)
|
||||||
|
|
||||||
[[!template id=note text="""
|
[[!template id=note text="""
|
||||||
### [[quickstart|standard_groups]]
|
### [[quickstart|standard_groups]]
|
||||||
|
|
||||||
Rather than writing your own preferred content expression, you can use
|
Rather than writing your own preferred content expression, you can use
|
||||||
several canned ones included in git-annex that are tuned to cover different
|
several standard ones included in git-annex that are tuned to cover different
|
||||||
common use cases.
|
common use cases.
|
||||||
|
|
||||||
You do this by putting a repository in a group,
|
You do this by putting a repository in a group,
|
||||||
|
@ -26,9 +26,9 @@ is standard for that group. See [[standard_groups]] for a list.
|
||||||
"""]]
|
"""]]
|
||||||
|
|
||||||
The idea is that you write an expression that files are matched against.
|
The idea is that you write an expression that files are matched against.
|
||||||
If a file matches, it's preferred to have its content stored in the
|
If a file matches, the repository wants to store its content.
|
||||||
repository. If it doesn't, it's preferred to drop its content from
|
If it doesn't, the repository wants to drop its content
|
||||||
the repository (if there are enough copies elsewhere).
|
(if there are enough copies elsewhere to allow removing it).
|
||||||
|
|
||||||
To check at the command line which files are matched by preferred content
|
To check at the command line which files are matched by preferred content
|
||||||
settings, you can use the --want-get and --want-drop options.
|
settings, you can use the --want-get and --want-drop options.
|
||||||
|
@ -74,7 +74,7 @@ and use "copies=transfer:1"
|
||||||
|
|
||||||
To decide if content should be dropped, git-annex evaluates the preferred
|
To decide if content should be dropped, git-annex evaluates the preferred
|
||||||
content expression under the assumption that the content has *already* been
|
content expression under the assumption that the content has *already* been
|
||||||
dropped. If the content would not be preferred then, the drop can be done.
|
dropped. If the content would not be wanted then, the drop can be done.
|
||||||
So, for example, `copies=2` in a preferred content expression lets
|
So, for example, `copies=2` in a preferred content expression lets
|
||||||
content be dropped only when there are currently 3 copies of it, including
|
content be dropped only when there are currently 3 copies of it, including
|
||||||
the repo it's being dropped from. This is different than running `git annex
|
the repo it's being dropped from. This is different than running `git annex
|
||||||
|
@ -83,7 +83,7 @@ drop --copies=2`, which will drop files that currently have 2 copies.
|
||||||
### difference: "present"
|
### difference: "present"
|
||||||
|
|
||||||
There's a special "present" keyword you can use in a preferred content
|
There's a special "present" keyword you can use in a preferred content
|
||||||
expression. This means that content is preferred if it's present,
|
expression. This means that content is wanted if it's present,
|
||||||
and not otherwise. This leaves it up to you to use git-annex manually
|
and not otherwise. This leaves it up to you to use git-annex manually
|
||||||
to move content around. You can use this to avoid preferred content
|
to move content around. You can use this to avoid preferred content
|
||||||
settings from affecting a subdirectory. For example:
|
settings from affecting a subdirectory. For example:
|
||||||
|
@ -91,7 +91,7 @@ settings from affecting a subdirectory. For example:
|
||||||
auto/* or (include=ad-hoc/* and present)
|
auto/* or (include=ad-hoc/* and present)
|
||||||
|
|
||||||
Note that `not present` is a very bad thing to put in a preferred content
|
Note that `not present` is a very bad thing to put in a preferred content
|
||||||
expression. It'll make it prefer to get content that's not present, and
|
expression. It'll make it want to get content that's not present, and
|
||||||
drop content that is present! Don't go there..
|
drop content that is present! Don't go there..
|
||||||
|
|
||||||
### difference: "inpreferreddir"
|
### difference: "inpreferreddir"
|
||||||
|
@ -108,15 +108,38 @@ The name of the directory can be configured using
|
||||||
|
|
||||||
### difference: "standard"
|
### difference: "standard"
|
||||||
|
|
||||||
git-annex comes with some standard preferred content expressions, that
|
git-annex comes with some built-in preferred content expressions, that
|
||||||
can be used with repositories that are in some pre-defined groups,
|
can be used with repositories that are in some [[standard_groups]].
|
||||||
as listed in [[standard_groups]].
|
|
||||||
|
|
||||||
When a repository is in exactly one such group, you can use the "standard"
|
When a repository is in exactly one such group, you can use the "standard"
|
||||||
keyword in its preferred content expression, to match whatever content
|
keyword in its preferred content expression, to match whatever content
|
||||||
the group preferrs to have. (If a repository is put into multiple standard
|
the group's expression matches.
|
||||||
|
(If a repository is put into multiple standard
|
||||||
groups, "standard" will match anything.. so don't do that!)
|
groups, "standard" will match anything.. so don't do that!)
|
||||||
|
|
||||||
Most often, the whole preferred content expression is simply "standard".
|
Most often, the whole preferred content expression is simply "standard".
|
||||||
But, you can do more complicated things, for example:
|
But, you can do more complicated things, for example:
|
||||||
"`standard or include=otherdir/*`"
|
"`standard or include=otherdir/*`"
|
||||||
|
|
||||||
|
### difference: "groupwanted"
|
||||||
|
|
||||||
|
The "groupwanted" keyword can be used to refer to a preferred content
|
||||||
|
expression that is associated with a group. This is like the "standard"
|
||||||
|
keyword, but you can set up groupwanted preferred content expressions
|
||||||
|
using `git annex vicfg`.
|
||||||
|
|
||||||
|
Note that when writing a groupwanted preferred content expression,
|
||||||
|
you can use all of the keywords listed above, including "standard".
|
||||||
|
(But not "groupwanted".)
|
||||||
|
|
||||||
|
For example, to make a variant of the standard client preferred content
|
||||||
|
expression that does not want files in the "out" directory, you
|
||||||
|
could set `groupwanted client = standard and exclude=out/*`.
|
||||||
|
Then repositories that are in the client group and have their preferred
|
||||||
|
content expression set to "groupwanted" will use that, while
|
||||||
|
other client repositories that have their preferred content expression
|
||||||
|
set to "standard" will use the standard expression.
|
||||||
|
|
||||||
|
Or, you could make a new group, with your own custom preferred content
|
||||||
|
expression tuned for your needs, and every repository you put in this
|
||||||
|
group and make its preferred content be "groupwanted" will use it.
|
||||||
|
|
|
@ -1,16 +1,16 @@
|
||||||
git-annex comes with some pre-defined [[preferred_content]] settings, that can
|
git-annex comes with some built-in [[preferred_content]] settings, that can
|
||||||
be used with repositories that are in special groups. To make a
|
be used with repositories that are in special groups. To make a
|
||||||
repository use one of these, just set its preferred content expression
|
repository use one of these, just set its preferred content expression
|
||||||
to "standard", and put it in one of these groups.
|
to "standard", and put it in one of these groups.
|
||||||
|
|
||||||
(Note that most of these standard expressions also make the repository
|
(Note that most of these standard expressions also make the repository
|
||||||
prefer any content that is only currently available on untrusted and
|
want to get any content that is only currently available on untrusted and
|
||||||
dead repositories. So if an untrusted repository gets connected,
|
dead repositories. So if an untrusted repository gets connected,
|
||||||
any repository that can will back it up.)
|
any repository that can will back it up.)
|
||||||
|
|
||||||
### client
|
### client
|
||||||
|
|
||||||
All content is preferred, unless it's for a file in a "archive" directory,
|
All content is wanted, unless it's for a file in a "archive" directory,
|
||||||
which has reached an archive repository, or is unused.
|
which has reached an archive repository, or is unused.
|
||||||
|
|
||||||
`(((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or roughlylackingcopies=1`
|
`(((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) and not unused) or roughlylackingcopies=1`
|
||||||
|
@ -38,34 +38,36 @@ will be added later.
|
||||||
|
|
||||||
### backup
|
### backup
|
||||||
|
|
||||||
All content is preferred.
|
All content is wanted. Even content of old/deleted files.
|
||||||
|
|
||||||
`include=* or unused`
|
`include=* or unused`
|
||||||
|
|
||||||
### incremental backup
|
### incremental backup
|
||||||
|
|
||||||
Only prefers content that's not already backed up to another backup
|
Only wants content that's not already backed up to another backup
|
||||||
or incremental backup repository.
|
or incremental backup repository.
|
||||||
|
|
||||||
`((include=* or unused) and (not copies=backup:1) and (not copies=incrementalbackup:1)) or approxlackingcopies=1`
|
`((include=* or unused) and (not copies=backup:1) and (not copies=incrementalbackup:1)) or approxlackingcopies=1`
|
||||||
|
|
||||||
### small archive
|
### small archive
|
||||||
|
|
||||||
Only prefers content that's located in an "archive" directory, and
|
Only wants content that's located in an "archive" directory, and
|
||||||
only if it's not already been archived somewhere else.
|
only if it's not already been archived somewhere else.
|
||||||
|
|
||||||
`((include=*/archive/* or include=archive/*) and not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
|
`((include=*/archive/* or include=archive/*) and not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
|
||||||
|
|
||||||
### full archive
|
### full archive
|
||||||
|
|
||||||
All content is preferred, unless it's already been archived somewhere else.
|
All content is wanted, unless it's already been archived somewhere else.
|
||||||
|
|
||||||
`(not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
|
`(not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
|
||||||
|
|
||||||
Note that if you want to archive multiple copies (not a bad idea!),
|
Note that if you want to archive multiple copies (not a bad idea!),
|
||||||
you should instead configure all your archive repositories with a
|
you can set `groupwanted archive` to a version of
|
||||||
version of the above preferred content expression with a larger
|
the above preferred content expression with a larger number of copies
|
||||||
number of copies.
|
than 1. Then make the archive repositories have a preferred
|
||||||
|
content expression of "groupwanted" in order to use your modified
|
||||||
|
version.
|
||||||
|
|
||||||
### source
|
### source
|
||||||
|
|
||||||
|
@ -83,12 +85,12 @@ data until a copy has been sent to some other repository.
|
||||||
This gives you nearly full manual control over what content is stored in the
|
This gives you nearly full manual control over what content is stored in the
|
||||||
repository. This allows using the [[assistant]] without it trying to keep a
|
repository. This allows using the [[assistant]] without it trying to keep a
|
||||||
local copy of every file. Instead, you can manually run `git annex get`,
|
local copy of every file. Instead, you can manually run `git annex get`,
|
||||||
`git annex drop`, etc to manage content. Only content that is present
|
`git annex drop`, etc to manage content. Only content that is already
|
||||||
is preferred.
|
present is wanted.
|
||||||
|
|
||||||
The exception to this manual control is that content that a client
|
The exception to this manual control is that content that a client
|
||||||
repository would not want is not preferred. So, files in archive
|
repository would not want is not wanted. So, files in archive
|
||||||
directories are not preferred once their content has
|
directories are not wanted once their content has
|
||||||
reached an archive repository.
|
reached an archive repository.
|
||||||
|
|
||||||
`present and ($client)`
|
`present and ($client)`
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue