熟悉SVN的朋友应该知道在Git大行其道的今天Subversion简称SVN依然是国内大量企业、事业单位和老牌项目团队的选择。因为它足够简单、权限控制清楚、集中式管理对团队管控非常友好。而我经常被刚入行的朋友问有没有一份完整的SVN命令行操作教程确实很多新人接触SVN是从TortoiseSVN小乌龟或IDE插件开始的点鼠标很舒服但一到Linux服务器、CI脚本、紧急排障时就完全抓瞎。这篇文章我就以多年实际使用SVN的经验从命令行角度把SVN的核心操作完整过一遍包括安装配置、日常增删改查、分支合并、冲突处理、权限管理以及那些文档里不会写但实操中一定会踩的坑。不管你是刚接手老项目还是准备在服务器上部署自动化构建这篇文章都值得你收藏。1. 先搞懂SVN的工作模型再敲命令很多人在命令行上卡住不是命令记不住而是对SVN的工作方式理解有偏差。SVN是集中式版本控制和Git这种分布式版本控制在思路上有本质区别。1.1 集中式与分布式的核心差异Git的特点是每个开发者本地都有一份完整的仓库历史提交commit先在本地完成再push到远端。SVN则不同它只有一个中心版本库Repository所有历史记录都保存在服务器上每个开发者本地只有一份工作副本Working Copy。你可能会问这跟命令行操作有什么关系关系很大。因为SVN的很多命令都必须联网才能执行比如solve的登录、提交、更新这些操作都要直接和服务器交互没有本地离线提交一说。理解了这个模型你就明白为什么SVN命令行里没有先提交到本地再推送这种两步走命令了。1.2 必须记住的几个核心术语在使用SVN命令行之前有几个术语必须烂熟于心Repository版本库服务器上集中存放代码和所有历史版本的地方也是所有操作的终点。Working Copy工作副本你从版本库checkout检出到本地的那份代码目录平时所有编辑都在里面完成。Revision版本号SVN用全局递增的数字表示历史版本比如r1024每次提交都会让版本号1。这个版本号是全局的不像Git那样每个分支独立这是排查问题时的关键线索。BASE / HEADBASE指工作副本中某个文件的本地基础版本HEAD指版本库中最新的版本。这两个概念在处理冲突和理解更新时机时非常重要。提示SVN的版本号是整个版本库共享的。即使你只改一个文件并提交全局版本号也会加1。这在后期回滚时很实用但也意味着不同路径的版本号可能差距很大别看到某个文件是r50就以为仓库很年轻。2. 环境准备SVN命令行安装与配置命令行操作的前提是有一台配好svn客户端的机器。这一节分Linux和Windows两部分讲覆盖最常见的开发环境和服务器环境。2.1 Linux下安装Subversion客户端绝大多数服务器和开发机都是Linux系统安装方式很简单。Debian / Ubuntu 系列sudo apt update sudo apt install subversion -yCentOS / RHEL / Rocky 系列sudo yum install subversion -y或者较新系统用dnfsudo dnf install subversion -y装完验证一下svn --version如果看到类似svn, version 1.14.1 (r1886195)的输出说明客户端安装成功。这里多说一句源码编译安装不推荐在日常开发机上做尤其是新手。SVN依赖的库不少如apr、apr-util、sqlite等版本不匹配会导致编译失败浪费时间不说还容易把系统的包管理搞乱。用系统自带的包管理器安装维护成本最低。2.2 Windows下让svn命令全局可用Windows用户如果装了TortoiseSVN其实自带命令行工具只是默认没有配置到环境变量里。用安装包安装时记得在Choose Components这一步勾选command line client tools这一项。如果已经装好了但没有勾选命令行工具可以重新运行安装包选择修改Modify补装上。安装完成后把subversion安装目录下的bin路径默认是C:\Program Files\TortoiseSVN\bin加到系统环境变量Path中然后打开新的CMD或PowerShell输入svn --version能正常输出版本信息就行。注意Windows下如果同时装了多个SVN客户端比如开发工具自带的、TortoiseSVN自带的、独立安装的容易造成svn命令版本不一致。建议统一使用一个版本的命令行工具避免不同版本间工作副本格式不兼容导致的Working copy too old之类问题。2.3 服务端版本库创建与基本配置客户端就绪后如果要自己搭一个服务端环境来练习可以在一台Linux服务器上先创建版本库# 创建存放版本库的目录 sudo mkdir -p /srv/svn/repos # 创建仓库名为myproject sudo svnadmin create /srv/svn/repos/myproject创建后目录结构大概是这样的/srv/svn/repos/myproject ├── README.txt ├── conf/ │ ├── svnserve.conf │ ├── passwd │ └── authz ├── db/ ├── format ├── hooks/ └── locks/其中conf/svnserve.conf是服务配置文件conf/passwd是用户密码文件conf/authz是权限控制文件。这三个文件是SVN权限管理的核心后面会细讲。启动SVN自带的svnserve服务默认端口3690sudo svnserve -d -r /srv/svn/repos-d表示后台运行-r指定仓库的根目录。这样访问地址就是svn://服务器IP/myproject。2.4 用户与权限管理配置SVN的用户权限管理集中在conf目录的三个文件里命令行操作最常见的报错认证失败、权限不足都和这里有关。第一步打开conf/svnserve.conf确保以下三项配置生效[general] anon-access none auth-access write password-db passwd authz-db authz这里的含义分别是匿名用户无任何权限、认证用户可以读写、密码文件为passwd、权限文件为authz。第二步编辑conf/passwd添加用户名和密码[users] zhangsan 123456 lisi abc123在实际生产环境中密码不要太简单而且要区分不同账户的用途。比如专门的构建账号和普通开发账号权限就要不同。第三步编辑conf/authz按路径控制权限[groups] dev zhangsan,lisi pm wangwu [/] * r dev rw pm rw这段配置的意思是所有用户对根目录有只读权限dev组和pm组有读写权限。如果你希望某个目录只让特定人改可以继续往下写[/trunk] dev rw * r注意权限配置是从上往下匹配的指定规则要写在大范围的通用规则之前或更具体的位置否则可能被覆盖。我见过很多次因为权限写反导致开发人员能提交代码到/tags目录把发布标签改得一团糟。改完配置文件需要重启svnserve服务才能生效sudo pkill svnserve sudo svnserve -d -r /srv/svn/repos3. 日常开发中最常用的SVN命令操作这一节是全文的核心涵盖入职第一天到日常开发中每天都在用的命令。我从检出到提交按一条完整工作流讲下去每条命令都讲清楚为什么这么用。3.1 首次连接checkout检出代码把远程版本库的代码拉到本地是SVN所有操作的起点。命令很直观svn checkout svn://192.168.1.100/myproject /data/project/myproject如果仓库路径带了用户名认证也可以写成svn checkout svn://192.168.1.100/myproject --username zhangsan实际工作中SVN地址往往很长尤其当项目在仓库的子目录下时比如svn checkout svn://192.168.1.100/myproject/branches/dev-2.0 /data/project/dev-2.0这种检出一个分支目录的做法非常常见因为老项目的主干trunk不一定稳定开发新功能通常在分支branches上进行。提示checkout后的工作副本目录里会有个隐藏文件夹.svn里面记录了本地文件的版本状态和与服务器的关联信息。如果没有特殊需求不要手动去改.svn里的文件很容易把工作副本弄坏。关于URL路径有个容易混淆的知识点checkout svn://ip/myproject和checkout svn://ip/myproject/trunk有什么区别前者是把整个仓库根目录检出你会看到仓库里所有顶层目录trunk、branches、tags等后者只检出trunk作为工作副本根目录。团队协作中建议只检出需要的子目录既减少下载量也降低把目录结构弄乱的几率。3.2 新增与删除文件svn add / svn delete / svn revert很多刚从IDE转到命令行的人最不适应的就是新建文件后为什么同事总是拉不到因为你只是把文件放到了磁盘上SVN完全不知道它的存在。你需要显式告诉SVN。新增文件或目录# 先在本地创建文件 echo package main main.go # 将文件纳入版本控制 svn add main.go可以一次添加多个文件svn add main.go config.yml README.md也可以添加整个目录svn add src/svn add只是把文件标记为待加入版本控制真正的入库操作还要靠后面的svn commit。你可以在add后先svn status查看状态确认无误再提交。删除文件或目录svn delete old_config.xml这里的svn delete会同时做两件事删除本地文件并标记为待删除。提交后版本库中的该文件就会被删除但历史记录保留随时可以找回。有时候你想删掉本地文件但还没决定是否删除版本库里的文件可以用普通rm命令删除磁盘文件。此时svn status会显示文件状态为!缺失然后你后续可以选择# 确认从版本库中也删除 svn rm path/to/missing.file # 或者反悔恢复文件 svn revert path/to/missing.file这个操作模式我第一次用的时候觉得特别绕但其实很有用。比如你临时把某个文件移到别处去对比内容删除后发现还需要它一个svn revert就恢复原样完全不用从服务器重新拉。误操作恢复# 恢复撤销工作副本中的修改 svn revert file.txt # 恢复整个目录谨慎使用 svn revert -R .svn revert是SVN命令行中最常用的后悔药。它的原理是用工作副本中存储的BASE版本信息把文件恢复到上次更新/检出的状态。注意revert只能撤销工作副本中尚未提交的修改对于已经提交的内容需要用svn merge或svn update -r去处理回滚。3.3 提交修改svn commit的正确姿势编辑完文件要送到服务器用commit命令svn commit -m fix: 修复登录超时问题-m参数是提交说明message必须要写。如果你不写SVN会调用系统默认编辑器让你输入提交信息。新手经常在这步卡住命令敲下去之后屏幕变成一片空白或者进入vi界面不知道怎么退出保存。如果不想进入编辑器两种办法每次都带-m 说明简单明了。设置环境变量SVN_EDITOR在Linux下可以export SVN_EDITORvim。提交时也可以只提交部分文件避免把无关的修改一起带上去svn commit -m 只提交修改过的配置 etc/nginx.conf这里建议提交前先执行一下svn status看看当前工作副本到底有哪些改动防止漏提文件或者把临时文件提交上去。我见过最多的新手错误是除了代码文件把target/、node_modules/、.idea/这类本不该入库的目录也提交了。SVN没有像Git那样的.gitignore全局忽略机制需要配置svn:ignore属性来解决后面会讲到。提示SVN的提交是原子提交要么全部文件一起提交成功要么一个都不提交。这和Git的commit逻辑不同它天然保证版本库中不存在提交了一半的状态。所以即便一次提交涉及多个文件也不必担心版本库历史被割裂。3.4 拉取最新代码svn update的时机与作用团队协作中你修改代码的同时同事可能已经提交了新内容。在你提交之前最好先更新工作副本svn updatesvn update会把版本库中自上次更新以来的变更合并到工作副本里。如果本地没有修改的文件SVN会直接更新到最新版本如果本地有修改而远程也改了同一个文件的同一处就会产生冲突后面有专节讲。如果你想更新到某个特定历史版本可以svn update -r 120这会把整个工作副本回退到r120的状态本地未提交的修改会保留且可能与旧版本文件合并出冲突。这个命令在排查最近两天哪次提交把功能改坏了时特别好用你可以先临时回退到某个历史版本复现问题确认后再更新回最新版。实际操作时我建议遵循一个简单流程编辑代码前先svn update确保基于最新代码。编辑完成后再次svn update此时冲突面最小。svn commit提交前看一眼svn status确认文件清单。这个流程虽然保守但能极大减少冲突和误提交。有些人喜欢先commit再update遇到别人改了同一个文件就会很被动尤其在生产分支上搞不好还得处理别人的冲突。4. 进阶操作状态、历史、分支与冲突日常增删改查之外有四个高频场景是命令行操作升级的关键查看状态、查看历史、管理分支、处理冲突。4.1 查看工作副本状态svn statussvn status输出当前工作副本与BASE版本上次同步时的版本之间的差异状态。不加参数时它会显示所有有变化的文件每条记录有七列状态码前两列最重要。常见状态码对照状态码含义说明AAdded文件已被add待提交MModified文件已修改待提交DDeleted文件已被删除待提交?Unversioned文件未纳入版本控制!Missing文件缺失可能被rm了CConflicted文件存在冲突必须处理~Obstructed类型不一致如文件变成目录XExternal由svn:externals定义的外部引用几个实用参数# 查看简版状态只显示有改动的文件 svn status -q # 查看指定目录下所有状态 svn status path/to/dir # 以非交互模式输出适合脚本调用 svn status --xml--xml参数我强烈推荐做自动化和CI脚本时使用它输出结构化数据方便解析。4.2 查看提交历史svn log要了解最近谁改了哪些文件、提交了什么内容用log命令svn log -l 10-l 10表示显示最近10条记录强烈建议加上否则日志很长时会刷屏。只看某个文件的历史svn log -l 5 path/to/file.py查看带文件变更明细的日志svn log -v输出的Changed paths:部分会列出本次提交涉及的所有文件和路径。如果想知道某个版本到底改了哪些内容配合diff看svn diff -c 130-c 130表示查看版本号130那次提交的变更内容。4.3 比较差异svn diffsvn diff是审查代码的好帮手它能比较工作副本与BASE版本之间的差异svn diff也可以只比较某个文件svn diff path/to/file.py或者比较两个历史版本间同一路径的差异svn diff -r 100:120 path/to/file.py甚至有跨仓库路径的比较svn diff svn://ip/repo/trunk svn://ip/repo/branches/dev这在合并前审查分支差异时非常有用。4.4 撤销已提交的内容svn merge的回滚用法如果某次提交引入了一个严重Bug需要回滚用svn merge的反向合并svn merge -c -130 .这条命令的意思是对当前目录执行一次反向合并将r130这次提交的所有变更撤销掉。重点是-c -130里的那个负号它代表取消r130的改动。操作步骤svn update svn merge -c -130 . svn status # 检查回滚影响的文件 svn commit -m revert r130, fix xxx bug如果没有问题提交后版本库就回滚了。这里要注意回滚之后如果还有人基于旧版本提交冲突会变得复杂所以一旦发现提交有问题回滚越早越好。4.5 分支与标签管理SVN创建分支/标签的成本极低本质都是版本库内的copy操作命令如下# 从trunk创建分支 svn copy svn://ip/myproject/trunk svn://ip/myproject/branches/dev-3.0 -m create dev-3.0 branch from trunk # 发布时打标签 svn copy svn://ip/myproject/trunk svn://ip/myproject/tags/release-3.0.0 -m release 3.0.0注意这里的copy不是复制本地文件而是在服务器端直接复制瞬间完成不占用客户端带宽。这也是SVN在管理大型项目时的一个优点。分支合并的标准流程svn update # 先更新工作副本如果在分支目录下 svn merge svn://ip/myproject/trunk . # 把trunk最新改动合并到当前分支 svn status # 查看合并结果 svn diff --check # 检查合并后有没有明显问题 svn commit -m merge trunk into dev-3.0合并产生冲突时处理方式和普通update冲突一致见下一节。4.6 冲突处理从恐慌到从容冲突是版本控制绕不开的坑。触发场景很典型你和同事同时修改了同一个文件的同一处代码他先提交了你执行svn update时就会冲突。发生冲突时svn status下会看到两种标记C内容冲突和!位置冲突本地文件被其他文件覆盖等。以内容冲突为例目录下会多出三个文件file.c含有冲突标记的合并后文件你的修改和别人的修改都在里面file.c.mine你本地修改后的版本file.c.r120冲突发生前的一个基础版本file.c.r121对方提交的最新版本示例文件名中数字为实际版本号顺序处理方式推荐用命令行解决先看冲突内容打开file.c搜索、、标记然后决定保留哪部分# 保留我的修改放弃对方的 svn resolve --accept mine-full file.c # 保留对方的修改放弃我的 svn resolve --accept theirs-full file.c # 手动编辑完file.c后标记冲突已解决 svn resolve --accept working file.c这里特别注意svn resolve和svn revert不是一回事。revert是把文件恢复到BASE版本放弃所有本地修改resolve只是把冲突状态移开并确认你选择的版本文件内容仍然是你编辑后的结果。处理完冲突后必须提交svn commit -m resolve conflict in file.c实操心得命令行处理冲突时别急着用--accept theirs-full或mine-full除非你非常确认对方的改动无关紧要。最稳妥的方式是手动打开冲突文件看清楚两边都改了什么再逐段整理。我在团队里最怕的就是有人图省事乱选accept结果把同事的功能代码被覆盖了后面还要花更多时间去追查。5. 高频问题与排查实录这一节整理我在实际使用SVN命令行时踩过的一些坑以及对应的排查思路。5.1 认证失败与E170001错误报错信息通常是svn: E170001: Authentication failed原因通常是用户名或密码错误、用户不存在、权限配置里禁用了认证。排查思路确认账号密码是否输入正确注意密码中的特殊字符在终端里要正确转义。确认服务端svnserve.conf中anon-access none确保匿名访问不会绕过认证。确认authz文件中的权限设置看该用户是否有对应路径的访问权限。清掉本地缓存重新认证svn auth --remove svn://192.168.1.100/myproject或者直接删除~/.subversion/auth目录下对应缓存文件。在脚本环境中跑SVN命令可以使用--non-interactive参数禁用交互提示避免脚本卡在等待输入密码的地方。5.2 工作副本被锁定和cleanup遇到如下报错svn: E155004: Run svn cleanup to remove locks这是因为上一次命令异常退出比如提交时断网、CtrlC中断工作副本中的元数据锁没有释放。解决办法svn cleanupcleanup会清理中断操作留下的瞬态状态。如果cleanup本身也报错可以尝试加--remove-unversioned或删除工作副本重新checkout。但删除重来是最后的手段因为本地未提交的修改会全部丢失。在SVN 1.9版本中svn cleanup还可以配合--vacuum-pristines清理无用的原始文件可以有效缩小工作副本体积svn cleanup --vacuum-pristines5.3 版本不一致和工作副本过旧SVN有两种常见版本类报错E155036: Please see the svn upgrade commandE160024: Working copy format version is too old前者说明工作副本格式比客户端旧执行svn upgrade后者说明客户端太老无法识别新版工作副本格式需要升级客户端版本。这类问题多发于团队内不同成员使用不同SVN版本。比较好的做法是统一安装同一大版本如1.14.x的客户端服务端也要保持版本兼容。5.4 .svn目录泄露自查这个虽然不是命令行直接操作的内容但作为SVN维护者经常会被问。.svn目录里记录了服务器地址、用户名、文件路径等敏感元数据如果网站部署时把工作副本直接发布到Web服务目录黑客就可能通过/.svn/entries、/.svn/wc.db等路径探测源码和文件结构业内叫SVN泄露严重时整个源码都能被拖走。底线操作发布部署时不要直接使用SVN工作副本作为Web根目录而是要导出干净代码。使用svn export代替svn checkout来获取发布用的干净代码包export不会生成.svn目录。如果在服务器上确实需要工作副本需要在Web配置中屏蔽/.svn路径的访问。5.5 忽略文件与svn:ignore属性前面提到SVN没有全局忽略文件但可以通过svn:ignore属性实现类似效果。# 设置忽略规则 svn propset svn:ignore target node_modules *.log . # 查看已有忽略规则 svn propget svn:ignore . # 编辑已有规则 svn propedit svn:ignore .注意svn:ignore只对尚未纳入版本控制的文件生效。如果一个文件已经被加入版本库再设置ignore是没用的需要先把它从版本库中删掉svn rm --keep-local保留本地文件再设置忽略规则。这个细节坑过不少人包括我自己。6. 让命令行操作SVN更顺手的小技巧最后分享几个我日常使用的小习惯不算高深但能明显提升效率。6.1 用别名缩短高频命令在Linux的~/.bashrc或macOS的~/.zshrc里加几个别名alias svnssvn status alias svnlsvn log -l 10 alias svndsvn diff alias svnupsvn update alias svncisvn commit -m alias svnaddsvn add alias svnrmsvn rm注意svnci的用法变成svnci 修复xxx虽然和官方语义略有偏差但用起来很顺手。6.2 用svn status配合grep快速定位关键文件# 只看冲突文件 svn status | grep ^C # 只看新增文件 svn status | grep ^A # 只看未纳入版本控制的文件 svn status | grep ^?脚本中处理SVN状态时svn status --xml配合awk或python解析是更规范的做法。6.3 提交前必做diff检查无论用IDE还是命令行提交前养成svn diff的习惯。命令行操作尤其重要因为你没有IDE的变更预览面板。先diff再审阅再提交这个习惯能挡住90%的误提交。svn diff | less看完确认无误再提交svn ci -m 具体描述-m信息我建议写清楚做了什么、为什么做、影响范围别写更新、修改这种无意义日志。团队Review代码、后期回溯问题时提交信息就是第一手的决策记录。6.4 Windows下结合小乌龟使用命令行Windows用户不必完全抛弃TortoiseSVN。日常交互操作比如看冲突来看图、图形化提交用TortoiseSVN很方便但在自动化脚本、批量处理、持续集成场景里命令行才是王道。两者可以共存只要环境变量指向同一个版本的命令行程序即可。我个人的习惯是图形界面用于查看历史和冲突内容命令行用于批量操作和脚本编写。例如用TortoiseSVN更新代码后再用命令行执行跨分支合并清晰高效。根据我个人经验SVN虽然老但在很多企业内部的生命力比想象中顽强。它那套集中式管理思路和良好的目录级权限控制恰好符合不少团队的合规和安全需求。命令行操作SVN的核心其实不是背命令而是建立正确的工作副本心智模型每次update都是从服务器同步状态每次commit都是把本地变更推送上去中间的所有本地操作都不会影响服务器直到你主动提交。把这个模型理解透了即使忘了具体参数用svn help也能马上查回来。最后再分享一个小习惯新人接手SVN项目时别急着改代码先花十分钟把svn info、svn log、svn status的输出看一遍搞清楚项目当前处于哪个版本、谁在频繁动哪些文件、工作副本里有没有遗留未提交的修改再动手不迟。这个习惯在团队协作里能帮你省掉很多不必要的麻烦。
SVN命令行完全指南：从安装配置到分支合并与冲突处理
熟悉SVN的朋友应该知道在Git大行其道的今天Subversion简称SVN依然是国内大量企业、事业单位和老牌项目团队的选择。因为它足够简单、权限控制清楚、集中式管理对团队管控非常友好。而我经常被刚入行的朋友问有没有一份完整的SVN命令行操作教程确实很多新人接触SVN是从TortoiseSVN小乌龟或IDE插件开始的点鼠标很舒服但一到Linux服务器、CI脚本、紧急排障时就完全抓瞎。这篇文章我就以多年实际使用SVN的经验从命令行角度把SVN的核心操作完整过一遍包括安装配置、日常增删改查、分支合并、冲突处理、权限管理以及那些文档里不会写但实操中一定会踩的坑。不管你是刚接手老项目还是准备在服务器上部署自动化构建这篇文章都值得你收藏。1. 先搞懂SVN的工作模型再敲命令很多人在命令行上卡住不是命令记不住而是对SVN的工作方式理解有偏差。SVN是集中式版本控制和Git这种分布式版本控制在思路上有本质区别。1.1 集中式与分布式的核心差异Git的特点是每个开发者本地都有一份完整的仓库历史提交commit先在本地完成再push到远端。SVN则不同它只有一个中心版本库Repository所有历史记录都保存在服务器上每个开发者本地只有一份工作副本Working Copy。你可能会问这跟命令行操作有什么关系关系很大。因为SVN的很多命令都必须联网才能执行比如solve的登录、提交、更新这些操作都要直接和服务器交互没有本地离线提交一说。理解了这个模型你就明白为什么SVN命令行里没有先提交到本地再推送这种两步走命令了。1.2 必须记住的几个核心术语在使用SVN命令行之前有几个术语必须烂熟于心Repository版本库服务器上集中存放代码和所有历史版本的地方也是所有操作的终点。Working Copy工作副本你从版本库checkout检出到本地的那份代码目录平时所有编辑都在里面完成。Revision版本号SVN用全局递增的数字表示历史版本比如r1024每次提交都会让版本号1。这个版本号是全局的不像Git那样每个分支独立这是排查问题时的关键线索。BASE / HEADBASE指工作副本中某个文件的本地基础版本HEAD指版本库中最新的版本。这两个概念在处理冲突和理解更新时机时非常重要。提示SVN的版本号是整个版本库共享的。即使你只改一个文件并提交全局版本号也会加1。这在后期回滚时很实用但也意味着不同路径的版本号可能差距很大别看到某个文件是r50就以为仓库很年轻。2. 环境准备SVN命令行安装与配置命令行操作的前提是有一台配好svn客户端的机器。这一节分Linux和Windows两部分讲覆盖最常见的开发环境和服务器环境。2.1 Linux下安装Subversion客户端绝大多数服务器和开发机都是Linux系统安装方式很简单。Debian / Ubuntu 系列sudo apt update sudo apt install subversion -yCentOS / RHEL / Rocky 系列sudo yum install subversion -y或者较新系统用dnfsudo dnf install subversion -y装完验证一下svn --version如果看到类似svn, version 1.14.1 (r1886195)的输出说明客户端安装成功。这里多说一句源码编译安装不推荐在日常开发机上做尤其是新手。SVN依赖的库不少如apr、apr-util、sqlite等版本不匹配会导致编译失败浪费时间不说还容易把系统的包管理搞乱。用系统自带的包管理器安装维护成本最低。2.2 Windows下让svn命令全局可用Windows用户如果装了TortoiseSVN其实自带命令行工具只是默认没有配置到环境变量里。用安装包安装时记得在Choose Components这一步勾选command line client tools这一项。如果已经装好了但没有勾选命令行工具可以重新运行安装包选择修改Modify补装上。安装完成后把subversion安装目录下的bin路径默认是C:\Program Files\TortoiseSVN\bin加到系统环境变量Path中然后打开新的CMD或PowerShell输入svn --version能正常输出版本信息就行。注意Windows下如果同时装了多个SVN客户端比如开发工具自带的、TortoiseSVN自带的、独立安装的容易造成svn命令版本不一致。建议统一使用一个版本的命令行工具避免不同版本间工作副本格式不兼容导致的Working copy too old之类问题。2.3 服务端版本库创建与基本配置客户端就绪后如果要自己搭一个服务端环境来练习可以在一台Linux服务器上先创建版本库# 创建存放版本库的目录 sudo mkdir -p /srv/svn/repos # 创建仓库名为myproject sudo svnadmin create /srv/svn/repos/myproject创建后目录结构大概是这样的/srv/svn/repos/myproject ├── README.txt ├── conf/ │ ├── svnserve.conf │ ├── passwd │ └── authz ├── db/ ├── format ├── hooks/ └── locks/其中conf/svnserve.conf是服务配置文件conf/passwd是用户密码文件conf/authz是权限控制文件。这三个文件是SVN权限管理的核心后面会细讲。启动SVN自带的svnserve服务默认端口3690sudo svnserve -d -r /srv/svn/repos-d表示后台运行-r指定仓库的根目录。这样访问地址就是svn://服务器IP/myproject。2.4 用户与权限管理配置SVN的用户权限管理集中在conf目录的三个文件里命令行操作最常见的报错认证失败、权限不足都和这里有关。第一步打开conf/svnserve.conf确保以下三项配置生效[general] anon-access none auth-access write password-db passwd authz-db authz这里的含义分别是匿名用户无任何权限、认证用户可以读写、密码文件为passwd、权限文件为authz。第二步编辑conf/passwd添加用户名和密码[users] zhangsan 123456 lisi abc123在实际生产环境中密码不要太简单而且要区分不同账户的用途。比如专门的构建账号和普通开发账号权限就要不同。第三步编辑conf/authz按路径控制权限[groups] dev zhangsan,lisi pm wangwu [/] * r dev rw pm rw这段配置的意思是所有用户对根目录有只读权限dev组和pm组有读写权限。如果你希望某个目录只让特定人改可以继续往下写[/trunk] dev rw * r注意权限配置是从上往下匹配的指定规则要写在大范围的通用规则之前或更具体的位置否则可能被覆盖。我见过很多次因为权限写反导致开发人员能提交代码到/tags目录把发布标签改得一团糟。改完配置文件需要重启svnserve服务才能生效sudo pkill svnserve sudo svnserve -d -r /srv/svn/repos3. 日常开发中最常用的SVN命令操作这一节是全文的核心涵盖入职第一天到日常开发中每天都在用的命令。我从检出到提交按一条完整工作流讲下去每条命令都讲清楚为什么这么用。3.1 首次连接checkout检出代码把远程版本库的代码拉到本地是SVN所有操作的起点。命令很直观svn checkout svn://192.168.1.100/myproject /data/project/myproject如果仓库路径带了用户名认证也可以写成svn checkout svn://192.168.1.100/myproject --username zhangsan实际工作中SVN地址往往很长尤其当项目在仓库的子目录下时比如svn checkout svn://192.168.1.100/myproject/branches/dev-2.0 /data/project/dev-2.0这种检出一个分支目录的做法非常常见因为老项目的主干trunk不一定稳定开发新功能通常在分支branches上进行。提示checkout后的工作副本目录里会有个隐藏文件夹.svn里面记录了本地文件的版本状态和与服务器的关联信息。如果没有特殊需求不要手动去改.svn里的文件很容易把工作副本弄坏。关于URL路径有个容易混淆的知识点checkout svn://ip/myproject和checkout svn://ip/myproject/trunk有什么区别前者是把整个仓库根目录检出你会看到仓库里所有顶层目录trunk、branches、tags等后者只检出trunk作为工作副本根目录。团队协作中建议只检出需要的子目录既减少下载量也降低把目录结构弄乱的几率。3.2 新增与删除文件svn add / svn delete / svn revert很多刚从IDE转到命令行的人最不适应的就是新建文件后为什么同事总是拉不到因为你只是把文件放到了磁盘上SVN完全不知道它的存在。你需要显式告诉SVN。新增文件或目录# 先在本地创建文件 echo package main main.go # 将文件纳入版本控制 svn add main.go可以一次添加多个文件svn add main.go config.yml README.md也可以添加整个目录svn add src/svn add只是把文件标记为待加入版本控制真正的入库操作还要靠后面的svn commit。你可以在add后先svn status查看状态确认无误再提交。删除文件或目录svn delete old_config.xml这里的svn delete会同时做两件事删除本地文件并标记为待删除。提交后版本库中的该文件就会被删除但历史记录保留随时可以找回。有时候你想删掉本地文件但还没决定是否删除版本库里的文件可以用普通rm命令删除磁盘文件。此时svn status会显示文件状态为!缺失然后你后续可以选择# 确认从版本库中也删除 svn rm path/to/missing.file # 或者反悔恢复文件 svn revert path/to/missing.file这个操作模式我第一次用的时候觉得特别绕但其实很有用。比如你临时把某个文件移到别处去对比内容删除后发现还需要它一个svn revert就恢复原样完全不用从服务器重新拉。误操作恢复# 恢复撤销工作副本中的修改 svn revert file.txt # 恢复整个目录谨慎使用 svn revert -R .svn revert是SVN命令行中最常用的后悔药。它的原理是用工作副本中存储的BASE版本信息把文件恢复到上次更新/检出的状态。注意revert只能撤销工作副本中尚未提交的修改对于已经提交的内容需要用svn merge或svn update -r去处理回滚。3.3 提交修改svn commit的正确姿势编辑完文件要送到服务器用commit命令svn commit -m fix: 修复登录超时问题-m参数是提交说明message必须要写。如果你不写SVN会调用系统默认编辑器让你输入提交信息。新手经常在这步卡住命令敲下去之后屏幕变成一片空白或者进入vi界面不知道怎么退出保存。如果不想进入编辑器两种办法每次都带-m 说明简单明了。设置环境变量SVN_EDITOR在Linux下可以export SVN_EDITORvim。提交时也可以只提交部分文件避免把无关的修改一起带上去svn commit -m 只提交修改过的配置 etc/nginx.conf这里建议提交前先执行一下svn status看看当前工作副本到底有哪些改动防止漏提文件或者把临时文件提交上去。我见过最多的新手错误是除了代码文件把target/、node_modules/、.idea/这类本不该入库的目录也提交了。SVN没有像Git那样的.gitignore全局忽略机制需要配置svn:ignore属性来解决后面会讲到。提示SVN的提交是原子提交要么全部文件一起提交成功要么一个都不提交。这和Git的commit逻辑不同它天然保证版本库中不存在提交了一半的状态。所以即便一次提交涉及多个文件也不必担心版本库历史被割裂。3.4 拉取最新代码svn update的时机与作用团队协作中你修改代码的同时同事可能已经提交了新内容。在你提交之前最好先更新工作副本svn updatesvn update会把版本库中自上次更新以来的变更合并到工作副本里。如果本地没有修改的文件SVN会直接更新到最新版本如果本地有修改而远程也改了同一个文件的同一处就会产生冲突后面有专节讲。如果你想更新到某个特定历史版本可以svn update -r 120这会把整个工作副本回退到r120的状态本地未提交的修改会保留且可能与旧版本文件合并出冲突。这个命令在排查最近两天哪次提交把功能改坏了时特别好用你可以先临时回退到某个历史版本复现问题确认后再更新回最新版。实际操作时我建议遵循一个简单流程编辑代码前先svn update确保基于最新代码。编辑完成后再次svn update此时冲突面最小。svn commit提交前看一眼svn status确认文件清单。这个流程虽然保守但能极大减少冲突和误提交。有些人喜欢先commit再update遇到别人改了同一个文件就会很被动尤其在生产分支上搞不好还得处理别人的冲突。4. 进阶操作状态、历史、分支与冲突日常增删改查之外有四个高频场景是命令行操作升级的关键查看状态、查看历史、管理分支、处理冲突。4.1 查看工作副本状态svn statussvn status输出当前工作副本与BASE版本上次同步时的版本之间的差异状态。不加参数时它会显示所有有变化的文件每条记录有七列状态码前两列最重要。常见状态码对照状态码含义说明AAdded文件已被add待提交MModified文件已修改待提交DDeleted文件已被删除待提交?Unversioned文件未纳入版本控制!Missing文件缺失可能被rm了CConflicted文件存在冲突必须处理~Obstructed类型不一致如文件变成目录XExternal由svn:externals定义的外部引用几个实用参数# 查看简版状态只显示有改动的文件 svn status -q # 查看指定目录下所有状态 svn status path/to/dir # 以非交互模式输出适合脚本调用 svn status --xml--xml参数我强烈推荐做自动化和CI脚本时使用它输出结构化数据方便解析。4.2 查看提交历史svn log要了解最近谁改了哪些文件、提交了什么内容用log命令svn log -l 10-l 10表示显示最近10条记录强烈建议加上否则日志很长时会刷屏。只看某个文件的历史svn log -l 5 path/to/file.py查看带文件变更明细的日志svn log -v输出的Changed paths:部分会列出本次提交涉及的所有文件和路径。如果想知道某个版本到底改了哪些内容配合diff看svn diff -c 130-c 130表示查看版本号130那次提交的变更内容。4.3 比较差异svn diffsvn diff是审查代码的好帮手它能比较工作副本与BASE版本之间的差异svn diff也可以只比较某个文件svn diff path/to/file.py或者比较两个历史版本间同一路径的差异svn diff -r 100:120 path/to/file.py甚至有跨仓库路径的比较svn diff svn://ip/repo/trunk svn://ip/repo/branches/dev这在合并前审查分支差异时非常有用。4.4 撤销已提交的内容svn merge的回滚用法如果某次提交引入了一个严重Bug需要回滚用svn merge的反向合并svn merge -c -130 .这条命令的意思是对当前目录执行一次反向合并将r130这次提交的所有变更撤销掉。重点是-c -130里的那个负号它代表取消r130的改动。操作步骤svn update svn merge -c -130 . svn status # 检查回滚影响的文件 svn commit -m revert r130, fix xxx bug如果没有问题提交后版本库就回滚了。这里要注意回滚之后如果还有人基于旧版本提交冲突会变得复杂所以一旦发现提交有问题回滚越早越好。4.5 分支与标签管理SVN创建分支/标签的成本极低本质都是版本库内的copy操作命令如下# 从trunk创建分支 svn copy svn://ip/myproject/trunk svn://ip/myproject/branches/dev-3.0 -m create dev-3.0 branch from trunk # 发布时打标签 svn copy svn://ip/myproject/trunk svn://ip/myproject/tags/release-3.0.0 -m release 3.0.0注意这里的copy不是复制本地文件而是在服务器端直接复制瞬间完成不占用客户端带宽。这也是SVN在管理大型项目时的一个优点。分支合并的标准流程svn update # 先更新工作副本如果在分支目录下 svn merge svn://ip/myproject/trunk . # 把trunk最新改动合并到当前分支 svn status # 查看合并结果 svn diff --check # 检查合并后有没有明显问题 svn commit -m merge trunk into dev-3.0合并产生冲突时处理方式和普通update冲突一致见下一节。4.6 冲突处理从恐慌到从容冲突是版本控制绕不开的坑。触发场景很典型你和同事同时修改了同一个文件的同一处代码他先提交了你执行svn update时就会冲突。发生冲突时svn status下会看到两种标记C内容冲突和!位置冲突本地文件被其他文件覆盖等。以内容冲突为例目录下会多出三个文件file.c含有冲突标记的合并后文件你的修改和别人的修改都在里面file.c.mine你本地修改后的版本file.c.r120冲突发生前的一个基础版本file.c.r121对方提交的最新版本示例文件名中数字为实际版本号顺序处理方式推荐用命令行解决先看冲突内容打开file.c搜索、、标记然后决定保留哪部分# 保留我的修改放弃对方的 svn resolve --accept mine-full file.c # 保留对方的修改放弃我的 svn resolve --accept theirs-full file.c # 手动编辑完file.c后标记冲突已解决 svn resolve --accept working file.c这里特别注意svn resolve和svn revert不是一回事。revert是把文件恢复到BASE版本放弃所有本地修改resolve只是把冲突状态移开并确认你选择的版本文件内容仍然是你编辑后的结果。处理完冲突后必须提交svn commit -m resolve conflict in file.c实操心得命令行处理冲突时别急着用--accept theirs-full或mine-full除非你非常确认对方的改动无关紧要。最稳妥的方式是手动打开冲突文件看清楚两边都改了什么再逐段整理。我在团队里最怕的就是有人图省事乱选accept结果把同事的功能代码被覆盖了后面还要花更多时间去追查。5. 高频问题与排查实录这一节整理我在实际使用SVN命令行时踩过的一些坑以及对应的排查思路。5.1 认证失败与E170001错误报错信息通常是svn: E170001: Authentication failed原因通常是用户名或密码错误、用户不存在、权限配置里禁用了认证。排查思路确认账号密码是否输入正确注意密码中的特殊字符在终端里要正确转义。确认服务端svnserve.conf中anon-access none确保匿名访问不会绕过认证。确认authz文件中的权限设置看该用户是否有对应路径的访问权限。清掉本地缓存重新认证svn auth --remove svn://192.168.1.100/myproject或者直接删除~/.subversion/auth目录下对应缓存文件。在脚本环境中跑SVN命令可以使用--non-interactive参数禁用交互提示避免脚本卡在等待输入密码的地方。5.2 工作副本被锁定和cleanup遇到如下报错svn: E155004: Run svn cleanup to remove locks这是因为上一次命令异常退出比如提交时断网、CtrlC中断工作副本中的元数据锁没有释放。解决办法svn cleanupcleanup会清理中断操作留下的瞬态状态。如果cleanup本身也报错可以尝试加--remove-unversioned或删除工作副本重新checkout。但删除重来是最后的手段因为本地未提交的修改会全部丢失。在SVN 1.9版本中svn cleanup还可以配合--vacuum-pristines清理无用的原始文件可以有效缩小工作副本体积svn cleanup --vacuum-pristines5.3 版本不一致和工作副本过旧SVN有两种常见版本类报错E155036: Please see the svn upgrade commandE160024: Working copy format version is too old前者说明工作副本格式比客户端旧执行svn upgrade后者说明客户端太老无法识别新版工作副本格式需要升级客户端版本。这类问题多发于团队内不同成员使用不同SVN版本。比较好的做法是统一安装同一大版本如1.14.x的客户端服务端也要保持版本兼容。5.4 .svn目录泄露自查这个虽然不是命令行直接操作的内容但作为SVN维护者经常会被问。.svn目录里记录了服务器地址、用户名、文件路径等敏感元数据如果网站部署时把工作副本直接发布到Web服务目录黑客就可能通过/.svn/entries、/.svn/wc.db等路径探测源码和文件结构业内叫SVN泄露严重时整个源码都能被拖走。底线操作发布部署时不要直接使用SVN工作副本作为Web根目录而是要导出干净代码。使用svn export代替svn checkout来获取发布用的干净代码包export不会生成.svn目录。如果在服务器上确实需要工作副本需要在Web配置中屏蔽/.svn路径的访问。5.5 忽略文件与svn:ignore属性前面提到SVN没有全局忽略文件但可以通过svn:ignore属性实现类似效果。# 设置忽略规则 svn propset svn:ignore target node_modules *.log . # 查看已有忽略规则 svn propget svn:ignore . # 编辑已有规则 svn propedit svn:ignore .注意svn:ignore只对尚未纳入版本控制的文件生效。如果一个文件已经被加入版本库再设置ignore是没用的需要先把它从版本库中删掉svn rm --keep-local保留本地文件再设置忽略规则。这个细节坑过不少人包括我自己。6. 让命令行操作SVN更顺手的小技巧最后分享几个我日常使用的小习惯不算高深但能明显提升效率。6.1 用别名缩短高频命令在Linux的~/.bashrc或macOS的~/.zshrc里加几个别名alias svnssvn status alias svnlsvn log -l 10 alias svndsvn diff alias svnupsvn update alias svncisvn commit -m alias svnaddsvn add alias svnrmsvn rm注意svnci的用法变成svnci 修复xxx虽然和官方语义略有偏差但用起来很顺手。6.2 用svn status配合grep快速定位关键文件# 只看冲突文件 svn status | grep ^C # 只看新增文件 svn status | grep ^A # 只看未纳入版本控制的文件 svn status | grep ^?脚本中处理SVN状态时svn status --xml配合awk或python解析是更规范的做法。6.3 提交前必做diff检查无论用IDE还是命令行提交前养成svn diff的习惯。命令行操作尤其重要因为你没有IDE的变更预览面板。先diff再审阅再提交这个习惯能挡住90%的误提交。svn diff | less看完确认无误再提交svn ci -m 具体描述-m信息我建议写清楚做了什么、为什么做、影响范围别写更新、修改这种无意义日志。团队Review代码、后期回溯问题时提交信息就是第一手的决策记录。6.4 Windows下结合小乌龟使用命令行Windows用户不必完全抛弃TortoiseSVN。日常交互操作比如看冲突来看图、图形化提交用TortoiseSVN很方便但在自动化脚本、批量处理、持续集成场景里命令行才是王道。两者可以共存只要环境变量指向同一个版本的命令行程序即可。我个人的习惯是图形界面用于查看历史和冲突内容命令行用于批量操作和脚本编写。例如用TortoiseSVN更新代码后再用命令行执行跨分支合并清晰高效。根据我个人经验SVN虽然老但在很多企业内部的生命力比想象中顽强。它那套集中式管理思路和良好的目录级权限控制恰好符合不少团队的合规和安全需求。命令行操作SVN的核心其实不是背命令而是建立正确的工作副本心智模型每次update都是从服务器同步状态每次commit都是把本地变更推送上去中间的所有本地操作都不会影响服务器直到你主动提交。把这个模型理解透了即使忘了具体参数用svn help也能马上查回来。最后再分享一个小习惯新人接手SVN项目时别急着改代码先花十分钟把svn info、svn log、svn status的输出看一遍搞清楚项目当前处于哪个版本、谁在频繁动哪些文件、工作副本里有没有遗留未提交的修改再动手不迟。这个习惯在团队协作里能帮你省掉很多不必要的麻烦。
