Hyrum K. Wright wrote:
>
> On Apr 19, 2009, at 12:23 PM, Branko Cibej wrote:
>
>> Greg Stein wrote:
>>> What if you just toss loggy from the upgrade story (for the v12
>>> upgrade, if possible; leaving it there for now for v11 upgrades). Or
>>> if you can't, then keep this in mind for the future.
>>>
>>> How about:
>>>
>>> 1) Port entries and property data into wc.db
>>> 2) Remove 'entries'
>>> 3) Remove all property files
>>>
>>> If an interruption happens at any point, this is detectable by
>>> 'entries' *and* 'wc.db' present in the subdirectory. When that
>>> happens, remove wc.db and start again.
>>>
>>> Oh, hmm. We don't want to have to stat for 'entries' every time we
>>> look in a .svn subdir, let alone stat around looking for un-removed
>>> prop files. Alrighty. There needs to be something in the database that
>>> will give us an indication of "in-process on upgrading; if you're
>>> seeing this, then it was interrupted; go investigate". Something in
>>> the format number? Maybe a temporary table whose presence/absence acts
>>> as a boolean?
>>>
>>
>> I'm gonna put my foot in it and suggest that you create the wc.db as
>> not.wc.db, transfer entries and stuff, close the DB and rename the
>> database file ... nice and atomic.
>
> I like the idea, and could probably do it one better: do all the
> upgrade stuff in an in-memory database, and then transfer that to
> disk. The problem is that we've abstracted away the filename of the
> database behind the wc_db API, so we've essentially no way to say "use
> this filename instead of the standard one".
Why, that's easy to fix, just abstract the temporary DB and its
mogrification to the permanent one, too. :)
/me wonders if "abstraction penalty" applies here
-- Brane
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1847348
Received on 2009-04-21 21:06:54 CEST