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

add remote state logs

Browse source 
This allows a remote to store a piece of arbitrary state associated with a
key. This is needed to support Tahoe, where the file-cap is calculated from
the data stored in it, and used to retrieve a key later. Glacier also would
be much improved by using this.

GETSTATE and SETSTATE are added to the external special remote protocol.

Note that the state is left as-is even when a key is removed from a remote.
It's up to the remote to decide when it wants to clear the state.

The remote state log, $KEY.log.rmt, is a UUID-based log. However,
rather than using the old UUID-based log format, I created a new variant
of that format. The new varient is more space efficient (since it lacks the
"timestamp=" hack, and easier to parse (and the parser doesn't mess with
whitespace in the value), and avoids compatability cruft in the old one.

This seemed worth cleaning up for these new files, since there could be a
lot of them, while before UUID-based logs were only used for a few log
files at the top of the git-annex branch. The transition code has also
been updated to handle these new UUID-based logs.

This commit was sponsored by Daniel Hofer.
This commit is contained in:
Joey Hess 2014-01-03 16:35:57 -04:00
parent 3560fb411d
commit 3e68c1c2fd
9 changed files with 119 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

11
doc/design/external_special_remote_protocol.mdwn
View file

@ -222,6 +222,17 @@ in control.
Gets the current preferred content setting of the repository.
(git-annex replies with VALUE followed by the preferred content
expression.)
* `SETSTATE Key Value`
Can be used to store some form of state for a Key. The state stored
can be anything this remote needs to store, in any format.
It is stored in the git-annex branch. Note that this means that if
multiple repositories are using the same special remote, and store
different state, whichever one stored the state last will win. Also,
it's best to avoid storing much state, since this will bloat the
git-annex branch. Most remotes will not need to store any state.
* `GETSTATE Key`
Gets any state that has been stored for the key.
(git-annex replies with VALUE followed by the state.)
## general messages