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

Re: Format bump for 1.8?

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 11 Jul 2012 16:51:41 +0200

On Wed, Jul 11, 2012 at 4:45 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
>> Sent: woensdag 11 juli 2012 15:51
>> To: Greg Stein
>> Cc: dev_at_subversion.apache.org
>> Subject: Re: Format bump for 1.8?
>>
>> I'd like to continue this discussion a bit more, as there are still
>> some things lingering here ...
>
>> Also, as I said, an auto-upgrade needs at least:
>> - To be reversible (need downgrade feature or script).
>> - To be fast, and O(1) (consider 1,000,000 nodes WCs).
>
> Note that there was a repeated expensive table scan in the upgrade process
> for 1.7, which was fixed in r1342984 and merged back to 1.7.x in r1349817,
> but still not released.
>
> O(1) is impossible for most database schema changes except adding empty
> tables, but O(n) should be doable. (Creating an index on some data is more
> expensive than O(n), and simply changing every record O(n))
> The 1.7 upgrade was O(n^2), until r1342984.
>
> The format bump required for conflict skels is currently still O(n), except
> for adding an index on the file move a fields that are always NULL in 1.7.

No problem. Note that I specifically said "an *auto-upgrade* needs
...". And 1.7 is manual-upgrading, so it's much less of an issue (user
knows what's going on, he asked for an upgrade after all).

Maybe O(1) is a bit overkill (in <= 1.6 the auto-upgrades were at
least O(number of directories)). But anyway, since the consensus in
this thread is leaning towards "manual upgrade", it's probably a moot
discussion about what I expect from auto-upgrade ...

-- 
Johan
Received on 2012-07-11 16:52:36 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.