On Sat, Sep 20, 2008 at 1:41 AM, Albert Cahalan <[EMAIL PROTECTED]> wrote: > The case of b/a being distinct from a/b is necessary. You may call > it a necessary evil, but in any case is is necessary.
Surprisingly, it's not: http://wiki.laptop.org/go/Experiments_with_unordered_paths I still think it's worth supporting as an edge case, but from my actual experiments, it seems that path ordering is almost never actually necessary (!). > For the journal to be truly usable, it needs to support pretty much > all that we ask of a filesystem. You'll know you're doing OK when > you can build joyride out of the journal. (git works, gcc works, etc.) This is a good test case. I'll confirm it, but I believe that this should actually work with unordered paths. The trickiness comes wrt to security in a multiuser system; Michael has been thinking hard about that. (I prefer just to punt it for the moment.) > Give priority to tags (and anti-tags) which split the set of > files most evenly. This greatly reduces search time; it is > equivalent to balancing a binary tree. It turns out that only about 3 tags are needed to find any directory among the 900,000 files in my home directory (I'm working on getting better statistics, sorry). So the opposite criterion might be more important: give priority to tags which 'most narrow' the search -- that is, they match the *fewest* things! Once you've entered two search terms, the exact thing you are looking for ought to be in that list; you don't want to be distracted by terms held in common by lots of files which don't appreciably narrow your search. I hope to implement experiments (as described in the wiki page cited above) to start getting real life experience with these tradeoffs. --scott -- ( http://cscott.net/ ) _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar