> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: donderdag 22 juli 2010 0:30
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: svn commit: r966381 -
> /subversion/trunk/subversion/libsvn_wc/wc_db.c
>
> On Wed, Jul 21, 2010 at 16:15, Bert Huijben <bert_at_qqmail.nl> wrote:
> >...
> > This last commit and the few previous (r966279, r966300 (fixes
> missing #endif) and more important r966313), fixed the last few
> remaining issues on upgrading to in-db properties.
> >
> > We still have the issue #2530 error, that makes the upgrade from
> 1.4.0 with specific replacement schedules fail (upgrade_tests.py 8).
> This test was specifically added to trigger this issue, so I think we
> can just mark it XFail until we know how to handle this.
> >
> >
> >
> > I think we are ready to switch to in-db properties now. If nobody
> objects, I would like to switch to in-db properties tomorrow, by
> switching to WC-format 18.
> >
> > @gstein: Can you please confirm that you read this mail and if
> possible review these revisions?
>
> Initial question: I don't see any *specific* tests for properties. I
> wrote a script over the weekend:
> tests/libsvn_wc/create_wc_for_upgrade.sh. The intent was to use that
> with 1.0.x, 1.4.0, and 1.4.6 to create three working copies with "all"
> variants of properties. Then .tar those up (put into
> upgrade_tests_data and info ...data/README) and write upgrade tests.
>
> I think that still needs to happen before we switch.
As far as I can tell all the interesting cases are handled by the set of 3x
working copies I added earlier (only two variants with local modifications
out of the 8 options are missing). But it might be useful to add some value
validation to that test, but manual validation confirmed that the result was
identical. (Except for the cases that we can't handle without the 4th tree.
But we have that same issue with the pristine store)
> I have some working copies that are kind of confused right now, w.r.t.
> properties. So there has been some property handling that is not quite
> right in the past, and left my working copies a bit inconsistent. I'd
> hate to have a broken upgrade step and leave our users in that state.
Using double property handling for the last 8 months, might have introduced
some issues... That is one of the reasons I want to switch sooner rather
than later.
(The update and merge code can really use a cleanup here)
Bert
>
> Cheers,
> -g
Received on 2010-07-22 01:36:47 CEST