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

Re: proposal: 1.0.1 release date Tuesday, March 9th

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-03-08 07:42:00 CET

Karl Fogel <kfogel@localhost.localdomain> writes:

> Second, I don't think it's a good idea to ship a brand-new
> apr/apr-util in what is supposed to be a safe, conservative
> maintenance release of Subversion. Sure, probably Apache 2.0.49 will
> be stable and wonderful. But by the time we're ready for SVN 1.0.2,
> we won't even have to say "probably" anymore -- we'll *know*, because
> 2.0.49 will have been out there for a while :-).

You stole the words right out of my ... fingers.

> Third, we can solve the BDB detection problem by shipping 1.0.1 with
> the patch applied to apr-util's configury (I mean the one from
> http://subversion.tigris.org/project_faq.html#linux-bdb42-build).
> Yes, this means that the apr-util in subversion-1.0.1.tar.gz will be
> *slightly* different from the officially released apr-util, but this
> is a normal technique for dealing with interim bugs in dependencies.
> As long as the patching doesn't get out of hand, it's fine.

I've thought about this in the past, and I don't like it. Well, I
don't like one side-effect of it. Folks using the tarball just to
bootstrap a HEAD checkout (I have no idea how common this is, but bear
with it) of Subversion's code will run into a weird problem where
their tarball build with work with db4.2, and then their bootstrapped
working copy (which is supposed to be *newer* than the tarball, after
all) will lose that 4.2 link ability.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 8 07:43:04 2004

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.