Branko Čibej wrote on Mon, Feb 13, 2012 at 17:52:01 +0100:
> On 13.02.2012 17:09, Daniel Shahaf wrote:
> > Thanks for your thoughts. One comment:
> >
> > Branko Čibej wrote on Sun, Feb 12, 2012 at 21:52:16 +0100:
> >> The idea is that we'd always maintain the complete index, i.e., in order
> >> to determine if path_at_15 exists, one only needs to search the index for
> >> (path, rev <= 15, !deleted) -- which is trivial in a properly ordered
> >> index. (Yes, this assumes that we record deletions in the index as well
> >> as insertions.)
> >>
> >> All of this can be done with an append-only index representation. What
> >> you can't do with append-only is represent forward history links, but --
> >> we're not representing them very well right now, are we. :)
> > Within the append-only constraint one can implement forward links if one
> > has, say, a separate file per revision. (So asking "where was foo_at_15
> > copied to" involves a linear scan of $REPOS/db/forward-links/15.)
> >
> > stsp and I even started on such a design on some branch somewhere ---
> > but that branch has been abandoned as the motivation for it was rename
> > tracking, which stsp figured he could solve better without the new FS
> > feature.
>
> A separate file per revision has other problems, too. You'd quickly run
> out of inodes on ext-derived file systems, for example.
>
Yeah, I was in theory mode in the previous mail. On the branch we
didn't ignore those "implementation considerations" and went for 3 files
per shard of 4k revisions.
https://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/BRANCH-README
> -- Brane
Received on 2012-02-13 18:06:09 CET