From 5e0dad09721637c2d9bf195f03b020275c329711 Mon Sep 17 00:00:00 2001 From: Richard Hartmann Date: Wed, 1 Jan 2014 22:48:32 +0100 Subject: [PATCH] Update comment --- ..._ccc743554cf9270e1db5275273b28265._comment | 37 ++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment b/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment index 76fe450bcb..bab26dc10d 100644 --- a/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment +++ b/doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment @@ -4,5 +4,40 @@ 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 """]]