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.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.
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
Received on 2010-11-29 03:53:44 CET