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.
