版本管理工具
源代码管理工具（笔者更常使用版本管理工具这个名字）中，比较常用的主要有：VSS、ClearCase、CVS、SVN、Git 和 Mercurial。有选择就有比较，网上有很多大有你死我活的争论，而争论的焦点通常都是SVN和Git，从这也能看出这两者的江湖地位。
笔者最早开发使用的IDE是VC++6，到后来VisualStudio，都是使用的VSS，VSS是M$出品，与VS等M$家族产品组合得很好。而从微软阵营转Linux阵营后，包括在华为参与开发FusionSphere云操作系统期间以及目前所在公司都是使用的SVN，而我自己做的一些toy型项目则是使用git (我的github: https://github.com/cucmeliu，欢迎互粉^V^)。其实SVN/Git的争论对多数人来说是没太大意义的，基本上你所在公司要求使用什么你也做不到一支独(Qi)秀(Pa)。
笔者觉得，当前阶段对于公司的产品开发，除非是开源项目，否则SVN还是首选，毕竟git的权限控制天生不足，没有哪个老板愿意让每个人都拥有整个项目的代码。而git的超牛逼的分支能力，用得不好将思路碎片化不说，学习成本也是很高的。
Windows下SVN 服务端推荐 VisualSVN（https://www.visualsvn.com）；
Linux下SVN 服务端推荐SubVersion（http://subversion.apache.org/）；
客户端用得最多的应该非TortoiseSVN莫属（https://tortoisesvn.net/）。
目录结构最佳实践
SVN本质上是一款版本管理工具，因此只要涉及版本迭代性质的任务，都可以考虑它，比如笔者的文档工作目录就是采用在本机搭建SVN来管理的，这样所有文档的更新记录一目了然。
在实际产品开发中，也建议项目的代码和文档都使用SVN来管理，这样的一个好处是有新成员加入团队时，相应的代码、文档及更新记录都很清晰，有利于新成员快速整体了解项目。
新建一个SVN项目的第一步就是要确定目录结构，目录结构可以根据自己的爱好或习惯来创建。如果你使用的是Visual SVN Server做服务端，那你应该知道其提供的两种初始化目录结构：空仓库 和 单项目仓库。空仓库即没有任何目录，可以自行创建，单项目仓库自动创建下图所示的三个顶层目录。当然不管哪种仓库，创建完成后都是可以添加、删除或修改的。
Visual SVN Server初始化的单项目目录结构
笔者对自己所在团队SVN路径的要求如下：
/trunk 主开发目录。我们的所有的开发都是基于trunk进行开发。Trunk目录下存放项目包，项目包下包括db/存放数据库DDL脚本，script/目录存在shell等配套脚本。
/tags 存档目录。一个版本开发告一段落（开发、测试、文档、打包等）结束后，项目经理基于当前冻结的代码库，打tag。
/branches 分支开发目录。当已发行版本（即已Tag版本）有一些bug，或者一些很急迫的功能要求，基于发行版对应的tag，做相应的分支（branch）进行开发。
/docs 概要设计文档和详细设计文档。
笔者所在团队的SVN目录结构
说明：
由于笔者现所在团队产品开发迭代较快，文档变动不大，所以单独出一个顶层文档（docs）目录。对于版本发布概念较强的项目，可以把文档docs目录放在trunk中，以便新建分支或打Tags时文档与代码版本保持一致。
版本分支最佳实践
SVN分支策略通常有两种：
分支稳定，即主干作为新功能开发主线，分支用作发布。
主干稳定，即分支用作新功能开发，主干作为稳定版的发布；
(1) 分支稳定分支策略
开发者每天提交当天编写的所有新特性、Bug修正等代码到主干/trunk。
在每轮迭代结束时，在/branches中创建一个版本分支，基于此分支进行测试和验收。
测试的Bug提到此版本上，由开发人员进行修改。
到此分支Bug收敛到可发布状态，则对其打Tag，版本处于可发布状态，同时，将此分支的修改合并到/trunk
分支稳定策略
(2) 主干稳定分支策略
在这种分支策略下，主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标记而不是分支。分支上的开发和测试完毕以后才合并到主干。（主干稳定是Git的主打分支策略）
主干稳定策略（git推荐方式）
分支稳定和主干稳定两种分支策略各有优缺点，孰优孰劣的争执也长期存在，个人觉得相对来说，分支稳定方式更可控，所以笔者所在团队采用分支稳定。
写在后面的话
SVN应该是IT开发人员必备工具之一，其客户端的基本操作比较简单，实际项目中的难点之一是确保开发人员每天提交的都通过本地单元测试通过的合格代码（其实我觉得这也是一个合格开发人员的道[良]德[心]底线）。
------------------我是分隔线--------I am a Line------------------
附1：推荐阅读：版本控制工具历史的10个里程碑：
https://www.flourish.org/2011/12/astonishments-ten-in-the-history-of-version-control/
附2：版本管理器的进化图
（From: http://codicesoftware.blogspot.com/2010/11/version-control-timeline.html ）
这张图上分成了四个时期：
史前时期：1982年的RCS。现在你可能还能在Unix的发布包中找到它。
古典时期：1990年的CVS（经典的SCM管理器，可惜不能track目录和文件名的改变，今天这个东西已经过时了），1985年的PVCS，1992年的clearcase（价格贵，功能复杂，当然，今天也有很多公司在用），微软的VSS（Welcome to Hell），90年代中期的Perforce(P4，这个工具今天都还在被广泛地使用，尤其是那些中等大小却有着大量开发团队的公司，现在是Google内部最大的代码管理器)。
中世纪时期：SVN（Linus很不喜欢SVN，2006年引入了Git），AccuRev(强力支持branch和merge，其扮演了一个很重要角色帮助社区脱离clearcase和CVS)，
文艺复兴时期：BitKeeper——Sun的内部管理工具，Linux的内核代码2002年也用这个工具，其实，很多开源工程都在用这个工具，2005年这个工具的东家BitMover对大家对BitKeeper逆向工程很不满，于是停止支持开源，于是出现了Git。