note
This commit is contained in:
parent
254b1de6a1
commit
b3a53f7f04
1 changed files with 21 additions and 0 deletions
|
@ -0,0 +1,21 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2017-07-10T18:15:02Z"
|
||||
content="""
|
||||
Using trees like that would not work well in a distributed setting
|
||||
where two repositories could be storing content on the same special remote.
|
||||
|
||||
The per-remote trees could be stored, by eg grafting them into the
|
||||
git-annex branches's tree under the uuid of the special remote.
|
||||
|
||||
But, there could then be merge conflicts, when different trees have been
|
||||
exported to the same special remote concurrently. And there's no way to
|
||||
resolve such a merge: If repo A uploaded F containing K and B uploaded F
|
||||
containing L, we don't know which file the special remote ended up with.
|
||||
If that happened it would have to delete and re-export from scratch.
|
||||
|
||||
I think it's fine for exporting to only be able to be done from one
|
||||
repository. But, if a user tries to do the above, it needs to fail in some
|
||||
reasonable way, not leave a mess.
|
||||
"""]]
|
Loading…
Add table
Reference in a new issue