On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <d.s_at_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.
Received on 2017-05-23 13:34:32 CEST