Subversion/Cvs

subversion/cvs (by hanlray(at)gmail.com)

repository

repository就是svn/cvs服务器端的一个目录，存放着各种versioned的文件。cvs只对repository中的文件进行版本化管理，svn对其中的目录也进行版本化管理。

server端提供一种或多种访问repository的方式，client端通过相应的URL访问repository：

对svn：

DAV

URL由svn的apache模块mod_dav_svn的配置来决定

SVN

URL由提供这种访问服务的svnserve程序的配置决定

LOCAL

对Local方式就直接写本地目录名了

 

要访问repository中的文件/目录，cvs需要在命令行先用-d指定repository的URL，然后再指定该repository中文件/目录的路径，如：

cvs -d :pserver:anoncvs@keithp.com:/local/src/CVS co nickle

而svn则只需要一个URL：

svn http://keithp.com:/local/src/CVS/nickle co xxx

svn通过svndadmin命令来创建、维护repository

working copy

working copy是repository中一个目录的本地拷贝，对文档的更新和提交等操作都是通过它来进行的。

通过checkout命令创建working copy；cvs不能直接控制创建的working copy目录的名字，其名字就是repository中的module的名字，而svn带了一个参数来指定working copy名。

识别一个目录是否是一个working copy很简单，看这个目录下是否有.svn/CVS的目录即可，.svn/CVS目录存放着meta数据，描述该working copy目录包含的versioned文件和目录的信息。

用svn info来查看该working copy的信息，比如其对应的远程目录的URL

checkout

基本的checkout命令创建repository中一个目录的working copy，因此带有两个参数：一个是远程目录的URL，一个是其working copy的本地路径。

• svn co http://site.com/calc calc 在当前目录下建立了一个calc目录，为http://site.com/calc目录的working copy

   

• 不能这样写 svn co http://site.com/abc.txt . 因为checkout是针对目录的，不能是文件
• 如果忽略第二个参数，将会用URL指定的目录的basename作为working copy的目录名建立在当前目录下，即svn co http://site.com/cal等价于svn co http://site.com/cacl cacl

• 删除文件

  删除文件要通过svn delete来进行，这个命令一方面从working copy所在的文件系统中删除文件，另一方面在本地的svn记录下这个变化，之后当submit时把这个变化提交到仓库，从而删除仓库中的文件。如果仅仅从文件系统中删除，svn会认为该文件仍然在仓库中，只是本地的working copy "missing"了这个文件，当下次update的时候它还会把它从仓库中取到本地。解决方法很简单，用update再取回该文件，用delete删除，再submit。但当你误用delete删掉了一个文件,甚至是一个目录怎么办?如果还没有commit,最简单的办法就是svn revert，它会把自从上次update后所做的改变撤销。

  svn:externals

  如果目录shared是一个共享资源，projec1和project2都需要在其子目录下引用这个shared目录，即project1和project2的working copy类似下面的形式：

  project1   shared   ... project2   shared 

  你会在repository中怎么组织这三个资源shared、project1、project2呢？可以把shared放在project1下，然后利用svn的copy功能把project1的shared目录copy到project2里，虽然svn的copy是一种lazy copy，并不会占用很多空间，但是这样得到的两个shared目录是独立的，是单独变化的，并不是我们期望的只有一份的共享的目录；还可以把shared目录从project1和project2中拿出来单独放在一个地方，当client建立了project1和project2的working copy后再在project1和project2目录下分别建立shared目录的working copy，这样虽然可以达到期望的效果，但是给clients增加了负担，因为每个client都要额外做一个操作此能建立完整的project目录。

  比较ideal的方法是利用svn:external这个属性。针对这个例子，可以把shared目录单独放在一个地方，假设为http://site.org/shared ，然后在client端建立project1和project2的working copy，修改project1和project2的属性svn:externals为：

  svn propset svn:externals "shared http://site.org/shared" project1 svn propset svn:externals "shared http://site.org/shared" project2 

  然后commit再update后project1和project2就会包含shared目录了。

   

  svn:externals属性的值是有限制的：外部定义的url只能指向目录，不能是文件，且必须是绝对路径；working copy的目录名必须是相对目录，且不能为.和..

  svn的property还是挺有用的，它可以应用在任何一个versioned的资源上（这里应用到了project1和project2上），它是meta数据的一部分，而svn的meta数据和普通的versioned的资源一样，也是通过commit和update来维护的，当update一个目录时，client首先会更新其meta数据，针对svn:externals属性，它会根据其属性值更新引用的资源，这里会发现project1和project2的working copy下没有shared目录，因此会从对应的URL建立shared的working copy。