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

Re: USE_DB_PROPS define

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Fri, 4 Jun 2010 15:36:52 -0500

On Thu, Jun 3, 2010 at 4:06 PM, Greg Stein <gstein_at_gmail.com> wrote:

> On Wed, May 26, 2010 at 15:44, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
> > To anybody concerned:
> > We currently use the USE_DB_PROPS define to filter out the experimental
> use
> > of exclusive in-db-properties. Since that will be implemented in format
> 17,
> > which is imminent as soon as Greg is home from holiday, I'd like to
> change
> > the defines from
> >
> > #ifndef USE_DB_PROPS
> >
> > to
> >
> > #if (SVN_WC__VERSION < SVN_WC__PROPS_IN_DB)
> >
> > The rationale is that they really just mean the same thing. I'll shortly
> be
>
> ... no, they don't.
>
> One allows me to test in-db properties by flipping a symbol. The other
> requires a version bump to test them, which implies a lot of other
> things. Would failures be caused by in-db properties, or due to some
> other interaction caused by missing/buggy upgrade logic? Who said that
> I wanted to test the upgrade logic?
>
> I don't understand the rationale for this.
>

My rationale was that I did want to test the upgrade logic through format 17
to what could eventually be format 18. My understanding before you left for
MX was that format 17 was imminent (indeed, I thought it was ready, you just
didn't want to turn it on for fear of stuff blowing up in your absence). It
appears that that wasn't correct.

We could revert the change, do some hacky #define madness to allow
USE_DB_PROPS to have the current meaning if not previously defined, or just
leave it as is fix the upgrade code in the interests of moving forward. I
won't have time to hack on the text base upgrade code until Berlin, so I'm
pretty indifferent in the interim.

-Hyrum
Received on 2010-06-04 22:37:30 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.