Johan Corveleyn wrote on Sun, Nov 28, 2010 at 21:20:28 +0100: > 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.
Are you advocating to implement it in the core (as an svn_fs_* API) or as a third-party script? The latter is certainly fine, but regarding the former I don't see the point of adding an API that cannot be implemented efficiently at this time. > 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
