thoughts
This commit is contained in:
parent
946ea4b961
commit
e5cb4f9dee
2 changed files with 39 additions and 0 deletions
|
@ -0,0 +1,17 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 2"""
|
||||
date="2019-09-27T15:53:25Z"
|
||||
content="""
|
||||
Yet another problem with the sameas idea is that old git-annex won't know
|
||||
what the sameas= value means, and will ignore it. So they'd proceed to use
|
||||
the wrong uuid for the special remote. That could result in a big mess.
|
||||
|
||||
Also, two remotes using the same underlying data need to be encrypted the
|
||||
same way. Including using the same cipher= value, which is not a value that
|
||||
the user provides. Basically, all the encryption parameters need to be
|
||||
shared between two such remotes.
|
||||
|
||||
Also the chunksize parameter needs to be shared, or at least be
|
||||
set on both if not to the same value.
|
||||
"""]]
|
|
@ -0,0 +1,22 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 3"""
|
||||
date="2019-09-27T15:59:28Z"
|
||||
content="""
|
||||
Alternate idea:
|
||||
|
||||
git annex initremote foo type=directory directory=/foo encryption=shared
|
||||
git annex initremote --sameas=foo foo-rsync type=rsync rsyncurl=server:/foo
|
||||
|
||||
The second command would inherit the encryption etc fields from the foo remote,
|
||||
and set up the foo-rsync remote with the same uuid as it.
|
||||
And it would add additional fields to the remote.log:
|
||||
|
||||
-uuid name=foo type=directory encryption=shared cipher=...
|
||||
+uuid name=foo type=directory encryption=shared cipher=... alt.foo-rsync.type=rsync alt.foo-rsync.rsyncurl=server:/foo
|
||||
|
||||
When enableremote foo-rsync is later run and fails to find a name=foo-rsync,
|
||||
it can look for a remote with the "alt.foo-rsync.type" field, and generate a
|
||||
RemoteConfig with type=rsync rsyncurl=server:/foo encryption=shared cipher=...
|
||||
From there the enableremote would proceed as usual.
|
||||
"""]]
|
Loading…
Reference in a new issue