-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a problem which lead, through a discussion with holsta on IRC, to a
desire to see the instructions changed.
When 0.11 was announced, I decided to upgrade my server. I don't do upgrades
lightly, because they are /always/ painful. So I did an svn up and did the
make clean, autogen, config.nice sequence. It didn't get very far -- no
suprise, because of some API conflict between the recent SVN and a slightly
less recent APR. After struggling to get Apache2 updated and reinstalled, I
gave up, deleted my entire apache source tree and installation (after backing
up my configs) and rebuilt Apache from scratch. After SVN failed to
configure nicely, I deleted THAT entire source tree and pulled it fresh as
well. It still won't configure. The problem is that SVN's configure is
looking for mod_dav.h in the apache build directory rather than the apache
install directory, where it always looked before. On top of that, it isn't
looking in the /correct/ directory; it is inserting a 'src' in the path where
there shouldn't be one. EG:
/usr/local/src/http-2.0/src/modules/dav/main/mod_dav.h
rather than:
/usr/local/src/http-2.0/modules/dav/main/mod_dav.h
which is where it really is.
Whatever. This I think I can hack around. The real problem is that the
instructions, and the releases, urge the users strongly to only use the
distribution tarballs for bootstrapping. They also tell the user to build
from the repository HEAD (implicitly, by giving the checkout URL of
http://svn.collab.net/repos/svn/trunk). I believe this is wrong, since HEAD
is a development branch, and is almost guaranteed to give people (novices,
semi-novices) trouble.
My belief is that either:
1) the tarballs are promoted as being what non-developers should use, and the
emphasis on upgrading from the repository be entirely removed from the
instructions, or
2) we start maintaining a http://svn.collab.net/repos/svn/tags/current_release
copy of whatever was used to build the tarball, or whichever release is
considered most "stable".
(2) would be the better solution, IMO, because people like myself who tend to
upgrade from the repository would be able to get in a "stable" branch and
stay there. I don't have a problem with testing; I'm happy to test. But
not being able to configure, much less compile, a recent version makes a
repository unaccessible, is more than a mere annoyance.
- --
|.. "The Earth is far too fragile a basket for humanity to keep all of
<|> its eggs in."
/|\ -- Robert Anson Heinlein
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8uGAMP0KxygnleI8RAr6tAKDK/F7EfkCAj7La44WmjAMBJ0t1XQCfUQEA
y+/AohhINR3xSee5dTjljn4=
=yOWm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 13 18:44:16 2002