SVN 版本控制

SCM 软件版本控制管理，常用工具：CVS,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、人为沟通。

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的按文件重复存储）。

在基础篇中我们大概讲了一下如何使用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、通知负责这部分的同事，让他改，自己只更新。这样做，可以很好的避免冲突的发生，提高合作的效率。


http://blog.csdn.net/annkey123/article/details/8161270