To be totally clear (as I made a little typo)... the Bug # doesn't mean subversion will arrive in RHSCL but means they are investigating it. I suppose the more request they have in that direction the more they'll look into it.
-----Message d'origine----- De : Todd Armstrong [mailto:todd.armstr...@newscycle.com] Envoyé : Tuesday, May 23, 2017 5:05 PM À : Cedric J.F. Blomart (MINFIN) <cedric.blom...@minfin.fed.be>; Nico Kadel-Garcia <nka...@gmail.com>; Daniel Shahaf <d...@daniel.shahaf.name> Cc : Subversion <users@subversion.apache.org>; Robert Heller <hel...@deepsoft.com> Objet : RE: Subversion on RedHat Cedric, Thanks for posting the bug details. We have been using Wandisco's releases and are quite thankful for them as when we started using subversion a couple of years ago RHEL version was so out of date even then that we couldn't really justify starting with what they ship when 1.8 branch had so many improvements in it. The RHEL position has some merit, but given the advances between what they are shipping and what is currently available they sound a lot more to me like excellent reasons to ship svn17, svn18, svn19, etc. and use the availability of higher version as a means to make it possible (and push) their customers towards more current releases - seems like that could allow them to stay more current on each version level branch and reduce backporting of fixes to older versions by pointing those looking for them to newer versions that already have them and are available as part of RHEL. -----Original Message----- From: Cedric J.F. Blomart (MINFIN) [mailto:cedric.blom...@minfin.fed.be] Sent: Tuesday, May 23, 2017 6:51 AM To: Nico Kadel-Garcia <nka...@gmail.com>; Daniel Shahaf <d...@daniel.shahaf.name> Cc: Subversion <users@subversion.apache.org>; Robert Heller <hel...@deepsoft.com> Subject: RE: Subversion on RedHat RedHat is already evaluating is releasing a newer version of subversion is feasible in RHSCL (software collection). If anyone has the issue and support from redhat I think they should submit their case into #Bug 1162551. So RedHat are taking the direction of apart repository for newer version of subversion and not into including a "renamed" package into the default repository. Concerning version concurrency (client, server, build system), the only good solution is communication between the different parties. -----Message d'origine----- De : Nico Kadel-Garcia [mailto:nka...@gmail.com] Envoyé : Tuesday, May 23, 2017 1:34 PM À : Daniel Shahaf <d...@daniel.shahaf.name> Cc : Cedric J.F. Blomart (MINFIN) <cedric.blom...@minfin.fed.be>; Subversion <users@subversion.apache.org>; Robert Heller <hel...@deepsoft.com> Objet : Re: Subversion on RedHat On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Cedric J.F. Blomart (MINFIN) wrote on Tue, 23 May 2017 05:54 +0000: >> Multiple reasons are given for this non upgrade, manly that upgrade would be >> impacting for customer: >> For RHEL6: upgrade from 1.6 to 1.7 needing an upgrade (svn upgrade) if not >> done automated system will be blocked. Plus issues with shared file system >> needing an upgrade of clients. >> For RHEL7: impacting as working copy changed in 1.8 > > What about the server side? None of this explains why > svnadmin/svnserve/mod_dav_svn wouldn't be upgraded. > > (Well, they'd have to maintain two different copies of libsvn on the > system and ensure svn and svnadmin each picked the right one...) Yup! You would. It would be feasible to talk RHEL into adding an "sclo", or software collections library, version of Subversion over in /opt/rh/svn19/. It would pretty much guarantee emotional angst when the default Subversion 1.6.x was used on a working repository that was checked out with 1.9.x. If RHEL or a local admin swapped the default or reset the default on a Jenkins build environment, for example, I'd personally be quite upset. It would also be feasible to build an alternative package named "subvesion19", much as they used to publish multiple versions of gcc as gcc33, gcc44, etc. on the same system. So it's possible. But it's work. And I'll admit that frankly, RHEL 6 is getting a bit long in the tooth. And even git is suffering similar issues of being seriously out of date for the commercial releases of RHEL, so Subversion is not the only source control system suffering from this problem.
