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

Re: Final WC format bump before branch

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Tue, 5 Jul 2011 16:47:30 -0500

On Tue, Jul 5, 2011 at 3:28 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Thu, Jun 30, 2011 at 11:01, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>> We're almost ready to branch 1.7.x, and there remains the business of
>> cleaning up the database schema from columns introduced in the 1.7
>> development cycle.  This has historically be labelled 'format 99', and
>> is found at the bottom of wc-metadata.sql.
>>
>> It feels that the current schema is stable, so I'd like to propose
>> that we make format 99 format 30, and release with the wc format as
>> format 30.  Users running development builds will have an automatic
>> upgrade (as with recent wc format bumps).
>>
>> Concerns?
>
> Yes. Unless we NEED a format bump, then I don't see a reason to do
> this. Just because we *can* doesn't mean we *should*.
>
> The code is working just fine today. Let's just defer this work to the
> next format bump, whenever that might be, in some future version of
> svn.

Greg, in r879400 you added the following comment to wc-metadata.sql:

/* Format 99 drops all columns not needed due to previous format upgrades.
   Before we release 1.7, these statements will be pulled into a format bump
   and all the tables will be cleaned up. We don't know what that format
   number will be, however, so we're just marking it as 99 for now. */

I'm curious as to what has caused you the change your mind.

Historical context: we had already written a bunch of the upgrade code
to remove columns and such, and then decided to punt all of said table
restructuring into One Final Step, rather than duplicating the steps
for intermediate formats. I agreed to support that plan then, because
I was under the impression that we would have a final format bump now.

The bulk of the proposed work involved removing stale columns and
renaming others. (For various reasons, SQLite allows the addition of
columns to existing tables, but removing columns involves a
dump/reload through an intermediate temporary table.) Dropping extra
columns saves (an arguably trivial amount of) space, but more
importantly cleans up a schema that we're going to have to support for
a long time yet.

It makes sense to do this now, when the only people impacted are devs
running intermediate versions, rather than the Entire World of
installed 1.7.x clients. It's going to happen sometime, let's make it
impact as few people as possible.

-Hyrum
Received on 2011-07-05 23:48:06 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.