43 lines
1.7 KiB
Text
43 lines
1.7 KiB
Text
[[!comment format=mdwn
|
|
username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
|
|
nickname="Richard"
|
|
subject="comment 1"
|
|
date="2014-01-01T21:32:56Z"
|
|
content="""
|
|
Such a class of repositories would be very useful, indeed.
|
|
|
|
A good name would probably be, in descending order:
|
|
|
|
* ephemeral
|
|
* volatile
|
|
* transient
|
|
* fleeting
|
|
|
|
It would be somewhere in between 'untrusted' and 'dead'.
|
|
|
|
I can see two approaches working nicely, here:
|
|
|
|
1. Local location log
|
|
2. Local location log in another branch / directory
|
|
3. No location log
|
|
|
|
In the first case, location data would be added to the local location log, but any `git annex sync` or similar would parse the location log and strip out all mentions of the UUID in question.
|
|
This would be somewhat slower when synching, but would ensure that all operations which rely on local logs operate normally.
|
|
|
|
In the second case, location data would be kept in a different location.
|
|
This would have the benefit of a clean separation and quicker merges, but induces overhead for lookups.
|
|
On the other hand, if those lookups are wrapped cleanly, only those functions would need to know about the different locations.
|
|
|
|
In the last case, no local logs would be kept.
|
|
|
|
|
|
All in all, I think I would prefer the first option.
|
|
|
|
The one thing that's hard/impossible by design is for other remotes to strip out the data.
|
|
As the repository would not be known to other remotes, they would simply continue the carry the data.
|
|
This can be worked around by setting the repository to "dead".
|
|
Ephemeral repositories would not correct "dead" info about themselves; they _would_ start behaving normally once set to trusted, semit-trusted, or untrusted, though.
|
|
|
|
|
|
Richard
|
|
"""]]
|