1. 先说清楚SVN到底解决什么问题：从“代码用U盘互拷”说起
我第一次接触SVN，是在一个刚换工作接手老项目的下午。Leader丢给我一个U盘，说“代码在里面，你先拷下来看看”。我当时人都傻了——2020年了，还在用U盘传代码？后来才知道，项目组之前经历了“我的版本是你的版本吗”“谁改了这段逻辑又不说话”“代码合并合了三天”的混乱阶段，SVN是上一任组长在离职前费了很大劲才推起来的。说实话，当时那套SVN用得极其粗糙，很多人只会“点右键提交”和“点右键更新”，分支、标签、权限一概不懂。但即便这样，也比U盘和QQ传文件强了一百倍。
SVN，全称Subversion，是目前仍在被大量企业内部项目使用的集中式版本控制工具。它和Git最大的区别在于“中心化”：所有代码版本都存在一台中央服务器上，每个开发者从服务器拉取代码到本地（Checkout），修改后提交（Commit）回服务器。你本地没有完整的历史版本库，只有一份工作副本。打个比方，Git像是每个人手里都拿着一本完整的账本副本，各自记账再互相校对；SVN则是所有人围着一本总账本，谁要改就借出来改，改完还回去，账本永远只有一本，以服务器为准。
现在很多新人一上来就学Git，进了公司却发现自己要用SVN，整个人是懵的。网上教程要么太老，要么只讲命令不讲场景，要么干脆是IDE里点两下就完了。这也就是我想写这篇手册的原因——把我这几年实际用SVN的经验，从安装配置到日常操作，从权限管理到排错实战，完完整整梳理一遍。这篇内容不追求堆砌所有命令，而是面向“你真的要在项目里用起来”这件事。不管你是刚毕业的实习生，还是被迫从Git转过来的开发，或者是需要给团队搭环境的运维/组长，这篇文章应该都能覆盖到你的需求。
我后面写的所有操作，都会尽量兼顾两种方式：TortoiseSVN图形化操作和命令行操作。因为你可能在自己电脑上用着挺舒服的图形界面，到了服务器上就只有命令行可用。两种都熟了，才算真正会用SVN。
2. 环境搭建：TortoiseSVN安装、汉化与IDE集成的关键细节
2.1 为什么首选TortoiseSVN，以及“小乌龟”的正确安装姿势
Windows下用SVN，最主流的客户端就是TortoiseSVN，就是大家俗称的“小乌龟”。它的特点是直接集成到Windows资源管理器的右键菜单里，不需要打开单独的客户端窗口，对文件、文件夹的操作就是SVN操作，上手门槛极低。很多老项目组里，甚至测试、产品都能用它在公共目录上同步文档，这是Git做不到的——你很难让非技术人员在命令行里敲git pull。
下载的时候有个坑你必须知道：TortoiseSVN官网会同时提供两个安装包，一个是主程序，一个是Language Packs语言包。主程序安装时默认是英文界面，如果你想要中文界面，必须额外下载对应版本的中文语言包。不要装完主程序才发现是英文，又回头找语言包，版本号对不上还得重装，浪费时间。
我建议的安装顺序是：先装主程序，装完后再装语言包，然后在任意文件夹右键 → TortoiseSVN → Settings → Language，选择“中文简体”，确定后重启电脑或者注销一次，界面就完全是中文了。另外，安装主程序时有个选项是“Will be installed on local hard drive”和“Entire feature will be installed on local hard drive”，第一项是标准安装，第二项是完整安装。我建议选第二项，把命令行工具（command line client tools）也装上。这个非常重要，因为TortoiseSVN自带的图形界面有时候需要调用命令行工具，而且你想在脚本里写SVN命令时，没装这个就废了。
2.2 装在Windows之外的场景：Mac和Linux不能没有“小乌龟”
很多人会忽略一个问题：公司项目不可能所有人都是Windows。Mac用户怎么办？Linux服务器上怎么办？
Mac上TortoiseSVN是装不了的，但好消息是，macOS自带了SVN命令行工具，不过版本比较老。如果你需要图形界面，可以考虑Cornerstone或Versions这两个商业软件，也可以直接用IntelliJ IDEA自带的SVN插件。我个人建议Mac用户直接用IDEA的SVN集成功能，界面友好，而且日常提交、更新、查看日志都够用。
Linux服务器上的情况比较特殊，因为通常你是在服务器上做拉取、更新、打包发布这类操作，没有图形界面，命令行是唯一选择。用包管理器安装即可：Ubuntu/Debian系是“sudo apt install subversion”，CentOS/RHEL系是“sudo yum install subversion”。装完后用“svn --version”确认一下，能看到版本号说明装成功了。
2.3 IDEA/VS Code里配SVN：别把提交代码这事儿只看作IDE按钮
现在主流的开发工具都内置了SVN支持，但内置归内置，前置条件是你得把SVN命令行工具配置好才能用。IDEA（IntelliJ IDEA）的配置路径是：File → Settings → Version Control → Subversion，把前面命令行工具的实际路径填进去（通常在TortoiseSVN安装目录的bin目录下，比如C:\Program Files\TortoiseSVN\bin\svn.exe）。配置好后，把项目从SVN仓库Checkout出来：在IDEA欢迎页选择Get from Version Control，版本控制选Subversion，填仓库地址（比如svn://192.168.1.100/svn/project），输入账号密码就行。
VS Code的情况稍微不同，它本身没有内置SVN支持，需要通过插件扩展。搜索“svn”关键字，装下载量最高的那个即可。装完插件后在设置里指定svn.exe路径，然后在源码管理面板就能看到文件的变更状态了。插件支持标记文件（勾选/取消勾选）、提交、更新等操作，日常用足够了。
一个比较隐蔽的坑是版本匹配问题：如果你的SVN服务器是1.8以上版本，而本地的TortoiseSVN是很老的1.6版本，可能出现“工作副本过旧，请先升级”的报错。最好的方式是让团队所有人的SVN客户端版本保持一致，或者至少主版本大于等于服务器版本。我见过有团队因为这个问题，某个人永远提交不了代码，最后发现是他电脑上的小乌龟还是三年前的旧版本。
3. 日常核心操作：检出、更新、提交，以及每个操作背后的逻辑
3.1 从仓库拉取项目到本地：Checkout的正确理解
Checkout（检出）是把远程仓库的代码拉一份到本地，在你本地建立工作副本。很多从Git转过来的人会把Checkout理解成Git的clone，其实差不多，但有一个本质区别：Git是拉取完整仓库（含全部历史），SVN的Checkout默认拉取最新版本（含版本信息但不含所有历史记录），你只拿到“当前这个时刻”的文件和目录结构。
实际操作很简单。在本地某个目录下，右键 → SVN Checkout，在弹出的对话框里填仓库URL（Repository URL）。这里我要特别说一下仓库URL的三种格式：
- file:/// 开头：本地仓库，比如file:///D:/svn/repo，适合自己学习测试时使用。
- svn:// 开头：SVN自带的协议，走svnserve服务，默认端口3690，内网使用最多。
- http:// 或 https:// 开头：走Apache服务器，适合跨网络访问。
如果没有启动SVN服务，Connection就报错“无法连接到主机”。很多新人第一次用SVN就卡在这里，以为URL打错了，其实是服务端还没启动。自己学习用的是file:///格式就行，不用启动任何服务。
Checkout时有一个“Checkout Directory”字段，默认是当前目录名，你可以改成自己项目的名字。还有一个“Only check out the top folder”选项，勾上后只检出根目录，不递归下载子目录内容。这个选项在项目很大、你只需要某一层目录时会很有用，但我建议普通情况下不要勾，因为收不到完整目录结构，后面操作容易出问题。
3.2 每天的“提交”到底在提交什么：看懂本地修改状态
提交（Commit）是SVN里出现频率最高的操作。但很多人对“提交”的理解有偏差——SVN提交的是“变化”，不是“整个文件”。它是基于差异（diff）来传输的，只上传你改动过的内容，所以大文件改一行，提交时也只会传输这一行的差异，不会整文件重推。
你在本地改完代码后，文件图标会有一个橙红色的感叹号（TortoiseSVN默认配置下），这是SVN在告诉你：这个文件和仓库里的版本不一致了。打开文件所在的文件夹，点右键 → TortoiseSVN → Check for modifications，可以列出当前工作副本里所有被修改、新增、删除的文件，并且可以看到具体差异内容。
提交的入口是右键 → SVN Commit（或者右键 → TortoiseSVN → Commit）。提交前建议双击每个改动文件看一下diff，确认自己没有把调试代码、本地配置、临时文件一起提交上去。提交信息（Message）一定要写清楚，这是团队协作里最基本也是最重要的习惯。比如“fix: 修复登录页白屏问题”就比“修改”靠谱一百倍。不写清楚的话，三个月后你自己回来翻日志，看着一堆空信息，想回滚都不知道哪个版本是哪个。
还有个经常被忽略的选项是“Keep locks”（保持锁定）。如果你的文件通过SVN Lock机制加了锁，不勾选这个，提交后锁会被自动释放。对于需要独占修改的配置文件、资源文件，这个选项要留意。
3.3 更新（Update）：提交前不做这步，迟早要吵架
更新（Update）是把服务器上的最新修改拉到本地。为什么必须有这步？因为集中式版本控制的逻辑是“先改后合”，多个开发者在各自的副本上并行修改，某个人先提交了，其他人的本地副本就过期了。如果本地副本过期，你提交时会收到“Item is out of date”的报错，提交被拒绝。
所以正确的提交习惯永远是：先Update，后Commit。先更新，如果有冲突就解决冲突，然后再提交。不要一上来就直接提交，然后被服务器打回来，然后一脸茫然地看报错。
更新操作：右键 → SVN Update。更新完成后，窗口会列出更新了多少文件、有多少冲突、有多少新增，快捷键是“svn update”。这里有个经验之谈：如果你长时间没更新（比如出差两周），更新时最好使用“svn update --accept postpone”参数。这个参数的意思是遇到冲突先搁置，不要急着弹出合并窗口打断更新流程。搁置后你可以慢慢处理冲突，处理完了再标记为已解决。因为长时间不更新，工作副本和远程差异极大，用默认方式更新会弹十几个冲突窗口，点都点吐了，而且容易手滑点错选项把别人的代码覆盖掉。
3.4 冲突：不是灾难，是有标准流程处理的事件
冲突（Conflict）出现的原因是：两个开发者修改了同一文件的同一行，后更新/后提交的人就会遇到。这是SVN使用中最让人头疼的事情之一，但也是绕不开的必修课。
举个实际场景：你和小张都在改LoginController.java。你第30行加了一个校验逻辑，小张在第30行删掉了一个废弃方法，他先提交了。当你更新时，SVN发现本地和服务器对同一行都有修改，没法自动合并，于是把文件标记为冲突状态。这时候文件图标变成一个黄色三角叹号，文件本身会附带生成三个文件：LoginController.java.mine（你的版本）、LoginController.java.r1234（服务器旧版本）、LoginController.java.r1235（服务器新版本）。
处理冲突的推荐方式是右键 → Edit Conflicts。TortoiseSVN会打开一个合并工具，左边是“Their file”（服务器版本），中间是“Merged file”（合并结果区），右边是“My file”（你的版本）。你的任务是在合并区手动调整，保留双方的有效变化，去掉无效变化。处理完后保存，然后在冲突窗口点“Resolved”（已解决），SVN会删除那三个临时文件，把工作副本恢复到正常状态。
这里我要强调一个原则：冲突解决没有任何自动化银弹，核心是靠人判断“两边哪些改动是有效的”。尤其不要无脑选“使用我的版本”或“使用服务器版本”——除非你很确定另一方的改动是废物。现实中90%的冲突是双方改的地方其实不矛盾，只是因为都动了一行，人为取舍一下就行。但也因为如此，冲突处理的顺序非常重要：先看服务器版本为什么改，再看自己的版本为什么改，最后决定合并方式。顺序反了，很容易把自己依赖的东西删掉而不自知。
3.5 撤销与回滚：SVN里怎么“后悔”
我不止一次遇到有人问：“改错代码了，怎么撤销？怎么回到昨天的版本？”这里必须区分两个完全不同的操作：撤销未提交的修改和回滚已提交的版本。
撤销未提交的修改：在文件上右键 → TortoiseSVN → Revert。这个操作会把你本地所有修改清空，恢复到上次更新/提取的版本。注意，这个操作是不可恢复的，没有确认后悔的机会。你改了几个小时的内容，眼睛一闭点下去，就真的没了。所以强烈建议Revert之前，先“Save copy of reverting files to Windows Recycle Bin”这个选项勾上，这样至少还能去回收站碰碰运气。
回滚已提交的版本：SVN和Git最不一样的地方就在这。Git可以随便改历史、cherry-pick、rebase，但SVN的回滚是“反向合并”（Reverse Merge）。逻辑是：基于当前最新版本，把某个旧版本的改动反向作用回去，生成一个新的提交。操作路径是：右键 → TortoiseSVN → Show Log，在日志列表里选中某个版本，右键 → Revert changes from this revision。这样生成的提交会把这个版本的改动撤销掉，但历史记录里会多一条“Reverted xxx revision”，而不是直接删除那条历史。这个机制虽然看起来麻烦，但好处是可追溯——谁在什么时候撤销了谁的哪个版本，一清二楚。
4. 目录约定与分支管理：trunk、branches、tags为什么要这么摆
4.1 标准目录结构的重要性
SVN仓库不像Git仓库那样可以任性乱摆。一个规范的SVN仓库，通常包含三个顶层目录：trunk（主干）、branches（分支）、tags（标签）。这是SVN社区多年沉淀下来的约定俗成，强烈建议新仓库直接按这个来。
- trunk：存放当前主开发线的最新代码。所有稳定的、经过验证的代码最终都要合并到这里。
- branches：每个分支用于某个特定的开发线。比如开发一个新功能、做一个大版本重构、修一个release的补丁，都可以开分支。分支之间互不干扰，开发完再合并回trunk。
- tags：存放里程碑版本。比如v1.0、v2.0、v2.1，发布前打一个标签，相当于给当前trunk的某个版本拍个快照，之后永远不会改动。之后任何时候想回到这个版本都非常方便。
这个结构解决的核心问题是“并行开发与发布隔离”。比如公司线上跑着v1.0，团队在trunk上开发v2.0。突然线上发现一个严重bug，需要立刻修。如果在trunk上直接改，会把还没完成的v2.0代码暴露给线上。正确做法是从v1.0的tag拉一条分支（比如branches/1.0.1-fix），修完测试通过后部署到线上，再把修复合并回trunk。这样“线上稳定”“日常开发”两条线互不干扰。
4.2 分支的操作：Branch、Switch、Merge的配合
创建分支很简单：在trunk目录上右键 → Branch/Tag，填分支路径，比如branches/dev-login-page。这个操作本质上不是复制一份文件，而是建立“廉价复制”（cheap copy），仓库内部存的是指向原版本的文件引用，几乎不占空间。所以你完全不用心疼创建分支的代价，大胆用就是。
创建完分支后，开发者的工作副本需要从trunk切换到分支上继续开发。这里有个很多人都会犯的误区：以为创建分支后，本地代码自动就在分支上了。**不对。**创建分支是在服务器端操作，本地工作副本目前还指向trunk。你需要在本地右键 → Switch，把工作副本切换到新分支路径下，之后提交才会提交到分支上。
Merge（合并）是分支操作里最讲究的一步。把分支合并回trunk时，常见的两种方式：一种是直接在trunk上右键 → Merge，选择“Reintegrate a branch”，指定要合并的分支路径；另一种是用命令行“svn merge”. 这里我反复提醒：合并前先确认分支的代码已经Update到最新，合并后在本地必须重新构建、测试，再提交。否则不小心把分支上的半成品合并到主干，线上立刻就崩。
4.3 Tag为什么不应该被“提交”
一旦打了Tag，就意味着这个版本被冻结了。后续开发不应该往Tag里提交任何代码。真正的发版流程是：测试通过 → 从trunk打Tag（比如tags/release-2.0.1） → 构建发布 → 后续如果需要修复，从Tag拉分支修，修完合并回trunk，再打新的Tag。Tag在SVN里没有特殊的“只读”权限设置，它本质上就是个目录，所以全靠团队自觉遵守这个规范。最稳妥的方式是在服务端配置权限，让普通开发者只有Tag目录的只读权限，只有管理员或特定角色才有写权限。这一点我们下一节详细说。
5. 用户权限与服务端配置：谁可以干什么，必须在一开始就定好
5.1 SVN服务端搭建的两种选择
服务端的选择决定了权限管理的方式。两种最常见的方案：
svnserve方式：SVN自带的服务程序，配置简单，适合内网小团队使用。仓库目录下会有一个conf文件夹，里面有三个关键文件：svnserve.conf、passwd、authz。svnserve.conf是主配置，passwd存用户名密码，authz控制访问权限。启动命令是“svnserve -d -r /path/to/repo”（-d表示后台运行，-r表示仓库根目录）。Windows下可以注册成系统服务，方便开机自启。
Apache+SVN方式：通过Apache HTTP Server提供SVN服务，支持http协议访问。优点是可以利用Apache的SSL加密、AD/LDAP认证、更细粒度的目录权限控制，适合跨公网访问、需要HTTPS加密的团队。缺点是配置复杂度明显提升，要装Apache模块、配置httpd.conf，对新手不太友好。
小团队项目，我建议先用svnserve，简单够用。等后面人多了、权限要求细了、要跨网络访问了，再迁移到Apache方式。
5.2 authz权限配置：粒度最小能控制到文件
权限控制是SVN服务端最核心的部分。svnserve方式的权限配置在conf/authz文件里。基本逻辑是：在[groups]段定义用户组，然后为每个仓库路径设置访问权限。
配置文件结构解读：
[groups] admin = zhangsan, lisi dev = wangwu, zhaoliu test = sunqi [repo:/] @admin = rw @dev = r * = [repo:/trunk] @dev = rw @test = r [repo:/branches/dev-api] @dev = rw * = r第一行的[groups]段定义了三个组：管理员组、开发组、测试组。注意用户名是passwd文件里定义过的。下面每个段的意思是：@admin表示组，表示所有人，空值表示无权限。比如[repo:/]下面“@dev = r”的作用是让开发组成员对根路径只有读权限，“= ”表示其他所有人无权限——注意这个空值必须写，不写的话匿名用户可以访问。
权限配置有一个关键特性：默认继承上一层。如果[repo:/]里@dev = r，那么在没有单独配置的子目录里，@dev都是只读。如果你想给某个子目录开户写权限，需要单独配置。比如上面给了@dev在/trunk下有读写权限，但在根路径下仍然只有读权限。这种“先最小化授权，再按目录单独开权”的方式是最安全的。
这里我要提醒一个实操细节：passwd文件里的密码默认是明文存储的，svnserve协议本身也不加密。如果走的是公网，强烈建议不要用svnserve明文密码，改用Apache+SSL或者至少用svn+ssh协议。内网环境下一般问题不大，大家心里有数就行。
5.3 新增员工与权限回收：离职前为什么必须立刻冻结账号
SVN权限管理中最容易忽略的环节是人员变动。新人入职加账号、配权限通常大家都会做，但离职员工的账号清理，很多公司完全没意识。我见过不止一次，离职半年的前同事账号还能提交代码，甚至还有管理员权限。这是巨大的安全隐患，比代码泄露更可怕——你不知道他会提交什么，也不知道他什么时候会动手。
我的习惯是：员工离职当天，第一步移除authz里的所有权限，第二步从passwd里删除账号或者注释掉。如果人不在了但还有权限，那这人的代码历史虽然保留，但账号已经不可登录。如果用的是Windows域账号做认证，更要确保SVN服务和域账号同步。
另外，权限配置变更后，通常需要重启svnserve服务才会生效。这也提醒了大家：改完authz后不重启服务，配置没生效，容易误以为“权限没配对啊”。你可以用“svnlook tree 仓库路径”检查配置是否生效，或者干脆用没有权限的账号试一下访问被限制目录，能拒绝访问说明配置没问题。
6. 从实际问题出发：SVN日常使用中真实的排错经历
6.1 图标不显示：多数人第一周就会遇到的问题
这个问题几乎是每个SVN初学者必经的坎：明明TortoiseSVN已经装了，但文件夹里看不到绿色勾、红色叹号这些状态图标。一开始我还以为是系统坏了，后来查了才知道，这是Windows资源管理器的限制。
Windows对资源管理器Shell扩展图标覆盖（Icon Overlay）的数量有上限，常见的有OneDrive、Dropbox这类同步工具占用的图标槽。当SVN要注册状态图标时，如果槽位已经被其他软件占满，SVN的图标就显示不出来。解决方案是在TortoiseSVN的Settings → Icon Overlays里，把不需要的图标覆盖项取消勾选，或者把“Drive”项关掉（因为每个盘符都会占一个图标槽），合并成“Folder”和“File”两个就够了。
如果你还是想要图标状态，但确实显示不出来，还有一个办法：用文件资源管理器里的“TortoiseSVN”列配置，或者直接依赖右键菜单里“Check for modifications”窗口看状态。图标是提醒，不是功能——别太依赖图标，SVN操作本身不依赖图标。
6.2 “Working copy locked”错误：不是代码问题，是操作问题
“svn: Working copy 'xxx' locked”这个报错，几乎每个SVN用户都遇到过。第一次遇到时，我的第一反应是“我代码出问题了？”，后来才发现完全不是。
这个锁（lock）和前面说的文件锁定（Lock）是两回事。工作副本锁是指：某个SVN操作（比如Update）未正常完成时留下的残留状态，比如断电、强行终止进程、操作中途蓝屏，都会导致这个锁无法自动释放。缓解办法很简单：找到报错的那个目录（通常是项目根目录），右键 → TortoiseSVN → Clean up，它会清理掉残留的锁和临时状态。Clean up完成后，再重新执行更新或提交，一般就正常了。
如果Clean up也解决不了，说明锁文件/目录被谁占用了，可能是之前svn进程没退出干净。到任务管理器里结束所有svn.exe和TortoiseSVN相关进程，再Clean up一次。如果手动删除锁文件（项目根目录下的.svn目录里，比如wc.db和lock文件），也可以，但风险是如果有未完成的事务，强行删除可能导致工作副本处于不一致状态。所以删除锁文件是最后手段，先Clean up，再杀进程。
6.3 提交后想反悔，却发现“救不回来”的教训
有一次我提交了一版代码，提交完才发现把本地的一个调试配置文件一起提交上去了，而且这个文件还是编译用的核心配置，导致其他同事拉下来后项目直接启动失败。我当时的第一反应是“有没有办法把这条提交删掉？”查了很多资料都没找到。后来才明白：SVN没有“删除某次提交”的功能，它只能通过反向合并来“撤销”这次提交的改动。
具体操作当时是：右键 → Show Log，找到那次提交，右键 → Revert changes from this revision，确认后提交。这样会生成一个新的提交，把原来那次提交的改动全部撤销。注意，撤销后，原始的提交记录依然存在，不会消失。这条记录像是病毒学里的“抗体”——它无法让感染不发生，但可以中和它的伤害。
这个机制其实提醒了大家：SVN不是Git，历史不可改写。你要接受“错误的提交会留痕”这件事，把注意力放在“如何快速反向合并恢复正确状态”上。踩过这个坑之后，我养成了一个习惯：提交前，尤其是提交配置文件、依赖文件之前，一定先看一眼diff。这个习惯值好几万个回车。
6.4 安全思路：不要把.svn目录暴露到公网
这个点比较特殊，很多人没意识到但影响极大。SVN工作副本里有一个隐藏的.svn目录，存储了本地的元数据信息，包括文件版本号、修改记录、差异数据，甚至可能包含一些被删掉但还没有被Clean up清理的敏感内容。当项目通过Web服务器部署时，如果服务端配置不当，允许了对.svn目录的HTTP访问，攻击者就可以通过访问/svn/.svn/之类的路径下载到源代码、账号信息甚至更多内网信息。
正确的做法是：线上发布的代码目录里，绝对不能包含.svn目录。发布前把.svn目录从代码里排除掉。具体操作可以是打包时忽略，也可以用命令在部署前删除：find /path/to/release -name ".svn" -type d -exec rm -rf {} ;。如果用的是自动化构建工具（比如Jenkins），在构建任务里加一步“删除.svn目录”的Shell命令，这是相当重要的安全加固步骤。
我见过不少团队，开发环境代码直接拷贝到服务器上，根本没注意隐藏的.svn目录。等出了事才追悔莫及。不知道怎么检查的话，打开浏览器访问一下“http：//你的服务器地址/项目路径/.svn/”，如果返回文件列表或报错信息而不是404，那就要立刻处理了。
7. 从零搭一个完整仓库的实操：一个可以直接照做的示例
最后我放一个完整的“从零搭建SVN仓库”示例，把前面所有环节串起来。假设你在Windows服务器上搭建：
- 安装TortoiseSVN（记住勾选安装命令行工具）。
- 创建仓库目录“D:\svn\repo”，右键 → TortoiseSVN → Create Repository here，选择“Native filesystem（FSFS）”格式，这是默认且最稳定的格式。
- 在仓库目录右键 → TortoiseSVN → Repo-browser，创建一个标准的目录结构：trunk、branches、tags。可以直接用命令行更快：
svn mkdir file:///D:/svn/repo/trunk -m "create trunk" svn mkdir file:///D:/svn/repo/branches -m "create branches" svn mkdir file:///D:/svn/repo/tags -m "create tags" - 启动svnserve服务：
如果想开机自启，用“sc create svnserve binPath= ""C:\Program Files\TortoiseSVN\bin\svnserve.exe" --service -r D:\svn\repo" start= auto”注册一个Windows服务。svnserve -d -r D:/svn/repo --listen-port 3690 - 配置conf/passwd和conf/authz，添加用户“zhangsan”和“lisi”，权限设置成只有开发组对trunk有读写权限。
- 用客户端检出：
输入密码，看到“Checked out revision 1”，说明整个流程完全跑通了。svn checkout svn://服务器IP/repo/trunk --username zhangsan
这个流程看起来简单，但我实际帮别人搭过无数次，最容易出问题的点还是那两个：svnserve是不是以管理员权限启动的（权限不够无法监听端口）、防火墙有没有放行3690端口。遇到客户端连不上，先做这两步检查，比什么都强。
SVN确实不是最“时髦”的版本控制工具，这我承认。但在企业内部、传统行业项目、外包协作这些场景里，SVN的集中式管理、权限控制、简单直观的优势依然是实打实地解决着问题。我不是要比较Git和SVN谁更好——工具是拿来解决问题的，不是拿来做信仰的。能清清楚楚地掌握一套工具，把它用到位，本身就是一种核心竞争力。希望这篇手册能帮你在实际工作中少踩点坑。
