从CVS到SVN

一、文件版本
通常指软件程序发行的次数版本号，一般文件版本形如 x.x.x，其中第一个X是软件内核的版本，第二个X是发行的正式版本的版本号，第三个X是软件更改修正的次数。
软件版本的类别
1.文件源版本（文件的核心开发版本）
2.文件修改版（其他用户或者产品生产单位更新或者升级的版本）
3.文件破解版（其他用户或者技术组为了自己使用对源文件所做的反编译版本）
4.文件合作版（与其他单位或者院校的合作版本）
5.文件定制版 （特指某个企业为定制版）
6.文件内部版本（仅限生产单位内部使用）
非正式版
α、β、γ称为测试版，大凡成熟软件总会有多个测试版。trial、unregistered、demo有时统称为演示版，这一类版本的广告色彩较浓，颇有点先尝后买的味道。
α版
　　此版本表示该软件仅仅是一个初步完成品，通常只在软件开发者内部交流，也有很少一部分发布给专业测试人员。一般而言，该版本软件的bug较多，最好不要安装。
β（beta）版
　　该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模的发布测试来进一步消除。这一版本通常由软件公司免费发布，用户可从相关的站点下载。通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改。该版本也不适合一般用户安装。
γ版
　　该版本已经相当成熟了，与即将发行的正式版相差无几，如果用户实在等不及了，尽可以装上一试。
trial（试用版）
　　试用版软件通常都有时间限制，过期之后用户如果希望继续使用，一般得交纳一定的费用进行注册或购买。有些试用版软件还在功能上做了一定的限制。
unregistered（未注册版）
　　未注册版与试用版极其类似，只是未注册版通常没有时间限制，在功能上相对于正式版做了一定的限制.
demo版
　　也称为演示版，在非正式版软件中，该版本的知名度最大。demo版仅仅集成了正式版中的几个功能，颇有点像unregistered。不同的是，demo版一般不能通过升级或注册的方法变为正式版。
正式版
• release（最终释放版）
该版本有时也称为标准版。一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号®，如windows nt® 4.0、ms-dos® 6.22等。
• registered （注册版）　　
注册版、release和下面所讲的standard版一样，都是软件的正式版本，只是注册版软件的前身有很大一部分是从网上下载的。
• standard（标准版）　　
不论是什么软件，标准版一定存在。标准版中包含了该软件的基本组件及一些常用功能，可以满足一般用户的需求。其价格相对高一级版本而言还是“平易近人”的。
• deluxe（豪华版）　
豪华版通常是相对于标准版而言的，主要区别是多了几项功能，价格当然会高出一大块，不推荐一般用户购买。此版本通常是为那些追求“完美”的专业用户所准备的。
• reference 　　
该版本型号常见于百科全书中，比较有名的是微软的encarta系列。reference是最高级别，其包含的主题、图像、影片剪辑等相对于standard和deluxe版均有大幅增加，容量由一张光盘猛增至三张光盘，并且加入了很强的交互功能。
professional（专业版）
　　专业版是针对某些特定的开发工具软件而言的。专业版中有许多内容是标准版中所没有的，这些内容对于一个专业的软件开发人员来说是极为重要的。如微软的visual foxpro标准版并不具备编译成可执行文件的功能，这对于一个完整的开发项目而言显然是无法忍受的，若客户机上没有foxpro将不能使用。如果用专业版就没有这个问题了。
enterprise（企业版）
企业版是开发类软件中的极品（相当于百科全书中的reference版）。拥有一套这种版本的软件可以毫无障碍地开发任何级别的应用软件。如著名的visual c++的企业版相对于专业版来说增加了几个附加的特性，如sql调试、扩展的存储过程向导、支持as/400对ole db的访问等。而这一版本的价格也是普通用户无法接受的。
update（升级版）
　　升级版的软件是不能独立使用的，该版本的软件在安装过程中会搜索原有的正式版，如果不存在，则拒绝执行下一步。
oem版
　　oem版通常是捆绑在硬件中而不单独销售的版本。将自己的产品交给别的公司去卖，保留自己的著作权，双方互惠互利，一举两得。
单机（网络）版
　　网络版在功能、结构上远比单机版复杂，如果留心一下软件的报价，你就会发现某些软件单机版和网络版的价格相差非常大，有些网络版甚至多一个客户端口就要加不少钱。
普及版
该版本有时也会被称为共享版。与试用版不同的是，该版本的软件一般不会有时间上的限制。
随着软件市场行为的变化，现在也出现了一些新的版本命名方式，比如windows xp中的xp是取自于experience中的第二、第三个字母。

软件包(SoftWare Package)
具有特定的功能，用来完成特定任务的一个程序或一组程序。可分为应用软件包和系统软件包两大类。应用软件包与特定的应用领域有关，又可分为通用包及专用包两类。通用软件包根据社会的一些共同需求开发，专用软件包则是生产者根据用户的具体需求定制的，可以为适合其特殊需要进行修改或变更。

二、cvs
1，CVS服务器（文件版本库）
　　CVS（Concurrent Versions System）是一个C/S系统，多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。版本控制系统是一种GNU软件包，主要用于在多人开发环境下的源码的维护。Concurrent有并发的、协作的、一致的等含义。实际上CVS可以维护任意文档的开发和使用，而不仅仅局限于程序设计。CVS维护的文件类型可以是文本类型也可以是二进制类型。CVS用Copy-Modify-Merge（拷贝、修改、合并）变化表支持对文件的同时访问和修改。它明确地将源文件的存储和用户的工作空间独立开来，并使其并行操作。CVS基于客户端/服务器的行为使其可容纳多个用户，这一特性使得CVS成为位于不同地点的人同时处理数据文件（特别是程序的源代码）时的首选。 
2，CVS的基本工作思路
　　在一台服务器上建立一个源代码库，库里可以存放许多不同项目的源程序，由源代码库管理员统一管理。每个用户在使用源代码库之前，首先要把源代码库里的项目文件下载到本地，然后用户可以在本地任意修改，最后用CVS命令进行提交，由CVS源代码库统一管理修改。这样，就好像只有一个人在修改文件一样，既避免了冲突，又可以做到跟踪文件变化等。 
　　它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最新的代码。它的无限制的版本管理检出(check out：)的模式避免了通常的因为排它检出模式而引起的人工冲突。它的客户端工具可以在绝大多数的平台上使用。 CVS被应用于流行的开放源码工程中，CVS内建了客户机/服务器存取方法，所以任何一个可以连到因特网上的开发者都可以存取在一台CVS服务器上的文件。
　　在传统的版本控制系统中，一个开发者检出一个文件，修改它，然后将其登记回去。检出文件的开发者拥有对这个文件修改的排它权。并且只有检出那个文件的开发者可以登记(check in：)所做的修改。(当然对于管理员有很多方法可以超越这个限制。)  CVS通过它的无限制的检出模式解决了这个问题。当多个开发者对同一个文件作了修改CVS会检测，并且自动合并那些只要不是对代码的同一行所作的改动。
3，CVS 术语
　　Revision (修订版本)－－文件历史记录中的被开发者提交的变化。一个修订版本就是一个时常变化的项目的 snapshot (瞬态图)。
　　Repository (源代码库)－－CVS 存储所有修订版本历史记录的地方。每个项目都有自己的一个确定的源代码库。
　　Working copy (工作拷贝)－－开发者对文件作出修改时文件所在的拷贝。
　　Check out (检验)－－从源代码库中申请一份工作拷贝。该工作拷贝反映的是取出时项目的瞬时状态。当开发者对拷贝作出修改时，必须运用 commit (提交)和 update (更新) 命令来 “发布”变化和查看其他开发者所作的修改。
　　Commit (提交)－－将工作拷贝中的变化输入中央源代码库。
　　Log message (日志信息)－－提交修订版本的时候，附带描述变化的注解。通过查阅记录信息，人们可以获得一个当前项目进程的总结。
　　Update (更新)－－从源代码库中取出别人的修改数据，将其输入自己的工作拷贝，并显示自己的工作拷贝是否有未提交的修改。注意，不要和 commit (提交)混淆，更新和提交是一对互补的指令。记住： Update 将使工作拷贝和源代码库拷贝保持同步更新。
　　Conflicts (冲突)－－两个开发者对同一个区域所做的改动都提交给主版本时出现的情况，在 CVS 觉察并指出这个冲突后，开发者必须解决该冲突。
4，日常使用
　　注意：第一次导出以后，就不是通过cvs checkout来同步文件了，而是要进入刚才cvs checkout project_name导出的project_name目录下进行具体文件的版本同步（添加，修改，删除）操作。
　　将文件同步到最新的版本cvs update 养成“先同步，后修改”的习惯， CVS里没有文件锁定的概念，所有的冲突是在commit之前解决，如果你修改过程中，有其他人修改并commit到了CVS 库中，CVS会通知你文件冲突，并自动将冲突部分用
　　>>>>>>
　　content on cvs server
　　<<<<<<
　　content in your file
　　>>>>>>
标记出来，由你确认冲突内容的取舍。版本冲突一般是在多个人修改一个文件造成的，但这种项目管理上的问题不应该指望由CVS来解决。
注意：CVS的很多动作都是通过cvs commit进行最后确认并修改的，最好每次只修改一个文件。在确认的前，还需要用户填写修改注释，以帮助其他开发人员了解修改的原因。修改某个版本注释：每次只确认一个文件到CVS库里是一个很好的习惯。

二、SVN与CVS优缺点
1，存储类型格式
CVS是个基于RCS文件的版本控制系统。每个CVS文件都是普通的文件，加上一些额外信息。这些文件会简单的重复本地文件的树结构。因此，不必担心有什么数据损失，如果必要的话可以手工修改RCS文件。
　　SVN是基于关系数据库的(BerkleyDB)或一系列二进制文件的(FS_FS)。一方面这解决了许多问题 (如:并行读写共享文件)以及添加了许多新功能(如：运行时的事务特性)。然而另一方面，数据存储由此变得不透明。
2，速度　 
　　整体而言,由于架构实现的不同, SVN的确比CVS快很多,在网络上它只传输很少的信息并支持更多的离线模式的功能。速度的代价就是巨大的存储（完全备份所有的工作文件）。
3，标志&分支　
　　SVN采用标志和分支,在档案库内部复制文件或目录以便保存日志。SVN里整个仓库都有版本号，但不是针对单个文件。
4， 元数据　
　　CVS只允许存储文件。SVN允许一个文件有任意多的可命名属性，功能十分完全。
5，文件类型　
　　CVS是为文本文件存储而设计的。SVN支持所有的文件类型。
6，回滚　
　　CVS允许任意的回滚，在任意一个已递交的版本上，尽管这要花些时间（所有的文件都要分别处理）。　
　　SVN不允许递交后回滚。建议把版本库里好的状态版本加到末尾，覆盖掉损坏的版本。而损坏的版本无论如何也是会存在数据库里的。（SVN的滚回操作实际上是merge操作）
7，事务　
　　CVS中的“零或一”事务原则根本没有实现。如果检入几个文件的话（加到服务器上），很有可能部分文件完成了，而另几个没有。作为一个潜规则，手工纠正这些并且对余下的文件 (而不是所有文件)一一重复检入。这样这些文件将在两阶段中被检入。SVN支持“零或一”事务原则，这是SVN的一大优势。
　　
一、SVN（Subversion）概述
1，定义
SVN版本控制系统、代码、文档等管理工具，是cvs的接班人。Subversion 最初的设计Team定下了几个简单的目标：它必须在功能上可取代 CVS，也就是说, 所有 CVS 可做到的事, 它都要能够作到。 在修正最明显的瑕疵的同时, 还要保留相同的开发模式。经过十四个月的编码后, Subversion 于2001年8月31日开始实现 “自行管理”，即开发人员不再使用 CVS 来管理 Subversion 的代码, 而以 Subversion 自己来管理。目前，绝大多数开源软件都使用SVN作为代码版本管理软件。SVN = 版本控制 + 备份服务器。简单的说，您可以把SVN当成您的备份服务器，更好的是，他可以帮您记住每次上传到这个服务器的档案内容，并且自动的赋予每次的变更一个版本。 通常我们称用来存放上传档案的地方就做Repository。用中文来说，有点像是档案仓库的意思，不过，通常我们还是使用Repository这个名词。基本上，第一次我们需要有一个新增(add)档案的动作，将想要备份的档案放到Repository上面。日后，当您有任何修改时，都可以上传到 Repository上面，上传已经存在且修改过的档案就叫做commit，也就是提交修改给SVN server的意思。针对每次的commit，SVN server都会赋予他一个新的版本。同时，也会把每次上传的时间记录下来。日后，如果您需要从Repository下载曾经提交的档案。您可以直接选择取得最新的版本，也可以取得任何一个之前的版本。如果忘记了版本，还是可以靠记忆尝试取得某个日期的版本。

2,版本模型
所有的版本控制系统都需要解决文件共享的问题 ,怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？传统的版本控制系统使用锁定-修改-解锁模型，在这种模型里，在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前，要“锁定”住这个文件，其他人就不能对这个文件做任何修改，在结束编辑并且放开这个锁之前，其他人只可以阅读文件。编辑完解锁后，其他人才可以锁定并且开始编辑这个文件。SVN，CVS和一些版本控制系统使用拷贝-修改-合并模型，在这种模型里，每一个客户联系项目版本库建立一个个人工作拷贝—版本库中文件和目录的本地映射。用户并行工作，修改各自的工作拷贝，最终，各个私有的拷贝合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择。如果修改冲突，可以看到一对冲突的修改集，并手工的选择保留一组修改。

3,为什么要使用SVN
• SVN Repository可以是PC上一个目录或随身碟，也可以是公司的服务器。
• SVN有很棒的版本控管机制。所有上传的版本都会帮您记录下来，日后您可以随时取得某一个时刻的版本，而且也有版本分支及合并等好用的功能。
• SVN可以让不同的开发者存取同样的档案，并且利用SVN Server作为档案同步的机制。也就是说，您有档案更新时，无须将档案寄给您的开发成员。只需要告诉他新的版本已经在SVN Server上面，请他自己去SVN Server上面就可以取得最新版本。而且，SVN Server也可以做到当您上传新版本后，自动发信给相关的成员。
• SVN的存放档案方式是采用差异备份的方式。也就是说，他只会备份有不同的地方。所以很省硬盘空间。此外，他也可以针对所谓的非文字文件进行差异备份。
4，集中式版本管理系统
SVN是一个“集中式”的信息共享系统。版本库是SVN的核心部分，是数据的中央仓库。版本库以典型的文件和目录结构形式文件系统树来保存信息。任意数量的客户端连接到SVN版本库，读取、修改这些文件。客户端通过写数据将信息分享给其他人，通过读取数据获取别人共享的信息。
集中式管理的工作流程如下图：
　　
   
集中式代码管理的核心是服务器，事实上，SVN的版本库的确是一种文件服务器，但不是“一般”的文件服务器。SVN版本库的特别之处在于，它会记录每一次改变：每个文件的改变，甚至是目录树本身的改变，例如文件和目录的添加、删除和重新组织。一般情况下，客户端从版本库中获取的数据是文件系统树中的最新数据。但是客户端也具备查看文件系统树以前任何一个状态的能力。版本控制系统的核心问题,设计用来记录和跟踪数据变化的系统。

二、在Windows下使用Subversion的客户端程序SVN

1，Subversion体系结构
采用了B/S与C/S相结合的方式。B/S结构,通过浏览器访问仓库。C/S结构,安装Tortoise SVN后,访问仓库。
2， 安装SVN时注意
svn服务器有独立服务器和借助apache运行2种运行方式。存储版本数据有BDB(一种事务安全型表类型)和FSFS(一种不需要数据库的存储系统) 两种方式。因为BDB方式在服务器中断时，有可能锁住数据，所以还是FSFS方式更安全一点。下载安装SVN成功后，在档案管理内按下鼠标右键可以看到：
 
大部分的Tortoise SVN的操作都是透过档案管理员及鼠标右键就可以完成了。
假设您的要放置Repository的地方是E盘。您需要先建立一个空的目录（文件夹） svn_repo。SVN没有限定Repository目录名称，您可以建立任何您自己喜欢的名称，建议勿使用非英文的档名。透过您的档案管理员，在E:\svn_repo的图标上，按鼠标右键后，选择TortoiseSVN->Create repository here，如图：
 
使用的Repository数据库格式选择FSFS，直到出现SVN repository成功的建立的提示。接下来就是要把你的档案备份进来。日后，只要需要使用这个repository，我们就可以使用file:///E:/SVN_REPO表示它。SVN就是透过这种URL的方式与Repository取得联系的。各种URL的格式如下：
file:///磁盘驱动器|/repository所在目录/子目录
http://账号@服务器名称/ repository所在目录/子目录
https://账号@服务器名称/ repository所在目录/子目录
svn+ssh://账号@服务器名称/ repository所在目录/子目录
其中，http表示使用一般的超文字传输通讯协议。https表示使用加密的超文字传输通讯协议。svn+ssh表示透过SSH加密通讯的管道，进行存取。
3，建立一个Working目录
所谓的Working目录，就是平常用来存放工作档案的地方。通常我们会等到自己的工作做的一个段落的时候再进行备份。所以我们平常都是在 Working目录下面工作，等到适当时机在commit到repository中。举例来说，我们在D盘下面建立一个名为working的空的文件夹，在档案管理员中按右键，选择SVN checkout，看到如下的画面：
 
首先我们要填入的是repository的位置，对于SVN来说，repository的位置都是URL。Checkout directory这个字段指向您的working目录。确认后按下OK按钮即可。您将会看到working目录下面多了一个名为.svn的目录(这个目录是隐藏的) 。 SVN会在您的工作目录下，以及其子目录下建立这个.svn子目录。注意，不要进去或改动.svn目录下的任何内容，否则会造成SVN无法正常运作。
由于原来的repository是空的，所以working目录也是空的。如果您现在checkout的是一个已经有内容的repository，您将会看到working目录下面现在多了许多目录及档案。如果您要在一个已经存在的SVN Server上面checkout出上面的档案，只需要给定正确的URL以及working目录的名称，就可以取得指定的档案及目录了。
4，新增档案及目录到Repository中
假设您开发的程序将放在前面建立的working目录下面的my_ prj子目录。编辑好档案后，在my_prj目录上面，按鼠标右键，选择TortoiseSVN->Add，如图：
 
接着，TortoiseSVN会把准备要加入的档案及目录，显示给您看。打勾的就是等下要被加入到Repository中的。如果您有某些档案或是目录不想在这次加入，您可以让该项目不要被勾选。如此，它就不会被加入到Repository去。 注意：Add的动作并未真正的将档案放到Repository中。仅仅是告知SVN准备要在Repository中放入这些档案。此时，查看这些档案，应该会看到一个白色红底的惊叹号在档案文件夹的下方，表示您的working目录中的档案与Repository中的档案还没有同步。我们要多一个commit的动作，让这些档案真正的放入到 Repository中。在my_prj目录上或是my_prj目录内的空白处按下鼠标右键，选择SVN commit。如下的窗口出现：
 
在这个窗口中，下半部会列出一个清单，让您清楚的了解到哪些档案要被commit到repository中。如果您有档案不想在这个时候commit到Repository，您可以取消选取的档案。 在档案列表的上方的Message栏里输入本次commit的目的，这是十分重要的字段，当您commit的次数很多时，可以靠这个讯息知道版本与版本之间的差异。到先前的folder中，确定所有的档案图标都有绿色勾勾在上面，这样代表您的档案都正确无误的到repository中。有时候，因为Windows本身的问题，您可能会看到有些图标没有变成绿色的勾勾，多按F5几次，就可以解决这个问题。
NOTE：新增的档案要经过提交(Commit)的动作才回真正的放入Repository中。
5，更新档案及目录
由于版本控制系统多半都是由许多人共同使用，所以同样的档案可能还有人会去进行编辑。为了确保您工作目录中的档案与Repository中的档案是同步的，建议您在编辑前都先进行更新的动作。在想要更新的档案或目录图标上按鼠标右键，并且选择SVN Update。会显示有哪些文件更新了。如果没有看到档案更新的相关信息，这表示您的目录中的档案已经是最新的，无须进行更新。
有时我们需要回溯至特定的日期或是版本，这时就可以利用SVN的Update to revision的功能。在这个Update窗口中，您可以选择更新到最新版本(HEAD)。也可以选择更新到某个指定的版本(Revision)。或按下Show log按钮，回顾历史版本。
 
 
所有您曾经做过的动作，及其日期与对应的版本都会列在这个窗口上面，只要在你想要的版上面点一下，让他变成反白，然后按下OK。这个版本就会自动填入Update窗口中的Revision字段中。您只要再按下一次OK，这个版本就会被取出来到您的硬盘中。
6，Copy/Tag/Branch/Release档案或目录
Branch，要产生一个分支，以区别与trunk不同的开发。 Tag，要形成一个标记，表示重要的milestone。Release，表示一个已经正式的release的纪录。所谓的Tag或Release就是一个特别的版本，因为这个版本可能有特别的意义。Tag与Release的作法与Branch完全相同，只是Branch可能会需要merge回原来的trunk中，而tag及 release大部分都不需要merge回trunk中。基本上，SVN只有目录的概念，并没有什么 Tag的用法。所以您会看到在SVN的选单上面，Branch与Tag是同一个项目。我们在Trunk上面，按鼠标右键，选择Branch/Tag的项目，就在Tag目录下面建立了一个1.0的目录（在Tag目录下面update一下，才能看到它）。 Branch、Tag、Release都只是将指定的 Trunk版本复制一份到另外一个目录去，至于这个目录要叫Branch还是叫Release，SVN根本就不管。所以您也可取其它的目录名称。不过Branch、Tag、Release已经是SVN上面约定成俗的名称。所以除非您知道自己为何这样做，否则最好还是follow这个命名原则，以免后面新加入的人看不懂。同样的道理Trunk也只是一个约定成俗的名称，不一定要叫Trunk。只是大家看到Trunk目录就会知道这里面放的是主要的开发主干。
首先确认您要处理的档案或目录是Repository中最新的版本。在要处理的目录或是档案上按鼠标右键，选择TortoiseSVN->Branch/Tag/Branch/Release,出现如图：
 
其中，From WC at URL:要复制的来源目录，To URL：输入您要复制到的路径。目录不存在时，会由SVN帮您建立（注意：SVN用斜线作为目录分隔字符而非反斜线）。Log message：输入目的即可。在复制到的路径下， SVN update就可以看到这个新增的目录了。
您可以任意对新增的目录Branch进行编辑，一直到您确认好所有在branch下面该做的工作都完成后，您可以选择将这个branch merge回原来的trunk目录，或者是保留它在branch中。 要merge回trunk目录中，我们在D:\working\my_prj\trunk目录空白处，按鼠标右键，选择Merge，看到如下的画面：
 
这个画面主要分为三个部份， From跟To的URL字段指定原来 branch的目录下。剩下的就是指定要merge的revision范围。按下Merge按钮后，将 branch的档案与trunk的档案合并起来。如果您确认这次的merge没有问题，可以直接使用commit来将这两个被修改的档案commit回repository上。如果有问题，您可以直接修改这两个档案，直到确认ok了，再commit。 在To URL处输入您要的目的地。
7，经典的svn工作流程
所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上,如果脱离了服务器，开发者基本上是不可以工作。
　　1）从服务器下载项目组最新代码。
　　2）进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码（很多人都有这个习惯，因为有时自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做）。
　　3）下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。
从流程上看SVN缺点：
　　1）服务器压力太大，数据库容量暴增。
　　2）如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
　　3）不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
从流程上看SVN缺点优点：
　　1)管理方便，逻辑明确，符合一般人思维习惯。
　　2)易于管理，集中式服务器更能保证安全性。
　　3)代码一致性非常高。
4)适合开发人数不多的项目开发。