On Sun, Nov 28, 2010 at 6:35 PM, Daniel Shahaf <d...@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 p...@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 f...@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
