Upgrading to wc-ng (was Re: svn commit: r40473 - trunk/subversion/libsvn_wc)

On Nov 12, 2009, at 12:09 AM, Hyrum K. Wright wrote:

> On Nov 11, 2009, at 11:56 PM, Hyrum K. Wright wrote:
>
>> Author: hwright
>> Date: Wed Nov 11 21:56:37 2009
>> New Revision: 40473
>>
>> Log:
>> Add a working copy upgrade migration routine for moving properties from disk
>> to the wc_db.
>>
>> This commit does *not* change the current version number of the working copy,
>> so this code will never be run. In fact, even with the current version number
>> bumped, I still can't get the code to run, for reasons I'll pontificate on
>> at a later date. I'm committing this now to get some review.
>
> Greg,
> Although this code is called from svn_wc__upgrade_sdb(), that function never gets called. We're not making any schema changes in the 15 -> 16 bump, and the sqlite version updater just goes right along with that. By the time we get to the call to svn_wc__upgrade_sdb() inside of create_wcroot(), it turns out that the sqlite format has already been bumped to 16, so we don't even make the call. Is this the intended behavior? If so, how can I get that function called so we can migrate the properties correctly?

Another problematic discovery:
Writing entries requires the sdb be at the latest format
Upgrading to the latest format requires entries in the sdb

It turns out that upgrade is a classic chicken/egg problem. In upgrade_to_wcng(), we currently:
1) Read the entries from the old format file
2) Create an sdb with the underlying database to wc-ng format 12
3) Set the wclock [*]
4) Write the entries [*]
5) Remove entries files, etc.

[*] One of these two (I haven't determine which, though I believe it to be (3)), does an autoupgrade of the database schema to the current format. This autoupgrade supposedly migrates locks and props, though through buggy behavior that isn't happening.

It's possible that we could upgrade the schema so as to write the entries, and then migrate the other data (locks, props, etc) into the fresh sdb after the entries get written. The code isn't currently set up for that, however.

The other option would be to integrate the schema upgrades and data migration bits more tightly:
1) Create sdb at format 12
2) Migrate data (including entries) to sdb at format 12
3) Bump db to format 13
4) Migrate data to sdb at format 13
5) ...

Yet another option would be to go straight to $CURRENT skipping intermediate formats, and combine all the steps into one. The benefit is simplicity and not having to support interm development formats long-term. The negative is that the few people using trunk would need to create new working copies, since their upgrade path wouldn't be supported (but we just had to do that for the ASF move, anyway).

-Hyrum (who wants to get this figured out so he can bump the format to store props in the sdb)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418689
Received on 2009-11-16 23:14:00 CET