Subversion on RedHat

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

 

Reply | Threaded
Open this post in threaded view
|

Re: Subversion on RedHat

Zdenek Sedlak
Den 2017-05-20 kl. 11:55, skrev 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
Reply | Threaded
Open this post in threaded view
|

RE: Subversion on RedHat

Grierson, David-2
In reply to this post by Cedric J.F. Blomart (MINFIN)

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:[hidden email]]
Sent: 20 May 2017 10:56
To: [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion on RedHat

Robert Heller
In reply to this post by Cedric J.F. Blomart (MINFIN)
At Sat, 20 May 2017 09:55:45 +0000 "Cedric J.F. Blomart (MINFIN)" <[hidden email]> wrote:

>
>
> 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.

>
> Cédric
>
>                              

--
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
[hidden email]       -- Webhosting Services
                                                                                               
Reply | Threaded
Open this post in threaded view
|

Re: Subversion on RedHat

Nico Kadel-Garcia-2
On Mon, May 22, 2017 at 7:39 AM, Robert Heller <[hidden email]> wrote:

> At Sat, 20 May 2017 09:55:45 +0000 "Cedric J.F. Blomart (MINFIN)" <[hidden email]> wrote:
>
>>
>>
>> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Subversion on RedHat

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:[hidden email]]
Envoyé : Tuesday, May 23, 2017 6:01 AM
À : Robert Heller <[hidden email]>
Cc : Cedric J.F. Blomart (MINFIN) <[hidden email]>; [hidden email]
Objet : Re: Subversion on RedHat

On Mon, May 22, 2017 at 7:39 AM, Robert Heller <[hidden email]> wrote:

> At Sat, 20 May 2017 09:55:45 +0000 "Cedric J.F. Blomart (MINFIN)" <[hidden email]> wrote:
>
>>
>>
>> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion on RedHat

Daniel Shahaf-2
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...)
Reply | Threaded
Open this post in threaded view
|

Re: Subversion on RedHat

Nico Kadel-Garcia-2
On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Subversion on RedHat

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:[hidden email]]
Envoyé : Tuesday, May 23, 2017 1:34 PM
À : Daniel Shahaf <[hidden email]>
Cc : Cedric J.F. Blomart (MINFIN) <[hidden email]>; Subversion <[hidden email]>; Robert Heller <[hidden email]>
Objet : Re: Subversion on RedHat

On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Subversion on RedHat

Todd Armstrong-2
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:[hidden email]]
Sent: Tuesday, May 23, 2017 6:51 AM
To: Nico Kadel-Garcia <[hidden email]>; Daniel Shahaf <[hidden email]>
Cc: Subversion <[hidden email]>; Robert Heller <[hidden email]>
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:[hidden email]] Envoyé : Tuesday, May 23, 2017 1:34 PM À : Daniel Shahaf <[hidden email]> Cc : Cedric J.F. Blomart (MINFIN) <[hidden email]>; Subversion <[hidden email]>; Robert Heller <[hidden email]> Objet : Re: Subversion on RedHat

On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

RE: Subversion on RedHat

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:[hidden email]]
Envoyé : Tuesday, May 23, 2017 5:05 PM
À : Cedric J.F. Blomart (MINFIN) <[hidden email]>; Nico Kadel-Garcia <[hidden email]>; Daniel Shahaf <[hidden email]>
Cc : Subversion <[hidden email]>; Robert Heller <[hidden email]>
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:[hidden email]]
Sent: Tuesday, May 23, 2017 6:51 AM
To: Nico Kadel-Garcia <[hidden email]>; Daniel Shahaf <[hidden email]>
Cc: Subversion <[hidden email]>; Robert Heller <[hidden email]>
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:[hidden email]] Envoyé : Tuesday, May 23, 2017 1:34 PM À : Daniel Shahaf <[hidden email]> Cc : Cedric J.F. Blomart (MINFIN) <[hidden email]>; Subversion <[hidden email]>; Robert Heller <[hidden email]> Objet : Re: Subversion on RedHat

On Tue, May 23, 2017 at 5:00 AM, Daniel Shahaf <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Subversion on RedHat

Nico Kadel-Garcia-2
In reply to this post by Todd Armstrong-2
On Tue, May 23, 2017 at 11:05 AM, Todd Armstrong
<[hidden email]> wrote:
> 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.