The sdb should be created as latest. Anything short of that is a bug. The ng
upgrade func assumes latest; even has a comment about that.
(Terse; phone)
On Nov 16, 2009 5:13 PM, "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu>
wrote:
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=2418693
Received on 2009-11-16 23:23:15 CET