[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Running SVN 1.9.x on ASF servers?

From: Tony Stevenson <pctony_at_apache.org>
Date: Tue, 01 Dec 2015 21:13:08 +0000

cc+= David Nalley (for oversight, the fact there is an 'issue', etc).

Hey Greg,

Sorry I didn't mean to use beta. You are indeed correct, as usual, they
are releases. :)

I will state again, that while I appreciate that differing versions of
httpd and/or subversion (and the libraries it uses) is far from a a
trivial task for us. This will essentially mean migrating and replacing
the current EU slave to bring it into line with the US master.  You may
recall that the US master move (and therefore migration) was forced upon
us when eris died over a year ago now.

This forced move meant the host was put on a different OS, which
introduced the disparity between the EU and US today.

Fixing this is something that Infra would consider a project piece. i.e.
not something we can just slot in this week. Given the projects on the
table already, and the skills in Infra to to do the work being tied up
in other projects; it is going to be weeks before there is any available
cycles to address it.

I understand this might not be what you want to hear, but it is a fact
of where we are in terms of standardising, and automating everything.

With all that being said, I suspect you would not want us to deploy 1.9
onto a single host (US) leaving the EU slave where it is now?

Tony

On Tue, 1 Dec 2015, at 08:45 PM, Greg Stein wrote:
> We've *always* been willing to help.
>
> Note these are not "beta" (like you said back in October). They are
> 1.9.x release packages. We don't have to do a repository upgrade at
> this time, but we may want to later. Note that you have different
> httpd packages on us and eu. That should be fixed first. And then,
> yes: upgrading the server means upgrading mod_dav_svn.
>
> Part of the reason for upgrade is to get everybody better performance,
> but also to bring us and eu into alignment. Having the write-through
> proxy be a different stack is not "bad", but it certainly isn't Good.
>
> Thanks, -g
>
>
> On Mon, Nov 30, 2015 at 8:40 AM, Tony Stevenson
> <pctony_at_apache.org> wrote:
>> __
>> Greg,
>>
>> In principal this is fine, yes. If the *PMC* are going to vouch for
>> these binaries, and are willing to help support Infra if/when they
>> are deployed.
>>
>> Of course, I will re-iterate that Infra will roll back if any forward
>> rolling is catastrophic to the service.  We are also likely to want
>> to roll up the repo, in to a tarball or some such before hitting the
>> big red button. JIC we need to roll back, and we cannot undo svnadmin
>> upgrade (assuming such an action is needed too).
>>
>> Perhaps a crash course for the PMC about the stack as is, and how we
>> get to a deployed update is a good idea?   Also, we'd like/need a
>> JIRA issue for each bump you want (to contain any notices about steps
>> required, or library changes and so on).
>>
>> Will you expect us to roll dav_svn et al each time too? If so we
>> should ensure that your package names match those upstream in Ubuntu
>> ( I assume James can cope with that, given his email address ;) ).
>>
>>
>> On Sun, 29 Nov 2015, at 10:00 PM, Greg Stein wrote:
>>> Does this work for you, Tony?
>>>
>>> On Sat, Nov 28, 2015 at 10:04 PM, James McCoy <jamessan_at_debian.org>
>>> wrote:
>>>> On Fri, Nov 27, 2015 at 10:53:43AM +0100, Bert Huijben wrote:
>>>>
> Is somebody still working on this?
>>>>
>>>> I had mentioned on IRC that I'd provide a PPA based on my Debian
>>>> packaging.  I forgot to follow up and state that it's available:
>>>>
>>>> https://launchpad.net/~jamessan/+archive/ubuntu/subversion
>>>>
>>>> Cheers,
>>>> --
>>>>
James
>>>>
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan_at_debian.org>
>>
>>
>> Cheers
>>
>> --
>> Tony
>>

Cheers

--
Tony
 
Received on 2015-12-01 22:13:11 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.