Subversion on RedHat

[Cedric J.F. Blomart (MINFIN)]

Hello,

Dumb question maybe.

What is the situation with RedHat?

They do deliver Subversion 1.7 in their repositories but latest releases of Subversion (1.9) states that the 1.7 version will not accept any more bug report.

Cédric

[Zdenek Sedlak]

Post by Cedric J.F. Blomart (MINFIN)
Hello,
Dumb question maybe.
What is the situation with RedHat?
They do deliver Subversion 1.7 in their repositories but latest
releases of Subversion (1.9) states that the 1.7 version will not
accept any more bug report.
Cédric

I would not expect anything newer before RHEL8 comes.

You have some options:
1. Use something like WANdisco - they generate RPM and DEB from upstream
2. Build own RPMs
3. Send a RFE to Red Hat to include newer Subversion releases in their SCL

//Zdenek

[Grierson, David]

Red Hat have a ABI (application binary interface) consistency policy within their major revisions. For example RHEL 6 distributes Apache httpd-2.2.15 - and will only ever include httpd-2.2.15.

This is good because it allows users of RHEL6 to have a consistent software version that they know will not shift in functionality, configuration or behaviour.

You will notice though that the patch level shifts - (RHEL6.4 includes httpd-2.2.15-28) this is due to Red Hat backporting patches into their version of the package.

The same is true of the Subversion packages distributed by Red Hat - the version distributed with RHEL will be lower version number than that supported by the Subversion community - however since you're using RHEL you should have a support contract with Red Hat where you can submit bug-reports related to the version on your platform.

However as Zdenek states if you're interested in using the features of a more modern version then you can use the WANDisco or CollabNet RPM's - however you should then expect the level of support that you're paying for from those vendors.

Dg.

From: Cedric J.F. Blomart (MINFIN) [mailto:***@minfin.fed.be]
Sent: 20 May 2017 10:56
To: ***@subversion.apache.org
Subject: Subversion on RedHat

Hello,

Dumb question maybe.

What is the situation with RedHat?

They do deliver Subversion 1.7 in their repositories but latest releases of Subversion (1.9) states that the 1.7 version will not accept any more bug report.

Cédric

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

[Robert Heller]

Post by Cedric J.F. Blomart (MINFIN)
Hello,
Dumb question maybe.
What is the situation with RedHat?
They do deliver Subversion 1.7 in their repositories but latest releases of
Subversion (1.9) states that the 1.7 version will not accept any more bug
report.

You file bug reports with RedHat (bugzilla.redhat.com) and RedHat backports
bug and security fixes from Subversion 1.9 (or whatever is the current
version).

This is basicly what you do with all of the software RedHat packages for EL 6
and 7, when the RH "version" is no longer supported by the original upstream
authors.

Post by Cedric J.F. Blomart (MINFIN)
Cédric

[Nico Kadel-Garcia]

Post by Robert Heller

Post by Cedric J.F. Blomart (MINFIN)
Hello,
Dumb question maybe.
What is the situation with RedHat?
They do deliver Subversion 1.7 in their repositories but latest releases of
Subversion (1.9) states that the 1.7 version will not accept any more bug
report.

You file bug reports with RedHat (bugzilla.redhat.com) and RedHat backports
bug and security fixes from Subversion 1.9 (or whatever is the current
version).
This is basicly what you do with all of the software RedHat packages for EL 6
and 7, when the RH "version" is no longer supported by the original upstream
authors.

RPMforge used to publish compatible updates of these packages for RHEL
based systems. I wrote the last few sets of Subversion RPMs published
there, but have basically thrown in the towel as increasing new build
requirements required maintaining more and more updated, unsupported
from upstream versions of libraries. And I'm fraid that RPMforge seems
to be moribund. I'd talk to Wandisco about getting their up-to-date
builds for RHEL 7 or compatible operating systems.

[Cedric J.F. Blomart (MINFIN)]

The reason presented by redhat for not supporting more recent version of subversion is explained in the bellow link:
https://access.redhat.com/solutions/646783


So basically RedHat won't support subversion 1.9 in current realeases but is tracking a proposal to support a newer version in #Bug 1162551 (in RHSCL). So they are investingating but no promises.

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

I tought having a few information for those under RHEL subscription might help.

-----Message d'origine-----
De : Nico Kadel-Garcia [mailto:***@gmail.com]
Envoyé : Tuesday, May 23, 2017 6:01 AM
À : Robert Heller <***@deepsoft.com>
Cc : Cedric J.F. Blomart (MINFIN) <***@minfin.fed.be>; ***@subversion.apache.org
Objet : Re: Subversion on RedHat

Post by Robert Heller

Post by Cedric J.F. Blomart (MINFIN)
Hello,
Dumb question maybe.
What is the situation with RedHat?
They do deliver Subversion 1.7 in their repositories but latest
releases of Subversion (1.9) states that the 1.7 version will not
accept any more bug report.

You file bug reports with RedHat (bugzilla.redhat.com) and RedHat
backports bug and security fixes from Subversion 1.9 (or whatever is
the current version).
This is basicly what you do with all of the software RedHat packages
for EL 6 and 7, when the RH "version" is no longer supported by the
original upstream authors.

RPMforge used to publish compatible updates of these packages for RHEL based systems. I wrote the last few sets of Subversion RPMs published there, but have basically thrown in the towel as increasing new build requirements required maintaining more and more updated, unsupported from upstream versions of libraries. And I'm fraid that RPMforge seems to be moribund. I'd talk to Wandisco about getting their up-to-date builds for RHEL 7 or compat

[Daniel Shahaf]

Post by Cedric J.F. Blomart (MINFIN)
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...)

[Nico Kadel-Garcia]

Post by Daniel Shahaf

Post by Cedric J.F. Blomart (MINFIN)
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.

[Cedric J.F. Blomart (MINFIN)]

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:***@gmail.com]
Envoyé : Tuesday, May 23, 2017 1:34 PM
À : Daniel Shahaf <***@daniel.shahaf.name>
Cc : Cedric J.F. Blomart (MINFIN) <***@minfin.fed.be>; Subversion <***@subversion.apache.org>; Robert Heller <***@deepsoft.com>
Objet : Re: Subversion on RedHat

Post by Daniel Shahaf

Post by Cedric J.F. Blomart (MINFIN)
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 co

[Todd Armstrong]

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:***@minfin.fed.be]
Sent: Tuesday, May 23, 2017 6:51 AM
To: Nico Kadel-Garcia <***@gmail.com>; Daniel Shahaf <***@daniel.shahaf.name>
Cc: Subversion <***@subversion.apache.org>; Robert Heller <***@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-----

Post by Daniel Shahaf

Post by Cedric J.F. Blomart (MINFIN)
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 cont

[Cedric J.F. Blomart (MINFIN)]

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:***@Newscycle.com]
Envoyé : Tuesday, May 23, 2017 5:05 PM
À : Cedric J.F. Blomart (MINFIN) <***@minfin.fed.be>; Nico Kadel-Garcia <***@gmail.com>; Daniel Shahaf <***@daniel.shahaf.name>
Cc : Subversion <***@subversion.apache.org>; Robert Heller <***@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:***@minfin.fed.be]
Sent: Tuesday, May 23, 2017 6:51 AM
To: Nico Kadel-Garcia <***@gmail.com>; Daniel Shahaf <***@daniel.shahaf.name>
Cc: Subversion <***@subversion.apache.org>; Robert Heller <***@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-----

Post by Daniel Shahaf

Post by Cedric J.F. Blomart (MINFIN)
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 co

[Nico Kadel-Garcia]

On Tue, May 23, 2017 at 11:05 AM, Todd Armstrong

Post by Todd Armstrong
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.

Agreed, except for the dependency trees for building more recent
versions of Subversion on, say, RHEL 6 or RHEL 7. I'm reviewing my old
efforts at https://github.com/nkadel/, and I finally had to throw in
the towel because of critical security component dependencies, where
upgrading them enough for Subversion 1.9 would break existing
libraries or requre parallel installing *those*. It got out of hand.
Puttin gthem in the "sclo" repositories, installed over in
/opt/rh/svn19/, would allow including those updated libraries there as
well. It's just a lot of work, and no one's offered me money to try,
so I've personally not pursued it.