先给结论
虚拟机下SVN安装失败，九成问题出在源配置、依赖冲突或服务启动参数上，跟虚拟机本身关系不大，最直接的解决路径是：先确认系统发行版和镜像源，再查看错误日志定位依赖缺失，最后用绝对路径启动服务并检查防火墙规则，下面按故障类别给出可操作的排查顺序。
虚拟机里装SVN，为什么总比物理机多一步
物理机上装SVN,通常下载安装包一路下一步就结束了，虚拟机里出问题，往往不是SVN本身的问题，而是你创建虚拟机时选的系统模板和网络配置“坑”了自己。
例如用CentOS 7最小化安装模板创建的虚拟机，默认连wget和vim都没有，更别说subversion的依赖库了，此时你执行yum install subversion，安装过程要么卡在找不到软件包，要么报一串Requires: libapr-1.so.0()(64bit)这类依赖错误。
另一个常见场景是Ubuntu虚拟机,用apt-get install subversion装到一半突然报Unable to locate package subversion，多数情况下是因为系统自带的/etc/apt/sources.list是精简版，软件源里根本没有收录subversion相关包。
所以当你在虚拟机里排查svn安装失败原因时,第一件事不是重装，而是确认自己装的哪个发行版、用的哪个源，这也是业内专家反复提醒的排查起点。
第一步：核实环境，别让错误日志背锅
查看系统发行版和内核版本
执行以下命令,确认你的虚拟机镜像是否完整：
cat /etc/os-release uname -a
如果你发现虚拟机用的是精简版模板（例如CentOS的Minimal、Ubuntu的Server版），后续所有操作都要先把基础工具链补齐，否则很多报错都会是误导性的“假故障”。
定位安装失败的具体错误
安装SVN失败时,终端输出会停留在最后一个报错信息上，用鼠标往上翻看，或者执行：
yum install subversion 2>&1 | tee /tmp/svn_install.log
然后打开/tmp/svn_install.log，重点关注“Error”“Nothing to do”“Requires”这三个关键词，以下是对照表：
| 报错关键词 | 实际原因 | 解决方向 |
|---|---|---|
Cannot find a valid baseurl for repo |
YUM源不可达 | 更换国内镜像源 |
Requires: libapr-1.so.0 |
缺少APR依赖库 | 手动安装依赖包 |
Package does not exist
|
源中无此软件包 | 添加EPEL扩展源 |
Another app is currently holding the yum lock |
后台有安装进程 | 杀死yum进程或等待 |
第二步：换源是头号解药
很多虚拟机在创建时使用的是官方默认源,而官方源在国内访问极慢，甚至直接超时，这会导致安装过程中下载中断、元数据过期，最终报错失败。
CentOS/RHEL系：配置国内镜像源
备份原源文件：
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
下载简米云镜像源（也可以用清华、中科大源）：
curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
清理缓存后重试：
yum clean all yum makecache yum install -y subversion
Ubuntu/Debian系：重写源列表
编辑/etc/apt/sources.list，将archive.ubuntu.com替换为mirrors.aliyun.com，然后执行：
apt-get update apt-get install -y subversion
安装完成后验证
执行svn --version，如果输出版本号，说明核心安装成功，接着执行whereis svn,确认安装路径，记住这个路径后面要用。
第三步：虚拟机svn认证失败缓存问题排查
安装成功之后,紧接着会遇到一个高频问题客户端访问时报Authentication failed，或者提示Error: Unable to connect to a repository at URL，这个现象在虚拟机的NAT网络模式下特别容易出现。
认证失败的第一嫌疑：密码存储缓存
你在物理机上访问过SVN服务器后,~/.subversion/auth/目录下会缓存认证信息，虚拟机如果克隆自某个已经配置过SVN的模板，这个缓存会直接继承过来，导致新环境下认证信息错乱。
解决办法是清空认证缓存：
rm -rf ~/.subversion/auth
然后重新访问SVN服务器,输入正确的用户名和密码。
第二嫌疑：svnserve服务未以绝对路径启动
虚拟机重启后,svnserve服务不会自动加载仓库配置，很多用户在手动启动时习惯写成：
svnserve -d -r /home/svn --listen-port 3690
如果仓库目录和启动命令不匹配,客户端能ping通虚拟机IP，但一访问仓库路径就报No such repository。
正确的验证方式是本地执行：
svn list svn://192.168.x.x/repos --allow-non-interactive
如果本地能列出目录,说明服务正常，问题出在客户端到虚拟机之间的网络链路。
第四步：依赖冲突是虚拟机的老演员
虚拟机系统为了精简体积,往往会裁剪掉一些SVN运行所需的共享库，安装时报Requires: libexpat.so.1或者libaprutil-1.so.0找不到，就是这个原因。
用包管理器自动解决依赖
CentOS系执行：
yum install -y apr apr-util expat neon
Ubuntu系执行：
apt-get install -y libapr1 libaprutil1 libexpat1
然后重新安装subversion：
yum install -y subversion
清理已损坏的依赖缓存
如果之前安装失败留下了残留文件,先执行：
package-cleanup --problems # CentOS系
Ubuntu系可以执行：
dpkg --configure -a apt-get install -f
第五步：服务起不来，先查防火墙和SELinux
SVN默认监听3690端口，虚拟机环境通常同时开着firewalld和SELinux，这两个机制会悄无声息地拦截外部访问。
firewalld放行SVN端口
firewall-cmd --zone=public --add-port=3690/tcp --permanent firewall-cmd --reload
SELinux状态检查
getenforce
如果显示Enforcing，执行以下命令让SELinux放行svn相关操作：
setsebool -P httpd_can_network_connect on
但更省事的方法是临时切换为宽松模式：
setenforce 0
这里多说一句：虚拟机里排查svn服务端口不通时，先用telnet 虚拟机IP 3690测试端口通不通，再去看服务日志，很多人在防火墙和SELinux上浪费大量时间，结果发现是宿主机VMware的网络模式选错了。
NAT、桥接还是仅主机网络模式决定成败
如果你用的是NAT模式,宿主机能访问虚拟机的3690端口吗？答案是：默认情况下能，但前提是VMware的NAT端口转发规则里添加了3690端口映射，桥接模式则不需要额外配置，虚拟机直接占用局域网内独立IP。
建议在创建虚拟机时选择桥接模式,省去端口映射的麻烦，如果已经用NAT模式创建好了，可以在虚拟网络编辑器里手动添加端口转发规则。
第六步：仓库初始化没做，客户端照样连不上
服务装好了、端口通着，但客户端访问svn://IP/repos还是报URL path not found，原因很简单仓库目录是空的，或者根本没初始化。
正确的仓库创建流程
mkdir -p /home/svn/repos svnadmin create /home/svn/repos
创建完成后检查配置文件：
ls /home/svn/repos/conf/
这个目录下应该有svnserve.conf、passwd、authz三个文件。
在svnserve.conf中确认以下内容没有被注释掉：
anon-access = none
auth-access = write
password-db = passwd
authz-db = authz权限设置完后要重启服务
修改配置后,必须重启svnserve进程：
pkill svnserve svnserve -d -r /home/svn --listen-port 3690
注意这里-r参数指向的是仓库根目录/home/svn，而不是仓库路径/home/svn/repos，这样客户端访问svn://IP/repos时才能找到仓库。
常见问题：虚拟机装SVN时反复遇到的几个坎
以下三个问题在各类技术社区里被反复讨论,属于虚拟机环境下SVN安装失败的高频坎：
用yum install subversion提示没有可用软件包
这是因为你的源里没有收录subversion,执行以下命令：
yum install -y epel-release
安装EPEL扩展源后再执行安装命令,这是CentOS系最常见的解法。
Ubuntu虚拟机执行apt-get install subversion报软件包未找到
先执行：
apt-get update
如果还是找不到,检查/etc/apt/sources.list里的路径是bionic还是focal，与实际系统版本不匹配会导致索引失效，可以手动替换为国内源对应的版本代号。
虚拟机重启后svnserve服务自动消失
没有配置开机自启,将启动命令写入/etc/rc.local，并赋予执行权限：
echo '/usr/bin/svnserve -d -r /home/svn' >> /etc/rc.local chmod +x /etc/rc.local
或者使用systemd服务单元文件,这里不再展开。
虚拟机下SVN安装失败,核心排查路径是：换源、装依赖、清缓存、查防火墙、配仓库，把这五步按顺序走一遍，绝大多数问题都能定位到具体环节，安装失败的报错并不可怕，可怕的是不看日志就反复重装，记住一句话：先看环境再谈安装，先查日志再动配置。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/632719.html
