我呆过的公司，要么是git，要么是svn来做代码版本管理工具，不过在我看来SVN用的还是比较多的。
说实在的，git我也不会用，虽然道理差不多。
今天来讲一讲SVN吧。
抱歉，也没有去深挖、去追根究底这是怎么来，又是怎么发展的，我是个实用主义，我只告诉你这个工具一般使用方法。
了解就行。
能用就行。
一、SVN是个什么东西？
其实吧，你可以这么理解：
在一个项目开发中，不是一个人在提交代码或文件，而是很多人，有前端、后端、策划、测试，关键每个岗位都不是一个人，而是多个人。
怎么让这么多人配合起来？
项目就只有一个项目，如果是一个人，那好，直接在自己本地把代码一改。
完美。
那两个人呢？
还是同样的项目，你电脑存一份，我电脑也存一份，等我们两个都修改好了。
再把改动的都同步一下。
虽然有点麻烦，但还是OK的。
那三个人呢？
五个人呢？
十个人呢？
二十个人呢？
一样的方法，那还不得爆炸。
这样的项目还不如一个人搞呢。
太麻烦了。
同样效率也低。
所以就出了类似于中央处理器一样的代码工具，比如svn。
svn的作用是什么？
就是为了解决多人合作的。
如果你看了我前面写的主干与分支的概念，那么你就可以这么理解。
不争：入行游戏测试小知识之主干、分支zhuanlan.zhihu.comsvn作为一个服务器，当然也是一个单独的电脑。
其实它就是这个项目的主干。
一个人的话，还是老样子，自己改就行。
两个人的话，就可以从svn这台服务器的项目代码全部复制到自己的电脑本地，就是一个分支。
三个人也是一样，更多的人，也是这样。
都是从svn里把完整的项目copy一份出来，放到自己的本地电脑，可以想象为一个分支。
分散是分散了，还不是跟之前一样嘛，不就是多了一台SVN的服务器？还多用了一台电脑呢。
多人合作的关键就在于合并。
说到合并，就需要说到提交：你在你自己本地改了的内容只对你生效，其他人不会生效。
为了生效。
如果你这么一个人一个人去传递你的改动，那就太麻烦了。
有了SVN，你只需要把修改的代码传到svn，对于那些需要你改动代码部分的人而言，就直接从svn拉取就ok了。
所以流程就没必要从你直接单独传给ABCD，或者你传给A，再由他们互相传，直至所有都更新到。
突然 有点像小时候传作弊答案一样。。。
svn它像一个完整的中间商，但是它不赚差价。
不仅不赚差价，而且冲突了还不会给你上传。
那什么是冲突呢？
比如svn有一份文件1，第一行是四个字：提交冲突。
同事A把这份文件复制到他的电脑，并且在第一行的位置加了两个字，变成：提交冲突了吗。
同事B也把这份文件复制到他的电脑，然后在第一行的位置减了两个字，变成：提交。
如果是同事A先把这份文件提交到了SVN，那么这份文件1的第一行就变成了：提交冲突了吗。
这时同事B也提交，SVN一看：你这怎么提交的还是老版本？
不行，不给你提交，直接给你个报错：conflict（冲突）。
那同事B也想提交怎么办？
那他首先需要把这份文件更新到最新版本，也就是说，把第一行的“提交冲突”，先更新成“提交冲突了吗？”
更新完之后，再删掉“冲突了吗。”，只剩下“提交。”
这时再上传，svn就没道理拒绝了。
现在svn就从最初的“提交冲突”，变成“提交冲突了吗。”，再到现在的“提交。”
完成了整个版本的更新管理。。
说白了，它就是一个提交和拉代码的工具。
应该明白了吧。
不明白就再看一遍。
再看一遍还不明白，
那就算了。
接着往下看吧。
让我想想，对于我们测试而言，能拿svn做 什么。。。
算了，我直接撸一遍完整的流程吧。
假设你现在入职了一家新公司，这是你上班的第一天。
你的leader让你先down一份自己项目的代码，于是给了你一份svn的安装包，和一个svn地址的url。
然后就让你自由活动了。
你傻瓜式的下一步下一步把svn安装成功了。
然后你问leader：接下来怎么办？
leader：你先在e盘新建一个文件夹
你不会傻傻地在C盘创建一个吧？
于是你在e盘创建了一个文件夹：新项目
leader：你最好改一下名字，不要用中文，不然会出现一堆乱七八糟的问题，我建议你把文件夹名字改成英文缩写+时间的形式。比如NEW0908.
你听着有道理，于是把文件夹改成了NEW0909，改完后接着问leader然后怎么做？
leader：你先把项目代码都拉到本地。
你先点击鼠标右键，看到上面的checkout了吗？点这个。（checkout，检出）
然后你再把我刚刚给你的url地址粘贴上去，再点OK。
你按着leader的指示，复制完url，然后点击OK，你看到一堆的update刷得你眼花缭乱。
你边玩手机，边看着下载进度，一小时后，你终于点击了被从灰色到高亮的ok按钮。
然后你继续问leader接下来怎么办。
leader：你先把项目用unity打开。
然后就到了第二天。
你发现了人生第一个bug，很开心。
开发大佬跟你发了消息说，这个bug已经修复了。
你赞叹于开发大佬解bug的速度是如此之快，然后打开unity再去看下，结果bug还在。
你心情有点复杂：开发大佬都说解决了，为什么我这里看这个bug还存在呢？
想不通就问leader。
leader：你代码是不是没更新？你更新完再看。
你默默地点了一下update，又发现一堆的代码在加载。
恍然大悟：哦，原来需要先更新啊。
你更新完再打开unity，结果发现这个bug还在，你再次询问leader。
leader拿起你的鼠标，点击showlog，查看一下项目提交日志。
leader：看上传记录，都没提交。
你只能硬着头皮问开发大佬：大佬，这个是不是没提交啊？
开发大佬过了一会儿给你回了一条信息：抱歉，刚刚漏传了。
你发了个可爱的表情。
然后继续update，再打开unity，结果发现这个bug还在。
你再次问开发大佬：我刚更新了，bug还没解决。
开发大佬秒回了你的信息：不可能啊，我本地是正常的啊，是不是代码冲突了？
你只能再求助leader：刚刚开发已经提交代码了，但是我更新完还是老样子。
leader：代码冲突？那你还原一下。
你点击了revert（还原），接着是一段代码加载，再次打开unity，结果发现bug还在。
你挠了挠头，一脸懵逼地再次 问leader。
leader：还原不行，那你再清理一下。
于是你点击了cleanup（清理），照样一顿代码加载闪烁。
你再次打开unity，结果发现bug还在。
leader：那肯定是bug没改好。
开发大佬再次给你回了个信息：刚刚打错了一个字符，你更新再测一下。
你再次点击update，看unity终于bug解决了。
你开心地像个300斤的胖子。
第二天就这么愉快地结束了。
第三天你照常更新之后，发现昨天这个bug明明已经解决了，怎么现在又出现了。
你问出了你的疑惑。
leader：你回退一下版本看看。
你点击showlog，翻到昨天的版本，点击了revert to this revision（回退到这个版本）
又是一阵眼花缭乱的加载，你打开unity，发现bug是解决了的状态。
你向开发反馈了这个情况。
开发大佬过了一会儿给你回信息了：xxx把我的代码给覆盖了，你再更新看一下。
你尝试更新之后，bug是解决了。
就这么开心地度过了第三天。
第四天的时候，leader让你写一份项目体验报告提交到svn测试项目。
于是你用了一天的时间，终于在下班前选择了commit（提交）...
763
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
