svn检出时部分文件报“permission denied”通常因操作用户与文件所有者不一致或服务端路径权限未开放：需检查本地.svn归属（如属root则用sudo chown -r $user:$user .svn）、服务端authz中目标路径是否显式授权、svnserve.conf是否启用authz-db、ssh协议下用户与仓库目录权限匹配，以及清理客户端认证缓存。
SVN检出时部分文件报“Permission denied”，通常不是整个仓库无法访问，而是某些路径或本地工作副本的特定目录权限不匹配。问题核心在于：操作用户与文件所有者不一致，或服务端对目标路径未开放对应权限。
检查本地工作副本的文件所有权和权限
检出时若混用 sudo 和普通用户，会导致 .svn 目录及其内部文件（如 lock、wc.db）归属 root，后续用其他用户执行 svn up 或 commit 就会因无写权限失败。
- 运行
ls -la .svn查看当前目录下 .svn 文件夹的 owner 和 group - 若 owner 是 root，而你正以 admin 或 dev 用户操作，需统一归属：
sudo chown -R $USER:$USER .svn - 确保关键文件可写：
chmod -R u+rw .svn（仅限开发机，生产环境慎用）
确认服务端仓库路径级权限配置
SVN 服务端（尤其是通过 svnserve 或 Apache 托管）使用 authz 文件控制路径粒度权限。即使用户认证成功，也可能因某子目录未显式授权而被拒绝。
- 打开仓库 conf/authz 文件，检查目标路径是否被明确赋予读（r）或读写（rw）权限
例如：[repo:/trunk/src]dev = rw - 注意继承规则：上级路径未设权限，子路径即使写了也无效；空行或注释后漏掉 section 头容易导致整段失效
- 确认 svnserve.conf 中
authz-db = authz已启用，且修改后重启了 svnserve 进程
排查 SSH 协议下的密钥与用户映射问题
使用 svn+ssh:// 协议时，“部分文件拒绝”可能源于 SSH 登录后实际执行命令的用户身份与仓库文件系统权限不匹配。
- SSH 到服务器后，运行
whoami && id -gn，确认登录用户能否读写仓库目录（如/var/svn/repo） - 检查仓库目录的 POSIX 权限：
ls -ld /var/svn/repo应允许该用户组进入（如 drwxr-x--- svn dev） - 若仓库由 svn 用户管理，但 SSH 登录的是 deploy 用户，需将 deploy 加入 svn 组：
sudo usermod -aG svn deploy
清理客户端缓存与认证凭据
旧的错误凭据或损坏的 auth 缓存可能导致部分请求被服务端静默拦截，表现为个别文件拉取失败。
- 删除本地 Subversion 认证缓存：
Linux/macOS：rm -rf ~/.subversion/auth/
Windows：del /s /q "%APPDATA%\Subversion\auth\" - 重新检出时手动输入账号密码（避免自动填充错误凭证）
- 如使用 Eclipse 等 IDE，还需清除其内置 SVN 客户端缓存（如刷新项目前执行 Team → Disconnect）
