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. ]
Received on 2011-09-13 21:13:16 CEST