When infra does move svn to the 1.7 candidates, we're committed to only moving forward with that, not back to a previous 1.6. So as long as we're all confident that serious problems can be addressed in a reasonable period of time, I'm +1 as well.
>________________________________ >From: Hyrum K Wright <hyrum.wri...@wandisco.com> >To: C. Michael Pilato <cmpil...@collab.net> >Cc: Daniel Shahaf <d...@daniel.shahaf.name>; dev@subversion.apache.org >Sent: Tuesday, August 23, 2011 8:52 AM >Subject: Re: 1.7.0-rc1 on svn.apache.org > >On Tue, Aug 23, 2011 at 7:06 AM, C. Michael Pilato <cmpil...@collab.net> wrote: >> On 08/23/2011 06:29 AM, Daniel Shahaf wrote: >>> - Bert points out that the HTTPv2 code may not interact well with >>> clients committing via the svn.eu mirror to an HTTPv2-enabled svn.us. >> >> Hrm, I can't think of any scenarios in which having a newer master version >> than slave version will cause issues. (It's the reverse case that can be >> problematic.) But then, I'm not completely awake yet, either. > >Although I don't want to be playing fast-and-loose with the ASF repo, >running the RC on svn.apache.org would give us just the type of >testing in these types of scenarios that's difficult to do manually. > >Assuming there is a decent "what to do if this thing borks the server" >plan, I'm +1. > >-Hyrum > > >-- > >uberSVN: Apache Subversion Made Easy >http://www.uberSVN.com/ > > >
