Erik Huelsmann wrote:
> Hi Steve,
> 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.
Yes, I concede your point. My personal use of a subversion repository
is not the case you're testing for. My "repository" is really just a
toy, a learning experience. If I was supporting a large development
team with a large investment in the code, I'm sure I would have felt
differently. I won't complain about the fact of unit tests again.
You've convinced me on that point.
> 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.
This is what I missed. Maybe I was made a little crazy from watching
two hours of build go by (on more than one occasion) only to fail, not
because there was anything wrong with my build of subversion but because
apache wouldn't start! Had this been caught earlier in the process, I
wouldn't have complained. Perhaps reorganzing the test suite to run the
precondition tests before the unit tests would be one way to minimize this.
>
>>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.
There is resistence from some quarters to switching to subversion and I
think you're somewhat in denial if you that think incidents like this
have nothing to do with it. But don't shoot me, okay. I'm a messenger.
I'm the guy persisting with subversion in spite of this. I'm one who
voted to go forward in spite of misgivings.
> We have binaries for most platforms (including RH9). That should serve most
> people not wanting/able to build themselves.
Unless they want to use subeclipse with javaHL. That is what drove me
down this path.
>
>
>>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?
>
I've heard it from more than one helpful soul during this ordeal that I
should upgrade to RHEL, Fedora, CentOS, whatever. There's a lot of
misinformation out there.
>
>>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.
>
>
This is good. I think you should also list version numbers and stick to
them. That way users would have more confidence that they won't have to
replace their OS just to upgrade subversion. Today I've seen RedHat 9.0
described as EOL. It's less than 2 years old! Granted, I primarily
blame RedHat itself for this state of affairs. But still, what features
above what the current version of these packages support does Subversion
need? Being conservative in what features you'll be using from
dependency packages will increase subversion's stability and require
less of a bleeding-edge mentality.
>>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?
But these ARE from Fedora, not RH9. My Apache "main page" (obtained
from this site) now claims it's running on Fedora. And the
documentation wasn't quite right. It recommended --nodeps installs, one
of which knocked out my apache server. Eventually, though, I did get it
working but not the way the site said to. But then I had to get into
source building in order to get javaHL for subeclipse.
>
>>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.
Agreed. That's what I'm asking for.
>
>
>>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.
You haven't answered my question. If you can't say, we'll work with any
apache back to v. x.x.x and plan to keep it that way, you do not enhance
your reputation for stability.
> Have a look at the testimonials page to see who's using svn:
> http://subversion.tigris.org/propaganda.html
I'm sure they are. But simpler installs are a big part of "ready for
prime time." At this point in time, I would not dream of recommending
that my employer adopt subversion. It demands a higher caliber of
developer than those I've seen there. Without a GUI, many of them are
lost. I hope to be able to recommend subversion there once there is a
stable subeclipse. You guys are making progress. Keep it up and you'll
get there.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 12 03:43:18 2005