目录：

零基础学习SVN之（一）：SCM与SVN的使用（基础篇）

零基础学习SVN之（二）：CVS与SVN的区别

零基础学习SVN之（三）：可视化SVN的使用

零基础学习SVN之（一）：SCM与SVN的使用（基础篇）

今天用了一点时间看了看SVN的视频，发现很多东西还是要学习基础的，之前虽说在用SVN，但今天看完视频之后还是收获很大。

要学习SVN，首先得知道SCM（Software Configuration Mangement）软件版本控制管理。我们大家都知道，一款软件从开始着手到完成发布，中间一定有很多不同的版本，那么如何管理好这些版本呢？作为SCM的一个工具，SVN给我们提供了很好的解决办法。

SCM要解决的问题：

1. 如何把大家的代码合并的一起。
2. 多平台的支持。
3. 版本之间的不同

SCM的核心功能：版本控制（version control）

SCM常用工具：

• CVS
• SVN
• VSS
• Clearcase
• Teamware

学习SCM重点在学习SVN，下面我们来说说SVN的使用方法

SVN分客户端和服务器端。

服务器：

服务器的建立：分三步

第一步：建立核心仓库，respository

Cmd控制台：Svnadmin+create +名称

第二步：设置权限：svnserver，password中的名字和密码

第三步：启动服务器：svnserve -d-r+目录名称/相对路径。

注意：这种方法控制台窗口不能关，否则服务器就会关闭。

服务器的两种运行方式：1、svnserve 2、apache http

客户端常用功能：

下载/更新：Update / CheckOut 即从仓库中取出内容。

上传/提交：Commit / CheckIn 即把内容放入仓库。

SVN主要是团队合作以及多人异地开发时使用，这样就有一个同时进行的问题存在，就会产生某些冲突。SVN是如何处理冲突的？

通常采用三种方法：

1. 把远程的文件更新到最新到本地，再重新添加你的修改。
2. 放弃你的修改，把远程的更新到你这，用最新的。
3. 人为沟通。

下面是我视频学习的笔记总结，以备快速复习

零基础学习SVN之（二）：CVS与SVN的区别

相信大家看了零基础学习SVN之（一）：SCM与SVN的使用（基础篇）这篇博客之后，对版本控制就有了一定的理解，同时也应该知道SVN与CVS是比较流行的两款SCM工具。那么到底这两款工具有什么区别呢？

1、版本编号方面

例如，我们的版本库为A，其中有文件a,b,c。

在SVN中，新版本的版本号不是针对某个特定文件的，而是针对整个库而言的。提交了5次和提交了6次，文件a有可能不同，也有可能相同，即1.0版和1.1版可能相同。因为第6次提交有可能是因为文件b或c进行了修改。而在CVS中则相反，每次更新可能只对文件的版本号进行修改，即a文件的1.0版和1.1版是肯定不同。

（在这里纠正一个概念，“文件a的第2版本”这个说法是错误的，应该是“文件a的第2次修改，即第二次Commit”）

SVN的全局性版本编号为SVN带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，SVN不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。

2、目录的版本控制

CVS只能对文件进行版本控制，不能对目录进行版本控制，这就导致CVS失去了很多功能：

1、没有移动操作

CVS里没有移动（move）这个操作，当人为进行文件移动操作时，CVS只能注意到，一个文件在一个位置被删除了，而在一 个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。所以使用CVS时，每个文件的位置一定要谨慎的选择。

2、没有重命名操作

CVS里没有重命名（rename）这个操作，人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。

3、没有拷贝操作

CVS中没有拷贝（copy）这个操作，人为的拷贝对CVS而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。

而SVN从很大程度上避免了这些不足，SVN将目录作为一类特殊的文件来处理。当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变。因此，SVN象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，SVN能够准确记录操作前后的历史联系。同样，像对文件的不同历史版本进行比较一样，SVN支持对目录的不同历史版本的比较，清晰展现目录的变化历史。

3、原子性提交

CVS和SVN同样作为SCM版本控制管理工具，SVN的原子性提交可谓是技高一筹啊！

SVN提交文件，只有当全部文件修改都成功入库，该提交才变得有效。一旦中断，SVN将会自动执行“回滚”（rollback）操作。SVN 这种机制保证所有的修改要么全部入库生效，要么一个也不入库。由于SVN的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS的按文件重复存储）。

而CVS则采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中。但当任何原因造成批量操作的中断时，版本库往往处于一个不一致的状态。另外，CVS即使在批量提交不发生中断时也会造成不一致：假设用户A启动一个需要较长时间才能完成的批量提交；与此同时，用户B执行cvsupdate操作。此时，用户B很有可能得到一个不一致的更新，即用户B通过“更新”操作，得到用户A的部分修改文件。

4、变更集概念的支持

由于SVN提交是原子性的，每次成功提交形成的唯一的全局版本号对应此次批量提交的所有文件修改，也就是说，一个SVN版本号其实对应了一个逻辑上的变更集，该变更集可能对应于对一个BUG的修复，或者对应于对一个已有功能的改进，或者对应于一个新功能的实现。可以说，变更集是一个软件开发活动的逻辑结果，该变更集可以通过其对应的版本号在软件开发的其他过程中（如软件合并/集成过程，软件发布管理，变更管理系统，缺陷追踪系统）被引用。因此，SVN将版本管理从单纯的、单个的文件修改的层次通过逻辑上的抽象，上升到更便于理解和交流的开发活动的层次。

5、、差异化的二进制文件处理

CVS最初设计是为处理文本文件（或ASCII文件，源代码文件），对文本文件进行差异化的存储、新旧版本的比较，文件合并等。但对于二进制文件，CVS则明显力不从心。在CVS的版本库中，对于二进制文件的历史版本，CVS是对不同的版本进行独立的、冗余的存储，哪怕版本之间其实只存在微小的差异。与CVS不同，SVN每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。更为重要的是，当客户端需要获取新的版本时，SVN只传输版本的差异，从而大大减少对网络带宽的消耗。

说了这么多，好像全是在说SVN得优点，其实它也不是那么完美。下面来分析一下SVN的一些不足之处。

1、对中文路径名的支持

cvs：支持的比较好

svn：要将权限控制文件保存为svn支持的UTF-8格式

2、本地文件与库的对应关系

cvs：可以多对多

svn：一个库可以有多个工作目录，但一个工作目录只能对应一个库，虽然可以更改库位置但是要求很严格

3、库中文件存放方式

cvs：完全用户可见方式与客户端文件夹结构完全一直（cvs生成文件除外）

svn：看不到文件真正的内容

零基础学习SVN之（三）：可视化SVN的使用

在之前的博客中我简单给大家介绍了SVN的基础知识以及与CVS的区别。通过上两篇文章，我想大家已经意识到，SVN是有很多CVS所不具备的特点。而且，现在大多数人的观点是CVS将被SVN所代替。

在基础篇中我们大概讲了一下如何使用SVN，但大多数是在非可视化的条件下操作的，这对我们大多数同学来说，这是由一定难度的。有了不舒服的地方，肯定就有好的代替方法。今天给大家介绍一下可视化SVN的使用。

VisualSVN是VisualStudio的一个插件,通过Visual SVN 我们可以在VS中对SVN代码进行管理，在项目资源管理器重右键相应的项目或类，可以看到Update(更新) 和Commit（提交），在这里就可以完成相应的任务。

VisualSVNServer是服务端，可视化的。我们可以看到服务器中的文件。

大家只要知道他们一个是客户端，一个是服务器端即可。下面介绍使用方法。

安装就不介绍了，一路Next安装。

我们上面说了VisualSVN是VS的一个插件，所以我们当然要在VS中找他啦！

而服务端在我们的开始菜单中可以找到。

我们首先打开服务端，我们来认识一下它：

首先是库，我们在前面的文章已经介绍了。然后用户，就是给使用这个库的人注册一下。组呢，现在还没用到，是针对大型项目时把不同的小组的人分出来用的。其实，无论是用户还是组，都是为了让特定的人有特定的权限去访问或修改库中的某个文件。

下面就是建库：

右键可以看到有Create New Repository，点击建库。输入库名，OK。库就算基本建成功啦！怎么样？比上次介绍的方法简单多了吧。

库建立好了，下面来添加用户：

同样的步骤，Users右键Create New User。输入用户名和密码。即可添加成功。

库也建好了，用户也添加了，是不是我们的任务就完成了呢？重要的还没说，权限！

权限就好像是一种证件，你只能做你权限内的事情，否则岂不乱套啦？试想，我们合作开发，每个人都可以提交的话，本来这部分是我做的东西，结果你不小心给我改了，而且提交到了服务器，那我们两个的东西不就起了冲突了吗？

所以，在建立用户的时候要根据用户的具体任务分给他不同的权限。以简单三层为例，test1负责UI层，那么test1的权限只能提交UI层，BLL/DAL他是不能提交的。而更新时对所有用户都开放的。

下面来看看如何配置权限。

首先说明一下，设置权限是某用户对某个库的权限，所以是对库的属性设置。

右键库名，点击属性（Properties）,点击Add把用户添加到该库的属性中。

相信大家都看到他下面的Permissons（权限）了。选中用户选择相应的权限即可。

Read/Write读写权限。

ReadOnly只读权限。

No Access，不允许，即没有权限。

Inherit fromParent,从父母继承。什么意思？这里的parent指的是这个库或者库中的文件的parent,即这个文件属于哪个库，则该用户对该文件的权限继承于该用户对这个库的权限。就是这个用户对这个文件的parent有什么权限对它就有什么权限。

现在对权限这部分特别有感触，开发之前应该要求各用户只能改自己负责部分的代码，其他的之能看，不能改。如果确实需要改，怎么办？1、自己拿出一个备份，去改。2、通知负责这部分的同事，让他改，自己只更新。这样做，可以很好的避免冲突的发生，提高合作的效率。