subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cedric J.F. Blomart (MINFIN)" <cedric.blom...@minfin.fed.be>
Subject RE: Subversion on RedHat
Date Tue, 23 May 2017 11:50:50 GMT
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:nkadel@gmail.com] 
Envoyé : Tuesday, May 23, 2017 1:34 PM
À : Daniel Shahaf <d.s@daniel.shahaf.name>
Cc : Cedric J.F. Blomart (MINFIN) <cedric.blomart@minfin.fed.be>; Subversion <users@subversion.apache.org>;
Robert Heller <heller@deepsoft.com>
Objet : Re: Subversion on RedHat

On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <d.s@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.
Mime
View raw message