C. Michael Pilato wrote on Wed, Sep 21, 2011 at 10:30:42 -0400:
> On 09/20/2011 09:38 AM, Daniel Shahaf wrote:
> > To implement 'svnadmin upgrade' for fs-successor-ids, it seems we want
> > code to do the following:
> >
> > def construct_successors_in_existing_fs(fs):
> > def handle_range(range):
> > for revision in range:
> > for node-rev-id in fs->revisions[revision]:
> > Add to 'successors' table: key=fs->nodes[node-rev-id].pred-id value=node-rev-id
> >
> > For range in 0..999, 1000..1999, ..., N*1000..youngest:
> > in a txn, handle_range(range)
> >
> > in a txn, handle_range( (old youngest)+1..[txn's value of "youngest"] )
> >
> > Now, handle_range() needs to work with two tables at once --- reading
> > from NODES and writing to SUCCESSORS --- and I haven't found any
> > precedent in subversion/libsvn_fs_base/bdb/*.c for code that reads two
> > tables at once. (locks-table.c reads from bfd->lock_tokens, but it
> > doesn't read from bfd->locks in that function; and everything else only
> > reads from the table the file is named after.)
> >
> > So, I'm asking what's the proper layout for this code: do I make
> > a function in bdb/successors-table.c that reads from NODES and writes to
> > SUCCESSORS? Or do I have a higher-level function (in, say, node-rev.c)
> > that runs within a txn, reading NODES and calling SUCCESSORS?
>
> I would probably go with a higher-level function that calls the appropriate
> database-specific functions in the bdb/* layer.
>
> But before we press on here, I'd like to understanding your bigger-picture
> view.
The branch operates on the assumption that an efficiently-queryable
successors store should be managed by the FS. In this thread I'm
further assuming that creating successors would be expensive and
therefore 'svnadmin upgrade' should create a 'miscellaneous' table
record and bump the format number.
There is a concurrent thread by Stefan2 that challenges both of these
assumptions. I don't know that we have consensus yet whether the design
in that thread or the design currently on the branch are better. (And,
yes, figuring that is the second thing at the top of my list, next to
figuring out how to implement 'upgrade' on the branch.)
> Why are you choosing to this by-revision in fs_base rather than using
> a more lower-level, largely-Subversion-ignorant approach? Is it
> specifically so you can have an interruptible/restartable process? Is it so
> you can hook into some pre-existing per-revision subsystem (notification,
> perhaps)?
>
I was simply trying to outline an algorithm for populating the
successors store from scratch in a live FS. (And yes, both
restartability and notification are nice properties to have.)
It's not clear to me exactly what the alternatives your question refers
to are. Could you elaborate on them, please?
(I'm not particularly familiar with BDB or with libsvn_fs_base, so it's
conceivable that I overlooked some potential approaches.)
> (As to you follow-up mail, yes, the `miscellaneous' table is the best place
> to store a progress pointer.)
>
*nod*.
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Thanks for the feedback,
Daniel
Received on 2011-09-21 17:04:15 CEST