[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: upgrade test failures

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 20 Apr 2009 09:21:32 -0500

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".

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1825693
Received on 2009-04-20 16:21:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.