Re: HEAD problems with Apache, and a request for changing the build instructions

[Bruce Atherton <br...@callenish.com>]

At 07:58 PM 4/13/02 -0700, Sean Russell wrote:
>Is this referred to anywhere else besides in the list archives, or are the
>powers that be unwilling to depend on this software?

I expect eventually it will get committed, though someone can correct me if 
I'm wrong and I'll find some other home for it. The "powers that be" are 
mostly C guys, so they aren't going to be that familiar with Ant. Also, I 
failed to mark the message with a [PATCH] subject line (since these are 
actually new files), so it may have slipped through their scripts for 
catching such things.

As to whether it should be depended on, well, it shouldn't be. It is not a 
part of the standard Subversion build system, just a convenience wrapper 
around it to automate as much as possible the rules of the INSTALL file. If 
you want to have java and ant on your system then you can use it if you 
choose, but those are not requirements for someone using Subversion.

>Anyway, for my part, the initial bootstrap isn't a problem; it's upgrading
>that I always have trouble with, one way or another.  I'm not sure that there
>is an easy way to make upgrades seamless, except some sort of chrootted build
>mechanism.

There is a target for update builds called "upbuild", and as I said you can 
get rid of shared libraries if you want to take the chance of breaking your 
client. However, doing a complete build of absolutely everything from 
scratch, including HTTPD 2.0, took just over an hour on my ancient Pentium 
Pro machine. If you perform the complete builds from scratch only when you 
have problems with an update build, that shouldn't prove too onerous. Or 
you could run a cron job to do a complete build every night and send the 
results to svn-breakage. Then you would always be up to date.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: versions, mismatches, tarballs, etc

[Jens Askengren <je...@linux.nu>]

I would personally like to se a release that compiles against the stock
apache2 so I could get a server up and running. I don't care if the
server/client actually works, but it will allow me to start coding
svn-plugins in paralell with the svn developement. I don't think it is a
terrible problem if the api changes. No one is planning a huge redesign
of the api, are you?

	-Jens



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: versions, mismatches, tarballs, etc

[Karl Fogel <kf...@newton.ch.collab.net>]

Greg Stein <gs...@lyra.org> writes:
> I *never* clean out my libraries, and haven't had any problems. I updated
> the various bits, compile them, and install them. And it all works fine.

Okay.

And this means...? :-)

> In fact, I'm beginning to get a bit annoyed at this whole push towards "the
> tarballs don't do anything except download the head; they are useless
> otherwise." If that is the frickin' case, then we should simply publish
> tarballs of the HEAD and leave it at that. We shouldn't ever bother with
> milestones or snapshot releases or anything.

I'm not sure I understand what the problem is.

The reason we want people to run HEAD is not because it's more or less
stable than any particular tarball, but because it's more useful *for
Subversion development* for people to be running HEAD.  There's no
point in receiving bug reports against tarballs when HEAD develops so
fast that the reports are often obsolete by the time we get them.

(I don't see what any of this has to do with milestones, which -- as
you have often pointed out in the past -- are to help us measure
development progress.  We also choose to release on them, because they
come along fairly regularly, but we don't have to do that.)

> then we should simply publish tarballs of the HEAD

Uh, and that's exactly what we do for most releases.  (But if we
discover a bug in that snapshot that prevents the tarball from being
useful even for bootstrapping, then we do backports and release new
tarball, as happened recently.)

> The fact of the matter is that the downloads *ARE USEFUL*. But people have
> problems matching them up with an Apache server. (the tarballs include APR,
> APRUTIL, Neon, and Expat, so no problems there) The second problem is that
> people are ignoring the included code and using stuff on their system, which
> can easily be out of sync.

I guess I'm missing the point here.

It's not enough to say "The fact of the matter is that the downloads
are useful".   What are they useful *for*?  What is our goal?

I think our goal is to get people running HEAD from a working copy,
until 1.0 or thereabouts.  At some point, we may want to maintain a
latest-release branch separate from the development branch, but now is
not the time.  However, if people are using tarballs on a regular
basis, then supporting a release branch is exactly what we're doing,
even if "supporting" just means receiving bug reports about it.

Our purpose is to shake the bugs out of Subversion.  We can best
accomplish that if people are running the latest code.

> The real answer here is to turn on the versioning in APR(UTIL) and start
> depending upon it. Also to depend more upon the versioning in httpd (see the
> ap_mmn.h file); we can have buildcheck.sh verify the values.

That will help, but it doesn't affect the main (imho) issue, which is
getting our users testing HEAD right now.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

versions, mismatches, tarballs, etc

[Greg Stein <gs...@lyra.org>]

On Sun, Apr 14, 2002 at 02:36:44PM -0700, Sean Russell wrote:
>...
> > There is a target for update builds called "upbuild", and as I said you can
> > get rid of shared libraries if you want to take the chance of breaking your
> > client. However, doing a complete build of absolutely everything from
> 
> Yeah, only you have to break your client to upgrade subversion anyway.  The 
> instructions tell you to remove any existing old libraries.  I have a script

I *never* clean out my libraries, and haven't had any problems. I updated
the various bits, compile them, and install them. And it all works fine.

In fact, I'm beginning to get a bit annoyed at this whole push towards "the
tarballs don't do anything except download the head; they are useless
otherwise." If that is the frickin' case, then we should simply publish
tarballs of the HEAD and leave it at that. We shouldn't ever bother with
milestones or snapshot releases or anything.

The fact of the matter is that the downloads *ARE USEFUL*. But people have
problems matching them up with an Apache server. (the tarballs include APR,
APRUTIL, Neon, and Expat, so no problems there) The second problem is that
people are ignoring the included code and using stuff on their system, which
can easily be out of sync.

The real answer here is to turn on the versioning in APR(UTIL) and start
depending upon it. Also to depend more upon the versioning in httpd (see the
ap_mmn.h file); we can have buildcheck.sh verify the values.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: HEAD problems with Apache, and a request for changing the build instructions

[Sean Russell <se...@germane-software.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun April 14 2002 13:12, you wrote:
> As to whether it should be depended on, well, it shouldn't be. It is not a

I should have been more clear:  by "depend on", I meant "associated with", not 
"reliant on".  What I'm trying to get at is that, if the only reference to 
this software is buried in the list archives, very few people are going to be 
able to benefit from it.

> There is a target for update builds called "upbuild", and as I said you can
> get rid of shared libraries if you want to take the chance of breaking your
> client. However, doing a complete build of absolutely everything from

Yeah, only you have to break your client to upgrade subversion anyway.  The 
instructions tell you to remove any existing old libraries.  I have a script 
that just moves the various libs elsewhere, where they aren't a problem but 
can be restored if need be.  It doesn't seem to help much on the server 
usually, but it's saved me on the client side.

- -- SER
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8ufZuP0KxygnleI8RAsttAJ9jXmLmc4YLB4V3ea8pv3Y8U6YLSwCeJLU9
Yedq3Gb91RwgVD05Tb65gVk=
=o4ro
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: HEAD problems with Apache, and a request for changing the build instructions

[Karl Fogel <kf...@newton.ch.collab.net>]

Bruce Atherton <br...@callenish.com> writes:
> I expect eventually it will get committed, though someone can correct
> me if I'm wrong and I'll find some other home for it. The "powers that
> be" are mostly C guys, so they aren't going to be that familiar with
> Ant. Also, I failed to mark the message with a [PATCH] subject line
> (since these are actually new files), so it may have slipped through
> their scripts for catching such things.

Yeah, we should include this in the tools/dev/ directory.  Apologies
for letting it slip through the cracks; can you repost it as a patch
for tools/dev/ and we'll get it in there?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org