项目管理工具SVN
1.SVN介绍
1.1项目管理中的版本控制问题
软件研发过程中，任意一个项目都是由一个团队完成的，而不能依靠单一个体完成。在团队开发过程中，资料数据的共享与同步将成为开发过程中比较突出的问题。
1.2原始开发管理模式（COPY模式）缺点：
①代码管理混乱；
②备份多个版本，占用磁盘空间大；
③解决代码冲突困难；
④容易引发BUG；
⑤难于追溯问题代码的修改人和修改时间；
⑥难于恢复至以前正确版本；
⑦无法进行权限控制；
⑧项目版本发布困难；
为保障团队开发过程中人员沟通各方面成本的降低，必须使用一种有效的方式减少沟通环节，提高开发效率，对资源的共享进行管理。
1.3现阶段的开发管理模式（Tools模式）相关概念：
1.4作为一个管理共享资源的工具必须具备以下几点：
①能够记录日常事务中所有的文件的新建，编译，删除；
②能够记录文件的操作人，操作时间，操作描述信息；
③对于同一个文件，能够提供更多的历史版本供适用者参考；
④对于不同的文件，能够提供更高的管理权限，限制用户的使用能力；
⑤对于不同的项目/Case，能够提供更多的空间管理模式；
对于不同的用户，提供远端访问支持，使用户更快捷进行资源共享。通常软件开发由多人协作开发，如果对代码文件、配置文件、文档等没有进行版本控制，将会出现很多问题：
①备份多个版本，占用磁盘空间大；
②解决代码冲突困难；
③容易引发BUG；
④难于追溯问题代码的修改人和修改时间；
⑤难于恢复至以前正确版本；
⑥无法进行权限控制；
⑦项目版本发布困难；
2.什么是版本控制
版本控制(Revisioncontrol)是维护工程蓝图的标准做法，能追踪工程蓝图从诞生到定案的过程。是一种记录多个文件内容变化，以便将来查阅特定版本修订情况的系统。
版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。
具体来说，在每一项开发任务中，都需要首先设定开发基线，确定各个配置项的开发初始版本，在开发过程中，开发人员基于开发基线的版本，开发出所需的目标版本。当发生需求变更时，通过对变更的评估，确定变更的影响范围，对被影响的配置项的版本进行修改，根据变更的性质使配置项的版本树继续延伸或产生新的分支，形成新的目标版本，而对于不受变更影响的配置项则不应发产生变动。同时，应能够将变更所产生的对版本的影响进行记录和跟踪。必要时还可以回退到以前的版本。例如当开发需求或需求变更被取消时，就需要有能力将版本回退到开发基线版本。在曾经出现过的季度升级包拆包和重新组包的过程中，其实就是将部分配置项的版本回退到开发基线，将对应不同需求的不同分支重新组合归并，形成新的升级包版本。
版本控制是软件配置管理的核心功能。所有置于配置库中的元素都应自动予以版本的标识，并保证版本命名的唯一性。版本在生成过程中，自动依照设定的使用模型自动分支、演进。除了系统自动记录的版本信息以外，为了配合软件开发流程的各个阶段。还需要定义、收集一些元数据来记录版本的辅助信息和规范开发流程，并为今后对软件过程的度量做好准备。当然如果选用的工具支持，这些辅助数据将能直接统计出过程数据，从而方便软件过程改进活动的进行。对于配置库中的各个基线控制项，应该根据其基线的位置和状态来设置相应的访问权限。一般来说，对于基线版本之前的各个版本都应处于被锁定的状态，如需要对它们进行变更，则应按照变更控制的流程来进行操作。
3.SVN是什么
SVN（Subversion）是近年来崛起的版本管理工具，在当前的开源项目里(J2EE)，几乎95%以上的项目都用到了SVN。Subversion项目的初衷是为了替换当年开源社区最为流行的版本控制软件CVS，在CVS的功能的基础上有很多的提升同时也能较好的解决CVS系统的一些不足。
SVN(subversion)是近年来崛起的版本管理工具，是cvs的接班人。目前，绝大多数开源软件都使用SVN作为代码版本管理软件。不要狭义的理解只服务于软件研发，很多公司都适用SVN管理整个公司的文档。
4.SVN的作用
针对软件研发企业的软件生产过程而言，SVN用于管理整个开发过程中的源码，进行版本控制。
5.主流版本控制工具
VSS：VisualSourceSafe(MicrosoftVisualStudio成员)主要任务是负责项目文件的管理。
CVS：ConcurrentVersionsSystem，march-hare出品的一套用于进行文件版本控制软件。
SVN：Subversion，Apache软件基金会名下的一套用于进行文件版本控制软件。
在2000年初，开发人员要写一个CVS的自由软件代替品，它保留CVS的基本思想，但没有它的错误和局限，保留CVS的基本特性但去除CVS的bug和不好的特性。
在2000年2月，他们联系《使用CVS开发开源项目》（OpenSourceDevelopmentwithCVS）(Coriolis,1999)的作者KarlFogel，并征求了他是否愿意在这个新的项目中担任一个角色。巧合的是，当时Karl已经和他的朋友JimBlandy讨论了一个关于新的版本控制系统的设计。在1995年，这两人就成立了CyclicSoftware，一个提供CVS的商业支持的软件公司。虽然他们经营商业服务，但是仍然在每天都在工作中使用CVS。使用CVS的挫折感使得Jim认真思考更好的方法来管理数据，不但确定名字为“Subversion”，而且完成了Subversion档案库的基础设计。
当CollabNet的电话到来时，Karl立即答应了加入项目中，而且Jim让他的雇主RedHatSoftware同意让他在这个项目中不定期工作。CollabNet雇用了Karl和BenCollins-Sussman，并在5月开始了详细设计工作。在得到了来自CollabNet的BrianBehlendorf、JasonRobbins和GregStein（当时是一名活跃在WebDAV/DeltaV规范过程的自由程序员）很多创意的帮助下，Subversion很快地引起了一个活跃开发者社区的注意。它找出并欢迎很多同样在CVS上受到挫折的社员能来为这个项目做点什么。
Subversion最初的设计Team定下了几个简单的目标。它必须在功能上可取代CVS，也就是说,所有CVS可做到的事,它都要能够作到。在修正最明显的瑕疵的同时,还要保留相同的开发模式。还有,Subversion应该要和CVS很相像,任何CVS使用者只要花费少许的力气,就可以很快地上手。
经过十四个月的编码后,Subversion于2001年8月31日开始实现“自行管理”。也就是说,开发人员不再使用CVS来管理Subversion的代码,而以Subversion自己来管理。
2009年11月，Subversion被ApacheIncubator专案所接收。
2010年1月，正式成为Apache软件基金会的一个顶级专案，所以为ApacheSubversion。
6.SVN体系结构图