On Thu, Aug 6, 2009 at 4:20 PM, Les Mikesell<lesmikesell_at_gmail.com> wrote:
> Dan Stromberg wrote:
>>> Is the subversion server a build host too?
> You might want to consider virtual machines (vmware, virtualbox, etc.) to
> permit different build targets without requiring your own infrastructure to
> always match.
>>> Even so, I don't think I'd want
>>> to keep using a 1.4.x.
>> Was 1.4.x kind of unstable or something?
> I don't think it was broken - except perhaps for the odd issue you are
> having, but there are improvements in the newer versions that you probably
> want while you are going to the trouble of moving it.
> The one thing to watch out for when updating is that newer clients will
> update working copy so you can't access it with older client versions. You
> can still use old clients with a newer server - you just can't access the
> same working copy with new, then old clients.
> Les Mikesell
Bad news: the latest subversion is incompatible with the apache plugin
we've been using.
I've built apache before, as well as APR, but I'm not sure I want to
saddle my successor with that.
I built a new mod_dav_svn for the version of apache already on the
system, but that just segfaults. I'm pretty sure both apache and my
mod_dav_svn were built against the same APR, but subversion's
configure script complained about the APR being too old until I gave
it a path to apxr2.
Am I correct in thinking that my options are:
1) Plow ahead with the APR and apache (and subversion, with the new
2) Go back to the old subversion, and just live with the potentially
corrupted repo that doesn't seem to be preventing modern builds
3) Do a tar | ssh tar despite the word size and slight operating
We're fine with a stopgap measure for this. A long term view is not
necessarily in this case.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-07 23:08:41 CEST