集中式版本控制系统：从svn到tfs

06年进公司的时候，我们没有使用版本控制系统，所有代码都在部门经理的电脑上放着，谁要改什么代码就过去要一份最新的，改好之后再放回去，感觉好原始。据说之前是用过一段时间微软的vss（visual.source.forge），曾经也搭建过vss服务器，但是中间不知道什么原因中断了，也就没有继续坚持了，可能是当时人还少，整个软件研发也就是10个人左右。所以没有使用版本控制也没有出什么大问题。

进公司之前，由于在matin fowler的《重构》中有提到版本控制系统，我就在自己电脑上搭建一个cvs服务器玩，完成一个小功能就提交一次，写好log，写错了再撤销回来，切实感觉到了有版本控制系统的好处，他就像是一个时光机器，可以让我回到之前的任何一个时间点。我再也不用不断的使用winrar压缩来做备份了。

所以在进公司半年，在摸清了部门的运转机制之后，就向领导提出提出希望可以引入版本控制系统。然后领导就同意了（没想到这么顺利），然后就是版本控制系统的选择问题，比如是继续使用当年的vss，还是寻找开源替代品，比如cvs或者其他的什么，现在已经不记得当年是如何选择的，不过我自己在使用cvs的时候确实是有一些不愉快的经历，库文件损坏。最终选择了svn，那会svn已经出来五年多了（2007），已经是比较稳定了，而且除了命令行，已经有各种插件/图形化工具可以使用。比如我们就使用visutal svn来搭建服务器，而使用tortoiseSVN来做客户端，然后再使用Visual SVN提供的vs的插件来解决和vs集成的问题，基本上整个流程就跑通了。然后就是组织培训，在组织内宣贯，这样前后大概过了一个季度，才陆续的将以前的代码迁移到svn服务器上。

在搭建服务器的过程中，一个比较明知的决定就是使用与服务器来同一用户管理，这样就可以同一svn和ftp两套系统的用户管理。visualSVN本身不支持域用户，所以需要另外搞个插件来做域用户与svn用户的映射，具体是什么有点不记得了。

这样服务器跑起来之后，稳定使用了三年多，随着公司的扩张，部门的人越来越多，新项目也越来越多，这时候问题就出来了，由于代码权限的问题，之前一直都是由部门经历兼职做配置管理员，由他负责svn的项目库创建，权限的分配等，现在有八九十号人的权限需要管理，差不多每天都有人需要申请svn的权限：创建项目库/分配老代码的读权限/写权限，等等。这样会占用他较多的时间，让一个部门经理来配置管理员的工作确实是有点浪费。

这个问题的核心在于svn不支持分级授权：比如如果给一个目录或者库指定了一个管理员，然后就可以由这个管理员来管理该库下面的所有目录的权限。

如果能够支持分级授权，那么部门经理的管理工作就会少很多，他只要负责创建库，然后分配管理员，其他的事情都可以由管理员来完成，这样就会比较理想。所以我们就开始重新寻找新的替代品。最终选择的是微软的TFS。之所以选择TFS一方面也是因为我们原来的那个bug管理系统不好用，也迫切希望能有一个新的替代品，而TFS是一个一体化的解决方案，可以在上面做版本控制，登记缺陷，做项目计划，发布会议通知，组织评审等，而且每个项目还可以有的门户。确实功能比较强大，然后，刚好他的版本控制系统有分级授权的功能。这就圆满了。

当然，搭建tfs服务器是一个比较麻烦的事情，这点去网上找相关文章吧，这里就不细说了，总之用微软一般就用全套，从他的服务器到数据库服务器到sharepoint到tfs服务器。

切换过去这两三年使用起来也还算平稳，没出什么大乱子。

另外提一下，不管是svn还是tfs，这种集中式的版本控制系统有一个问题，服务器如果挂了，大家就没法工作了，特别是我们是公司是两个中心模式，两个研发中心通过vpn相连，如果偶尔网络不好，那么另外一个研发中心的同事基本上就很多事都干不成了。这种问题对于中央式仓库没有什么很好的方法。而且目前网络中断的情况没有经常发生，所以也就没有成为内部主要矛盾。