Use case is wanting to set up a server with a git-annex repository which is
a mirror of an original repository.
All git refs are mirrored, using eg git push --mirror.
So, the git-annex branch cannot diverge. Or if it does, any divergence will get overwritten the next time the refs mirror is updated.
The mirror can contain some, but not necessarily all annex objects as the original repository. If a client requents an annex object that is not present in the mirror, it transparently proxies the request to the original repository. It may also, optionally, cache the object in the mirror (if the mirror's preferred content configuration wants it).
A client dropping an object from the mirror would have it proxy the drop to the original repository, and only delete its cache if that drop succeeded.
It seems at first that the mirror repository would need to have the same uuid as the original repository. Since the client sees the original git-annex branch, it only knows about the uuid in that branch for location tracking.
But using the same uuid would bring in a ton of special cases and problems.
Just a few of them are:
* git-annex get in the mirror repository would fail to get files from the
original repository, because the local repo uuid is filtered out of the
remote list in keyPossibilities'.
* The mirror couldn't have its own preferred content configuration.
The mirror repository could have the same uuid as the original set in annex.uuid, so the client thinks it has the same uuid, but actually have a different uuid that is configured elsewhere. Make git-annex use that other uuid, and with annex.private set, it will never reach the git-annex branch.
In the P2P protocol, AUTH-SUCCESS includes the server's uuid.
That would need to be the original repository's uuid, to avoid a
client thinking it's talking to the wrong repository.
Concretely, a mirror could be configured like this:
git remote add original http://example.com/foo
git pull --prune mirror
git config annex.mirroring original
git config annex.private true
git-annex init
# that sets annex.uuid to the discovered uuid of original
# and it sets annex.mirror-uuid to the repo's true uuid
git-annex mirror --from=original # optional
I had to think about in which ways this maps back onto the approach I had in mind. I think the following statement is what I keep stumbling upon:
This implies a much more symmetric relationship of the source and the mirror than what I had in mind. My concept of a mirror was that
I like the transparent key retrieval through the mirror from the source. I like the decision making on whether to cache a key via preferred content.
I do not immediately see the advantage or necessity to bind the fate of a mirrored-key to its counterpart at the source. I think this is a consequence of
which further implies
In my sketch of an approach, I saw the mirror repo as an ordinary node in the git-annex network. It would have its own UUID, and therefore would require (ordinary) coordinated merges of the git-annex branch. But this would enable fully independent decision making re key availability/dropping at the "mirror".
Right, the reason I think the mirror would need to proxy the drop to the original repository is that otherwise a client who dropped a file from the mirror would update the location log to say it's no longer in the original repository when it still is.
But the mirror doesn't need to be able to write to the original repository. It would be ok for a drop from it to fail if it is unable to proxy the drop on to the original repository. It could choose to always make drops from it fail. Or it could choose to drop its local cache on a drop, and then fail the drop, leaving the content in the original repository. Any of these options would leave the git-annex branch in a consistent state.
(I didn't cover what the mirror would do if a client tried to store an object on it, but similar reasoning applies.)
That's fine as long as you don't mind having the git-annex ref not be identical to the one in the original repository.