Hi Steve,
> I had hoped my "Victory" thread would have sparked more discussion on
> the subject of whether the suite of tests was an appropiate default
> inclusion in source RPMs, and the difficulty involved in building
> Subversion. I'm a new member of your community - so for all I know
> you've discussed this to death already.
Welcome. As you probably have found by now, we're trying to work by very
high standards. In order to keep standards as high as they have been until
now, we want to understand exactly what it is that drives enhancement
requests, bugreports etc. It looks like we don't care and give you a hard
time, while actually you should start worrying when no reactions come to
your mails.
> However, the discussion seems to have settled on whether I should or
> should not have attempted to build the source RPM as root (my position
> is now that I should not have, but that I had been building source RPMs
> that way for years - and that a week's worth of hair-pulling was too
> great a penalty to pay for this oversight - that the RUNNING of apache
> within the build process makes Subversion a rather unusual beast and
> that some method for warning the builder might be appropriate).
The subversion team, including its packagers take the utmost care to provide
you with software that does what it is advertised to do. In the case of
Subversion this might be more appropriate than a gettext or bash build: some
people will store their complete 20 years software development history in
it. Any failure will be fatal then.
In this strategy the unit tests are used to determine whether consecutive
revisions still provide the functionality we set out to deliver. However
build processes are not guaranteed to be without problems: we've seen builds
linked against two different bdb versions at the same time, builds which
were linked against one version but running against another, etc. These
problems can be detected by the unit tests too. One should just not assume
that because the build completed successfully that you were provided with a
correctly working toolset.
> More interesting to me are these questions:
> Is it appropriate to put what are essentially developer unit tests into
> a source package such that they are run by default? Or should the user
> of such a package be entitled to assume that it would not have been
> released if all such tests had not already passed (assuming a properly
> set up environment - which can be tested within the source rpm). At
> most, I would think, these tests are relevant to the packager of such
> RPMs.
Sure. If the unit tests did not pass on our systems there would not have
been a release, but if it works on my system, that does not guarantee it
works on yours.
> I think we may have a confusion here between environment-checking tests
> and developer unit tests, and that we are trying to make one set of
> tests developed for the second purpose also serve the first.
Not really. The unit tests provide you with a good estimate of the health of
your build and are run post-build. Configure tests (which we have too) serve
to identify the environment pre-build.
> And this
> DOES have consequences - it drives users away from using wanting to use
> Subversion.
Well, I don't see it that way: I think it is a testimonial to the care the
team takes to provide you with a toolset which wont corrupt your work.
We have binaries for most platforms (including RH9). That should serve most
people not wanting/able to build themselves.
> Or it leads to loose talk such as "RH 9.0 is not supported
> by subversion".
Even if we provide binaries for exactly that platform?
> Speaking of which, another related point is this: Has the Subversion
> development team targeted a minimum set of system requirements?
No. There are so many different uses for Subversion that there's hardly a
good estimate. There were people building it into embedded systems where
both space and computing power are limited. Others version the company
assets and provide svn with a quad opteron and 1TB disc...
> i.e. "Subversion supports the following platforms Windows 2K, XP,
> solaris xxx, RedHat Linux > x.x, Debian > x.x. Also required are
> Apache > x.x, etc."
We don't enumerate all Linux distros, but in the README there is a list of
all prerequisites:
Apache
APR
Neon
Berkely DB
libxml / expat
libz
gettext
etc.
> It still seems a little strange to me that I had
> to upgrade my RH9 system with various patches developed for Fedora,
> etc.
So what was wrong with the binaries you can download from the summersoft
site?
> Finalizing a set of minimum requirements for the foreseeable
> future would reassure me that I will not have to go through such
> trouble with the next subversion release.
Having a list of minimum requirements by itself does not assure you of that.
Only the intention to keep them stable will help you there.
> In the Jakarta-commons-net project where I am a committer we only
> recently dropped support for Java JDK 1.1. (And we only bumped the
> minimum level to 1.2). We very deliberately forced ourselves to write
> code that was now suboptimal to preserve the contract we had with our
> users. Does subversion have such a contract? I think if it did, it
> would put to rest some of this "ready for prime time" controversy.
Do we have a 'ready for prime time' controversy? People have been versioning
multi-GB datasets from years before svn went 1.0 without many problems. Have
a look at the testimonials page to see who's using svn:
http://subversion.tigris.org/propaganda.html
bye,
Erik.
--
DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 11 23:35:51 2005