不同版本管理系统的优劣大家搜索一下就能看到大量这方面的权威讨论和对比，我想以我的亲身经历，站在系统管理员和一线用户的角度描述一下Git、SVN、P4D这三者对于我们日常研发效率提升的真实感受。

SVN-老而弥坚但值得信赖

            时间回到2013年，当我从同事手上接过公司SVN系统管理权的时候，游戏业界正处于从端游往手游转移的前中期，公司的每个项目都有一个独立的SVN（和独立的访问域名），例如/SVN/G1、/SVN/S1等等，每个项目的子目录再按工种来划分工作目录，例如/SVN/G1/Client、/SVN/G1/Server、/SVN/G1/Plan等等。

            记忆中那段时间，每天都要花不少的时间来处理SVN的账号新增、密码修改、权限管理等等琐碎的需求，实在不厌其烦，直到后来我用openldap统一了SVN系统的账号管理，并且用PHP写了一个简单的账户自助管理系统，让每个人可以自助申请账号和修改、重置密码，我才算从这个泥潭中拔脚逃了出来。

            搞定账户自助后，还需要搞定SVN权限自助，当时想到的办法就是用SVN本身来管理SVN权限，方法也很简单，创建一个独立的SVN库，例如/SVN/Access，然后在下面创建每个项目的控制文件，例如/SVN/Access/G1/authz，每个项目定义PM、主程等至少两个人作为这个权限的管理者和编辑者，这样每个项目的日常权限的增删减就有项目同学自己负责了，只需要再写一个定时任务，把这些一一对应的authz文件同步到每个库的正确位置就大功告成了，成功甩锅（后来authz的管理也转移到了git系统）。

            趟过了SVN的账号和权限管理这个坎之后，偶尔要处理的就是SVN的性能问题。当时SVN就是装在一台1U的小刀片上，几百兆或者1~2G的小库还好，当大的库接近200G的时候，可以很明显的感觉到整个库的push和pull速度的下降，当年还没有足够的资源购买SSD，都是用着普通的SATA或者SAS硬盘，磁盘IO根本跟不上项目的需求，你想想每天早上每个项目少的几个人、多的超过20人都在拖拉同一个SVN的酸爽。

            直到今天互娱所使用的SVN架构与最初相比也没有很大的变化，变化的是用户已经是以前的10多倍，SVN库的数量也已经是以前的20多倍，存储空间增长了不止百倍，库都散列到了多个硬件上，用上了IO爆表的SSD，后来也实现了100%的云化，IO、性能和带宽都已经不是问题。之前说到的每个SVN库都使用了独立的访问域名，这个设定也让单个SVN库可以很方便的进行扩容和迁移的同时，不会影响到其他库。可以说SVN的成长和演变见证了互娱这10年的整个发展和变化，到现在它仍旧是所有项目开发不可或缺的重要部分。

            顺便提一句，我们使用的SVN方案是Apache+DAV_SVN+openldap的方案，虽老而弥坚但值得信赖，我知道有很多人说SVN已经老了，现在都是Git的世界了，但对于策划、美术这些非纯技术同学来说，Git的概念很难理解，而SVN理解和使用起来都很简单，他们愿意一直用着SVN来工作，并且工作得很好。

Git-前卫而稳定

            2015年开始越来越多的项目组把纯代码类的开发流转移到github后，我们才意识到这已经是一个不可抗拒的方向，作为一个前卫的分布式版本协作方案，其设计思维和管理策略完全匹配了这个时代的步伐，甚至有人认为，作为Linus的最重要的两个作品之一，Git的诞生及对业界的贡献比Linux本身还要伟大。时至今日Git可以说已经完全统治了软件开发的多个重要方面，而不单单是代码开发版本管理，还有DevOps、CICD等等多个方面。

            但国内网络访问github的速度问题始终是一个逃不开的梗，github的访问问题发生的非常频繁，于是在某一个炎热的夜晚，我使用gitbucket在10分钟内便搭建好了一个可用的Git系统，并且很方便的把原来SVN使用的openldap认证接入到gitbucket的中，实现了账号认证的统一。

            庆幸的是gitbucket实现了github的接近90%的功能，而且全部都是用户自管理的，所以作为管理员实际花在它上面的时间是很少很少的，项目的代码逐渐的迁入这个自建的gitbucket中，一直沿用至今，不夸张的说，这个自建的git系统实现了真正意义上的99.99%的可用性。

            这几年我们对它所做的管理工作无非就是硬件的升级、数据库的升级（从H2升级到Mysql）、磁盘的SSD化，当然最终也实现了100%的云化。自建git系统还有gitea、gogs等方案，也是非常不错的方案。

            在互娱Git和SVN不是互斥的，而是相互配合的，并且两者配合得非常好，代码放在Git上，美术资源和策划案放在SVN上，打包流程会把两者很自然得串起来，最终实现研发效能的提升，而且项目组中的每个角色都仍旧能选择自己最熟悉和最顺手的工具链来工作，这也是非常非常重要的一环。

P4D-丝滑如初

            在过2018年的春节之前的几天，有一个新项目的同学提出需要我们帮忙创建一套P4D系统来作为他们项目的代码和资源管理，我才第一次听说这个产品。问了一些朋友和来自猪场、鹅场的同事，我才知道这个产品在游戏大厂中是非常流行的而且是必需品。于是过年的那几天，我花了点闲暇时间查阅了Perforce的官网和安装指南等材料后，开始了它的构建工作。它的构建非常简单和快速，30分钟就足够了，但是要管理好它却是需要一定的门槛的。openldap是yyds，我们很简单的就用openldap接入了P4D的认证，又一次实现了用户认证的统一。

                后面的故事就是，从这个项目开始使用P4D之后，项目和美术中台的大量美术资源、二进制资源都以P4D作为版本管理的标配了，P4D的最大优势就是不会因为资源规模的增长导致性能的降低（官网介绍说是用了BTree，BTree是啥 :)），它现在仍旧如我第一天创建它的时候那么丝滑。是的，最终我们也把它实现了SSD化和云化。

                时至今日P4D仍旧是最让我省心的一个系统，它也是我们另外一个实现了99.99%可用性的系统，我还保持着偶尔去翻阅官网的管理员文档的习惯（ https://www.perforce.com/manuals/p4sag/Content/P4SAG/Home-p4sag.html ），在下不小心成为了全互娱（甚至全集团）最懂P4D的屌丝，也可能是全司唯一一个对P4D感兴趣的人（自吹）。Perforce官网文档是优秀文档的典范，你按着它来仔细查阅、理解、实践，相信你也能成为一个优秀的P4D管理员。

结语

            SVN、Git、P4D，无论是哪个产品，在一个有着优秀版本管理理念和流程管理理念的企业内部，都是能找到它的最合适的应用场景的，这三者的特点和发展也让我从另外一个角度认识了游戏行业的发展朝向，与各位共勉，谢谢。

转发请注明出处：肥龙的小札 （ https://thislinux.com ）