On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Sun, Nov 28, 2010 at 16:48:30 +0100:
>> The real problem is that we want to be able to answer these questions
>> very fast, and some design aspects work against this. For instance,
>> FSFS by design does not allow modifying old revisions. So where do
>> we store the copy-to information for a given path_at_N?
>
> copy-to information is immutable (never changes once created), so we
> could add another hierarchy (parallel to revs/ and revprops/) in which
> to store that information. Any 'cp foo_at_N bar' operation would need to
> create/append a file in that hierarchy.
>
> Open question: how to organize $new_hierarchy/16/16384/** to make it
> efficiently appendable and queryable (and for what queries? "Iterate
> all copied-to places" is one).
>
> Makes sense?
I'm not sure. But there is another alternative: while we wait for
FS-NG (or another solution like you propose), one could implement the
"slow" algorithm within the current design. Just automating what a
user (or script) currently does when looking for this information,
i.e. a binary search.
Of course it would be slow, but it would certainly already provide
value. At the very least, it saves users a lot of time searching FAQ's
and list archives, wondering why this doesn't work, understanding the
design limitations, and then finally implementing their own script or
doing a one-time manual search.
Then, when FS-NG arrives, or someone comes up with a way to index this
information, it can be "optimized".
I don't know if there would be fundamental problems with that, apart
from the fact that someone still needs to implement it of course ...
Cheers,
--
Johan
Received on 2010-11-28 21:21:28 CET