C. Michael Pilato wrote on Tue, Sep 13, 2011 at 15:02:06 -0400: > On 09/13/2011 02:42 PM, Daniel Shahaf wrote: > > C. Michael Pilato wrote on Tue, Sep 13, 2011 at 14:25:14 -0400: > >> On 09/13/2011 02:04 PM, Daniel Shahaf wrote: > >>> Does anyone have ideas for how to implement 'upgrade' for the BDB backend? > >> > >> The BDB situation should be about the easiest scenario possible. I mean, > >> it's a database, for crying out loud. My not-completely-thought-out > >> approach would be: run a cursor over the whole `nodes' table, reading > >> node-revision-ids (the keys of that table) and precessor-ids (parsed from > >> the values of that table), and store the reverse mapping in the > >> `successors' > >> table. > > > > In other words, run over the noderev-to-predecessor mapping and reverse > > it. No argument about /that/. But do we make 'svnadmin upgrade' do > > that, or do we introduce a bit that says "Set this bit to '1' after > > you've built the successors mapping"? > > I can't answer this right now, because I think it's best answered in the > scope of all the other changes to the backend for this release, and in > comparison with other approaches we're willing to entertain. > > For example, if this is the only change we make to the BDB backend, then it > would seem silly to *not* have 'svnadmin upgrade' do the work. If, however, > there are other changes that are less intrusive, we might wish to let > 'svnadmin upgrade' pull off a quicker upgrade while still leaving the > successor-id feature disabled, and then use some other mechanism to populate > the mapping and enable the feature.
What about people who want to upgrade their repository from 1.7's format to 1.9's format (perhaps they used a 1.8 server with --pre-1.8-compatible), and use any new BDB features we might add in 1.9? [ In any case, I'll start writing the upgrade code. We can later decide where in the UI to hook it up to. ]
