简介：面向需要在 Windows 环境下搭建 SVN 版本控制服务的技术人员，这份资源围绕 VisualSVN Server 3.5.3 提供完整安装包与配套补丁，并额外解决 Web 端自助修改密码这一常见需求，适用于 Win7 与 Windows Server 2008 平台，对中小团队自建代码仓库、内网权限管理场景较为实用。压缩包共 15 个文件，约 7.95MB，包含 msi 安装程序、exe 补丁、dll 与 so 运行库、conf 与 ini 配置、cmd 启停脚本，以及 html、css、js 等 WebUI 页面资源和 docx 安装说明，覆盖部署、授权与密码修改三个环节。已有 831 人学习下载，说明该版本组合在实际运维中仍有稳定需求。读者可据此完成服务端安装与配置，借助 Web 界面让用户自行更新密码，减少管理员手工维护成本，并通过说明文档与脚本快速定位部署中的常见问题。
1. 老版本 SVN 服务端为什么还有人装：从一份 3.5.3 安装包说起
接手一个遗留项目时，代码仓库还挂在一台内网 Windows 机器上，运维交接文档里只写了一句“SVN 服务端装在 2008 上，别乱动”。打开一看，版本是 VisualSVN Server 3.5.3，配套的 Web 界面密码早就没人记得，新同事连只读账号都开不出来。这种场景下，重新装一套新版反而风险更大——客户端插件、钩子脚本、证书路径全是按老版本调的，动一处可能整条提交流程就断。所以一份带安装包、授权处理说明和 Web 密码修改方法的资源，对还在维护老仓库的人来说是刚需，不是怀旧。这篇笔记就围绕 visualsvn server3.5.3 这个具体版本，把安装、服务配置、Web 端账号密码重置、以及几个容易翻车的点拆开讲，适合手里有老仓库要续命、又不想大动干戈的从业者照着复现。
2. 装之前先想清楚：3.5.3 的组件构成与安装路径选择
2.1 这个版本到底装了什么
VisualSVN Server 本质上是把 Subversion 服务端、Apache HTTP Server、以及一套 Windows 管理界面打包在一起的集成安装包。3.5.3 这个版本对应的是 Subversion 1.9.x 系列的服务端能力，安装后主要落三块东西：服务进程（VisualSVN Server 服务，底层跑的是 httpd）、仓库根目录（默认在安装盘符下的 Repositories）、以及管理控制台（MMC 插件形式）。理解这个结构很关键，因为后面改 Web 密码、调端口、迁仓库，动的都是这三块里的某一块，而不是某个“黑匣子”。
安装包本身是 MSI 封装，双击后走的是标准 Windows 安装向导。这里第一个决策点是安装路径和仓库路径要不要分开。我一般会把程序装在系统盘默认位置，但把仓库根目录指到数据盘，原因是仓库会随提交量持续增长，跟系统盘抢空间是血泪经验。安装向导里有一页专门问仓库位置，别一路下一步点过去。
2.2 安装时的几个关键选项
向导里真正需要停下来看的只有三处：服务端口、认证方式、仓库路径。端口默认 443（HTTPS）和 80（HTTP），如果机器上已经有 IIS 或其他 Web 服务占着 80，安装会报端口冲突，这时候要么改端口，要么先停掉占用方。认证方式选“Subversion 认证”即可，走的是仓库自带的账号体系，跟后面 Web 界面改密码是同一套用户库，这点很重要——很多人以为 Web 密码和 SVN 密码是两回事，其实在 VisualSVN 里它们是同一个 Windows 本地用户或同一套内置账号。
安装完成后，服务会自动注册并启动。验证是否装好，不用打开控制台，直接在浏览器访问https://localhost/svn/看是否返回仓库列表页即可。如果返回证书警告，是自签证书的正常现象，继续访问能看到登录框就说明服务链路通了。
# 安装后快速验证服务与端口占用情况（在目标机器上执行） net start | findstr /i "VisualSVN" # 确认 VisualSVN Server 服务已启动 netstat -ano | findstr ":443" # 确认 443 端口处于 LISTENING第一行确认服务名存在且已运行，如果没启动，去服务管理器手动拉起并看事件日志里的 httpd 报错。第二行确认端口监听，如果 443 被别的进程占了，netstat输出里会显示对应 PID，用任务管理器反查是哪个程序，再决定改端口还是停对方。这两条命令是我每次装完必跑的，比打开图形控制台快。
2.3 仓库创建与权限模型的对应关系
装好之后第一件事是建仓库。控制台里右键 Repositories 新建，命名建议全小写无空格，因为后面钩子脚本和 URL 拼接时大小写和空格都是坑。建库时可以选择默认目录结构（trunk/branches/tags），老项目如果已有既定结构就别勾，否则会多出一层空目录。
权限这块，VisualSVN 的模型是“仓库级 + 路径级”两层。仓库级给某个组读写，路径级再对 trunk 或某个子目录做细化。常见误用是直接给所有人 Read/Write 全开，图省事，结果后面想收紧时发现钩子脚本里已经假设了匿名可读，改权限就断。我的习惯是建库时先只给管理员组完全控制，普通开发者组给 Read/Write 但限制在 trunk 和 branches，tags 只读。这个初始设置多花五分钟，后面省很多事。
3. Web 界面密码修改：账号体系、操作路径与命令行兜底
3.1 Web 密码到底改的是哪个密码
这是最容易混淆的一点。VisualSVN Server 的 Web 界面（访问/svn/那个页面）登录用的账号，和 TortoiseSVN 客户端提交时弹框输入的账号，在默认配置下是同一套。也就是说，在 Web 端改了密码，客户端下次提交就会用新密码。但前提是认证方式选的是 Subversion 认证而非 Windows 认证——如果安装时选了 Windows 集成认证，账号就是域账号或本地 Windows 账号，改密码得走 Windows 的net user或域控，Web 界面里改不了。
判断当前是哪种认证，打开控制台，右键服务器节点看属性，认证那一栏写得很清楚。资源里提到的“web 密码修改”，针对的是 Subversion 认证模式下的内置用户库。这个用户库文件在仓库根目录同级的conf下，但不要手动去编辑它，格式是 htpasswd 的变体，手改容易把哈希写坏导致整个认证失效。
3.2 图形界面改密码的标准路径
在 Subversion 认证模式下，改密码有两条路。第一条是控制台：展开服务器节点，找到 Users，右键目标用户选“Properties”，弹出的对话框里可以设置新密码。这条路径最稳，因为它会同步更新内部用户库并让服务重新加载，不需要重启。操作时注意密码策略——3.5.3 默认没有强制复杂度，但如果你之前配过组策略或改过配置，可能会拒绝弱密码，报错信息会提示策略不满足，这时候换一个含大小写和数字的组合即可。
第二条是 Web 端自助修改，但这需要额外配置，默认安装是不开的。默认的/svn/页面只提供仓库浏览，没有改密码入口。资源里如果包含 Web 密码修改的说明，通常指的是通过配置一个 CGI 或启用内置的密码修改页面来实现。这里要提醒：不要随便从网上抄一段 CGI 脚本丢进去，老版本对脚本的权限和路径很敏感，配错会导致整个 Web 界面 500。
3.3 命令行兜底：用 htpasswd 思路处理批量重置
当用户多、或者图形界面打不开时，命令行是后悔药。VisualSVN 自带了一个htpasswd.exe，藏在安装目录的bin下。用它可以直接对用户库文件操作，但操作前必须停服务，否则文件被占用写不进去。
# 进入 VisualSVN 的 bin 目录（路径按实际安装位置调整） cd "C:\Program Files\VisualSVN Server\bin" # 先停服务，避免用户库文件被占用 net stop "VisualSVN Server" # 修改指定用户的密码，-b 表示在命令行直接给密码，-m 表示 MD5 哈希 htpasswd.exe -b -m "C:\Repositories\htpasswd" zhangsan "NewPass@2024" # 重新启动服务 net start "VisualSVN Server"第一行切到工具目录，htpasswd.exe不在系统 PATH 里，必须显式进入。第二行停服务是关键，不停的话第三行会报“文件被另一个进程使用”。第三行里-b让密码跟在用户名后面直接传入，适合脚本化；-m指定哈希算法，3.5.3 支持 MD5 和 SHA，跟现有库保持一致即可，不确定就先用-m，因为老库多半是 MD5。最后的路径指向用户库文件，默认在仓库根目录下的htpasswd，如果你的仓库根目录改过，路径要跟着改。改完启动服务，用客户端拉一次代码验证，能拉下来就说明密码生效且哈希没写坏。
提示：批量重置时不要用循环一次性改几十个用户再启动，建议改三五个就启动验证一次。老版本对用户库的并发写入不友好，批量操作中途出错很难定位是哪个用户写坏了。
4. 避坑与排查：安装、认证、端口三类高频翻车
4.1 安装到一半报端口占用，服务起不来
现象是安装向导走到最后一步弹错误，或者装完后服务状态是“已停止”，手动启动几秒后又停。原因通常是 80 或 443 被 IIS、其他 Web 服务或残留的旧 httpd 进程占着。解决分两步：先用netstat -ano | findstr ":443"找到占用 PID，反查进程；如果是 IIS，停掉对应站点或改绑端口；如果是残留进程，结束它再启动 VisualSVN 服务。如果确实不能释放端口，就在控制台里改 VisualSVN 的监听端口，改完记得防火墙放行新端口，否则客户端连不上。
4.2 客户端能连但 Web 页面 403，账号密码都对
现象是 TortoiseSVN 提交正常，浏览器访问/svn/却返回 403。原因多半是 Web 访问权限和仓库权限是两套配置，Web 页面的访问控制由 httpd 的配置段管，仓库读写由 SVN 的 authz 管。默认安装下两者一致，但如果有人改过httpd-custom.conf或动过 Location 段，就会出现这种割裂。解决是打开控制台的服务器属性，检查“Web 界面”相关设置，或者直接看安装目录conf下的httpd-custom.conf，确认/svn/的Require指令没有把当前用户排除。改完重启服务生效。
4.3 改了密码客户端仍用旧密码提交成功
现象是在 Web 或控制台改了密码，客户端不弹框、直接用旧凭据提交成功，让人以为密码没改成功。原因是 TortoiseSVN 把凭据缓存到了 Windows 凭据管理器里，客户端根本没去服务端验证。解决是打开“控制面板 → 凭据管理器 → Windows 凭据”，找到对应服务器地址的条目删掉，下次操作就会重新弹框。这个坑很隐蔽，因为服务端日志里看到的还是旧会话，容易误判成密码没生效。
4.4 钩子脚本在 3.5.3 上突然不执行
现象是 pre-commit 或 post-commit 钩子之前好好的，某次改完权限或迁完仓库后不触发了。原因通常是钩子脚本的路径写的是绝对路径，而仓库根目录迁移后路径变了；或者脚本文件权限在 Windows 上丢了执行位。解决是打开仓库的hooks目录，确认脚本文件名没有.tmpl后缀（带后缀的是模板，不执行），再检查脚本里引用的仓库路径和工具路径是否还存在。Windows 下还要确认脚本首行的解释器路径正确，比如#!/bin/sh对应的 sh.exe 是否在 PATH 里。
4.5 授权处理相关文件被杀软拦截
现象是安装或运行过程中，某些文件被安全软件隔离，导致服务异常或功能缺失。原因是这类资源里的部分文件行为特征容易被误判。解决不是关掉杀软了事，而是把安装目录和仓库目录加入白名单，再重新释放被隔离的文件。如果文件已经损坏，重新从原始安装包释放对应组件，不要用网上随便找的替换文件，版本不匹配会引入更难查的问题。
5. 老仓库续命的进阶手法：备份、迁移与版本边界
5.1 动任何配置前先做一次可回滚的备份
老版本环境最怕的是改完回不去。我的习惯是每次动认证或端口之前，先把整个仓库根目录和conf目录各复制一份到独立路径，命名带日期。仓库目录用文件复制即可，但要在服务停止状态下复制，否则可能拿到不一致的快照。更稳的做法是用svnadmin hotcopy，它能在服务运行中做一致性拷贝。
# 热备份单个仓库，服务运行中也可执行 svnadmin hotcopy "C:\Repositories\myproject" "D:\backup\myproject_20240601" --clean-logs # 验证备份可读：对备份目录做一次校验 svnadmin verify "D:\backup\myproject_20240601"第一行hotcopy会把仓库完整复制到目标路径，--clean-logs表示不复制无用的日志文件，省空间。第二行verify是很多人省略的一步，但它能在你真正需要恢复之前就发现备份是否损坏。备份完把这两条命令的输出留档，出问题时能快速判断是备份坏了还是恢复步骤错了。
5.2 迁移到新机器时的版本对齐
把 3.5.3 的仓库迁到另一台机器，最容易忽略的是服务端版本对齐。Subversion 的仓库格式有版本号，低版本服务端打不开高版本格式的库。3.5.3 对应的仓库格式较老，迁到新装的高版本 VisualSVN 上通常能自动升级，但反过来不行。所以迁移方向如果是“老到新”，问题不大；如果是“新到老”或者平级迁移，先在新机器上装同版本或更高版本，用svnadmin dump导出再load导入，比直接拷目录稳妥。
| 操作 | 适用场景 | 注意点 |
|---|---|---|
| 直接复制仓库目录 | 同版本、同路径迁移 | 必须停服务，路径变了要改配置 |
| svnadmin dump/load | 跨版本迁移 | 大库耗时长，注意磁盘空间 |
| svnadmin hotcopy | 同机备份或换盘 | 服务可运行，目标路径不能已存在 |
表格里三种方式没有优劣，只看场景。直接复制最快但最挑环境，dump/load 最通用但慢，hotcopy 适合备份不适合跨大版本。我一般迁移前先用 hotcopy 留底，再用 dump/load 做正式迁移，两条路都留着。
5.3 版本边界：什么时候该停手换方案
3.5.3 毕竟是老版本，它的边界在于对新客户端特性的支持和对现代 Windows 系统的兼容。如果团队里已经有人用较新的客户端且依赖某些新特性，或者服务器系统要升级到较新版本，继续守着 3.5.3 的维护成本会超过迁移成本。判断标准很简单：当“改配置”的频率高于“写代码”的频率，或者每次系统更新都要重新折腾一遍服务，就该考虑把仓库 dump 出来迁到受支持的版本上。这份资源的价值在于让你在决定迁移之前，能把现有环境稳住、把账号密码理清楚、把备份做扎实，而不是无限期地给老系统打补丁。
从那以后我每次碰老版本服务端，都强制先跑一遍 hotcopy 加 verify，再动任何账号和端口配置。这个习惯救过我好几次——有一次改完认证整个 Web 界面起不来，靠前一天的热备份十分钟就回滚了。希望这份拆解能帮到还在维护老仓库的你，少走几个我踩过的坑。
本文还有配套的精品资源，点击获取
