mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

DOC: minor typos and rewording in few docs

Browse source
This commit is contained in:
Yaroslav Halchenko 2014-12-04 22:25:00 -05:00
parent bf84014bce
commit 0efe9825d0
2 changed files with 13 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/design/external_special_remote_protocol.mdwn
View file

@ -91,14 +91,14 @@ send one of the corresponding replies listed in the next section.
The following requests *must* all be supported by the special remote. The following requests *must* all be supported by the special remote.
* `INITREMOTE` * `INITREMOTE`
Request that the remote initialize itself. This is where any one-time Requests the remote to initialize itself. This is where any one-time
setup tasks can be done, for example creating an Amazon S3 bucket. setup tasks can be done, for example creating an Amazon S3 bucket.
Note: This may be run repeatedly over time, as a remote is initialized in Note: This may be run repeatedly over time, as a remote is initialized in
different repositories, or as the configuration of a remote is changed. different repositories, or as the configuration of a remote is changed.
(Both `git annex initremote` and `git-annex enableremote` run this.) (Both `git annex initremote` and `git-annex enableremote` run this.)
So any one-time setup tasks should be done idempotently. So any one-time setup tasks should be done idempotently.
* `PREPARE` * `PREPARE`
Tells the special remote it's time to prepare itself to be used. Tells the remote that it's time to prepare itself to be used.
Only INITREMOTE can come before this. Only INITREMOTE can come before this.
* `TRANSFER STORE|RETRIEVE Key File` * `TRANSFER STORE|RETRIEVE Key File`
Requests the transfer of a key. For STORE, the File is the file to upload; Requests the transfer of a key. For STORE, the File is the file to upload;
@ -110,20 +110,20 @@ The following requests *must* all be supported by the special remote.
Multiple transfers might be requested by git-annex, but it's fine for the Multiple transfers might be requested by git-annex, but it's fine for the
program to serialize them and only do one at a time. program to serialize them and only do one at a time.
* `CHECKPRESENT Key` * `CHECKPRESENT Key`
Requests the remote check if a key is present in it. Requests the remote to check if a key is present in it.
* `REMOVE Key` * `REMOVE Key`
Requests the remote remove a key's contents. Requests the remote to remove key's contents.
The following requests can optionally be supported. If not handled, The following requests can optionally be supported. If not handled,
replying with `UNSUPPORTED-REQUEST` is acceptable. replying with `UNSUPPORTED-REQUEST` is acceptable.
* `GETCOST` * `GETCOST`
Requests the remote return a use cost. Higher costs are more expensive. Requests the remote to return a use cost. Higher costs are more expensive.
(See Config/Cost.hs for some standard costs.) (See Config/Cost.hs for some standard costs.)
* `GETAVAILABILITY` * `GETAVAILABILITY`
Requests the remote send back an `AVAILABILITY` reply. Requests the remote to send back an `AVAILABILITY` reply.
If the remote replies with `UNSUPPORTED-REQUEST`, its availability If the remote replies with `UNSUPPORTED-REQUEST`, its availability
is asssumed to be global. So, only remotes that are only reachable is assumed to be global. So, only remotes that are only reachable
locally need to worry about implementing this. locally need to worry about implementing this.
More optional requests may be added, without changing the protocol version, More optional requests may be added, without changing the protocol version,

12
doc/internals.mdwn
View file

@ -17,7 +17,7 @@ See [[hashing]] for details.
Each subdirectory has the [[name_of_a_key|key_format]] in one of the Each subdirectory has the [[name_of_a_key|key_format]] in one of the
[[key-value_backends|backends]]. The file inside also has the name of the key. [[key-value_backends|backends]]. The file inside also has the name of the key.
This two-level structure is used because it allows the write bit to be removed This two-level structure is used because it allows the write bit to be removed
from the subdirectories as well as from the files. That prevents accidentially from the subdirectories as well as from the files. That prevents accidentally
deleting or changing the file contents. See [[lockdown]] for details. deleting or changing the file contents. See [[lockdown]] for details.
In [[direct_mode]], file contents are not stored in here, and instead In [[direct_mode]], file contents are not stored in here, and instead
@ -158,7 +158,7 @@ File format is identical to preferred-content.log.
## `group-preferred-content.log` ## `group-preferred-content.log`
Contains standard preferred content settings for groups. (Overriding or Contains standard preferred content settings for groups. (Overriding or
supplimenting the ones built into git-annex.) supplementing the ones built into git-annex.)
The file format is one line per group, staring with a timestamp, then a The file format is one line per group, staring with a timestamp, then a
space, then the group name followed by a space and then the preferred space, then the group name followed by a space and then the preferred
@ -205,7 +205,7 @@ values.
Lines are timestamped, and record when values are added (`field +value`), Lines are timestamped, and record when values are added (`field +value`),
but also when values are removed (`field -value`). Removed values but also when values are removed (`field -value`). Removed values
are retained in the log so that when merging an old line that sets a value are retained in the log so that when merging an old line that sets a value
that was later unset, the value is not accidentially added back. that was later unset, the value is not accidentally added back.
For example: For example:
@ -214,8 +214,8 @@ For example:
The value can be completely arbitrary data, although it's typically The value can be completely arbitrary data, although it's typically
reasonably short. If the value contains any whitespace reasonably short. If the value contains any whitespace
(including \r or \r), it will be base64 encoded. Base64 encoded values (including \r or \n), it will be base64 encoded. Base64 encoded values
are indicated by prefixing them with "!" are indicated by prefixing them with "!".
## `aaa/bbb/*.log.cnk` ## `aaa/bbb/*.log.cnk`
@ -237,7 +237,7 @@ Used to record scheduled events, such as periodic fscks.
The file format is simply one line per repository, with the uuid followed by a The file format is simply one line per repository, with the uuid followed by a
space and then its schedule, followed by a timestamp. space and then its schedule, followed by a timestamp.
There can be multiple events in the schedule, separated by "; " There can be multiple events in the schedule, separated by "; ".
The format of the scheduled events is the same described in The format of the scheduled events is the same described in
the SCHEDULED JOBS section of the man page. the SCHEDULED JOBS section of the man page.