[CentOS-devel] subversion / CS8 update / status of workflow

On Wed, Aug 4, 2021 at 9:28 AM Leon Fauster via CentOS-devel
<centos-devel at centos.org> wrote:
>
> Hi,
>
> inspired by a different thread here, I did a dnf distro-sync on
> a CS8 node and noticed that subversion would be downgraded:
>
> from
> subversion-1.10.2-4.module_el8.3.0+703+ba2f61b7
> to
> subversion-1.10.2-3.module_el8.3.0+393+21cd8ae8

First note. Modules Are Not Your Friend(tm). They've caused
considerable confusion about dependencies, and the technology was not
mature when introduced in RHEL 8. It's not clear that it will ever be
mature.

Second note: CS 8.4 has subversion-1.14. I'd encourage the upgrade,
the older a version of Subversion the likelier it is to have a
long-resolved security or performance issue. I say this as the guy who
used to publish the updated Subversion releases for RPMforge.
subversion-1.10.2 is over 3 years old now. If you want to run a secure
server or deal with awkward, bulky repositories, on your clients,
update.

Third note. From the recent adventures with freetype-devel, it's clear
that beta packages will show up in CentOS 8 Stream, then be deleted
and the SRPMs withdrawn from vault.centos.org, never to show up in
RHEL 8. This means that CentOS 8 Stream packages may require rollbacks
at arbitrary times, without notice. This is a new problem.

Fourth note: very few companies or developers continue to use
Subversion. Most have migrated to git, for a whole stack of reasons,
and support for subversion is increasingly difficult to find. You
pretty much have to find someone who's been around for a while to
maintain it. Maybe not as long as *me*, but it's really fallen out of
favor for a number of reasons. Even I use "git-svn" rather than
Subversion for my workspaces when compelled to use upstream Subversion
repos.

Subversion has some uses, for compelling developers to submit
*everything* to the mothership repository before compilation and
deployment. And learning it is often faster, especially with the
somewhat more popular GUI tools like TortoiseSVN for Windows users.
But subversion's developer's unwillingness to provide an "obliterate"
function, which was first requested roughly 20 years ago with its
first releases, remains a problem for large deployments. Cleaning up
after someone *inevitably* commits bulky binaries is frought with
adventures: I frankly use "git-svn" to pull it into a git repo, clean
up that, and push it back to a new Subversion repo.