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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-09-13 21:02:43 CEST