Upgrading SVN to 1.8 on CentOS 7

Upgrading SVN to 1.8 on CentOS 7

The SVN version bundled with CentOS 7 is often old (typically 1.7.x). It is fine in most cases, but you will want to upgrade when your team needs syntax features that only 1.8 supports, an older version carries a known security issue, or you need consistent SVN behavior across multiple machines. In that situation you can upgrade SVN to 1.8 by configuring the yum repository provided by Wandisco.

Check your current version first with svn --version --quiet. Compared with 1.7, 1.8 adds options like --parents and better merge tracking — but for legacy projects an upgrade is not mandatory, so assess the need before starting.

First compare the two major versions to decide whether the upgrade is really necessary:

If the team only uses SVN for documents and simple code, 1.7 is more than enough. The real drivers to upgrade are: needing 1.8-only commands or behavior, a security issue in the old version, or standardizing versions across machines. Conversely, if there is no hard requirement, staying on the bundled 1.7 is actually safer — the Wandisco repo itself has been unmaintained for years, and the risk you take on for the upgrade may outweigh the old version's problems.

1. Remove the Old SVN

yum remove subversion

Remove the old SVN bundled with the system first.

2. Configure the SVN 1.8 Repository

vi /etc/yum.repos.d/wandisco-svn.repo

Enter the following content:

[WandiscoSVN]
name=Wandisco SVN Repo
baseurl=http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/$basearch/
enabled=1
gpgcheck=0

3. Install

yum clean all && yum install subversion -y

4. Verify the Installation

svn --version

The output should show version 1.8:

svn, version 1.8.16 (r1740329)
   compiled Apr 26 2016, 13:16:01 on x86_64-unknown-linux-gnu

Also run svnadmin --version to confirm the server-side tool upgraded too — if the client and server tool versions differ, the repository format can become incompatible. You can also verify the repository is accessible:

svnadmin verify /var/svn/repos
svnlook youngest /var/svn/repos

If the revision number from svnlook youngest matches the pre-upgrade value, the repository data is intact.

Back Up the Repository First

Upgrading a repository is not like upgrading ordinary software: if svnadmin becomes incompatible with the repository format, an old repository may no longer open directly. The safe approach is a full dump first:

svnadmin dump /var/svn/repos > repos_backup.dump

If something goes wrong, restore with the old svnadmin load without losing any commit history.

One-Shot Script

Combine the entire upgrade into a single command:

yum remove subversion
sudo tee /etc/yum.repos.d/wandisco-svn.repo <<-'EOF'
[WandiscoSVN]
name=Wandisco SVN Repo
baseurl=http://opensource.wandisco.com/centos/7/svn-1.8/RPMS/$basearch/
enabled=1
gpgcheck=0
EOF
yum clean all && yum install subversion -y && svn --version

A full post-upgrade check

After the upgrade, run a self-check in this order so problems surface now rather than for users:

1. svn --version confirms the client is 1.8;
2. svnadmin --version confirms the server tool matches;
3. svnlook youngest /var/svn/repos matches the pre-upgrade max revision;
4. svn checkout a working copy, edit a file, and commit to exercise the full read/write path;
5. Confirm existing auth configs (such as authz and passwd) still apply.

Notes

1. Back up the SVN repository before upgrading (svnadmin dump) to avoid data corruption from compatibility issues;
2. The Wandisco repository has been unmaintained for years; only use it when compatibility with an old environment is required. For a fresh setup, prefer the system-bundled version or migrate to Git;
3. gpgcheck=0 disables GPG verification. For higher security, provide the official GPG key and set gpgcheck=1;
4. If svnadmin becomes incompatible with the repository format after upgrade, dump with the old svnadmin dump first, then import.

Common post-upgrade issues

Most of these surface during the full post-upgrade self-check, so don't skip that step.

Migrating to Git as an Alternative

If the team's repository has no heavy legacy baggage, consider migrating to Git directly: git svn clone imports the full SVN history into a Git repository, unlocking more mature branching and PR workflows plus a richer tool ecosystem.

The migration itself is not complex: first run git svn clone https://svn.example.com/repos -s myrepo locally to clone the full history, verify the commit log is complete, then push to a private GitHub or GitLab repository and tell the team to switch their workflow. Make sure everyone commits and syncs local changes before migrating to avoid a fork in history. For long-lived projects this is the more worthwhile direction; if you only need to solve a compatibility issue temporarily, there's no need to change systems over it.

SVN is one of the common version control systems. For more version control and team collaboration content, see the developer tools category, such as SVN local global ignore settings and Git workflow for website development. Whether you upgrade to 1.8 or migrate to Git, backing up first and verifying step by step are principles that never go wrong.

Reference: Subversion official docs https://subversion.apache.org/docs/

Original post: https://www.cnblogs.com/cqzhuomi/articles/17280906.html (cnblogs.com CQZHUOMI, repost)