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.