CVS SVN VSS 使用对比

更多精彩请到 http://www.139ya.com

From : http://www.cnblogs.com/liubiqu/archive/2009/01/05/1369533.html


版本控制系统里团队开发不免要用上CVS SVN VSS ClearCase等工具。至于选择上，则是根据开发团队搭建的平台，使用的编程语言相关联。



如果用.net平台开发，VSS无疑首选，尽管它曾经有不经时事的诟病，现在发展的功能也蛮强的。如果有服务器linux系统，则CVS，SVN都可以选择。现在SVN大有取代CVS之势。然而很多古老的程序员还是对CVS情有独钟。



如下节选一些网上的对比说明，我作以综述。当然，真正要弄懂这些版本控制系统，还是要花费巨大工夫学习研究，不可能在baidu或者google几下就能完成的。



一、Subversion包含绝大部分CVS功能



Subversion 作为CVS 的重写版和改进版，其目标就是作为一个更好的版本控制软件，取代目前流行的CVS。Subversion 的主要开发人员都是业界知名的CVS 专家。Subversion支持绝大部分的CVS 功能/命令；Subversion 的命令风格和界面也与CVS 非常接近。当然，不同的地方正是对CVS 的改进。



二、全局性的版本编号



一个新的版本，并得到一个自增量的版本号N+1，该版本号并不针对某个特定的文件，而是全局性的、针对整个版本库的。因此，我们可以将Subversion 的版本库看作是一个文件系统或文件目录树的数组。



从技术的角度来说，在Subversion 中，"文件foo.c 的第5 版本"这个说法是错误的；正确的说法应该是："文件foo.c 在版本库被修改了5 次，即执行5 次commit 后是什么样子？"。显然，在Subversion 中，版本库被修改5 次后foo.c 的内容，和被修改了6 次后foo.c 的内容很可能完全一样，因为版本库的第6 次修改很可能只修改了版本库的其他部分，而并没有对foo.c 的进行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本总是不同的。



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



三、目录的版本控制



CVS 只能对文件进行版本控制，不能对目录进行版本控制，因此CVS 没有任何关于文件"移动"（move）操作的概念。当人为进行文件移动操作时，CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置 CVS 存储库时，必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，几乎就要一直使用这个位置了。



同样由于CVS 不记录目录的版本历史，CVS 不支持对文件的"重命名"（rename），人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。



还有，CVS 不支持对文件的"拷贝"（copy），人为的拷贝对CVS 而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。



综上所述，缺乏对文件"移动"、"重命名"、"拷贝"的支持的根源在于CVS 不能记录目录的版本历史，而这些操作在当前的软件开发过程中经常发生，这正是Subversion被开发并取代CVS 的主要原因之一。



Subversion 将目录作为一类特殊的文件来处理（事实上，从文件系统的角度来看，目录确实是一类特殊的文件，当目录中的子目录/文件被删除、重命名、或新的子目录/文件被创建时，目录的内容将发生改变）。因此，Subversion 象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，Subversion 能够准确记录操作前后的历史联系。同样，象对文件的不同历史版本进行比较一样，Subversion支持对目录的不同历史版本的比较，清晰展现目录的变化历史。



四、原子性提交



从使用者的角度来看，CVS 和Subversion 都支持对多个文件修改的批量提交，但二者在实现方式上存在本质的区别。



CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。



CVS 串行批量提交模式的弊端在于－当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库，很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update 操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更多的时间进行软件调试和排错。



CVS 即使在批量提交不发生中断时也会造成不一致：假设用户A 启动一个需要较长时间才能完成的批量提交；与此同时，用户B 执行cvs update 操作。此时，用户B 很有可能得到一个不一致的更新，即用户B 通过"更新"操作，得到用户A 的部分修改文件。



Subversion 彻底消除了CVS 的以上弊端。无论批量提交包含多少文件修改，只有当全部文件修改都成功入库，该提交才变得有效，才对其他用户可见；否则，无论任何原因造成中断，Subversion 都会自动执行"回滚"（rollback）操作。换一个说法，Subversion 保证所有的修改要么全部入库生效，要么一个也不入库，即对版本库不作任何的修改。这就是Subversion 的原子性提交（atomic commit）。



由于Subversion 的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS 的按文件重复存储）。



五、支持变更集概念



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



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



由于历史原因，CVS 主要是为早期的程序员设计的，CVS 能够有效处理文本文件（或ASCII文件，源代码文件），可以对文本文件进行差异化的存储、新旧版本的比较，文件合并等；但对于二进制文件，CVS则明显力不从心。在CVS 的版本库中，对于二进制文件的历史版本，CVS 唯一能做的就是对不同的版本进行独立的、冗余的存储，哪怕版本之间其实只存在微小的差异。举例而言，一个10M 的二进制文件（照片、图形文件、机械设计文件、电子设计文件）假如每周修改一次，无论每次修改的大小，一年下来，仅该文件就要消耗500M 以上的存储空间。而且，客户端每次获取该文件的新版本都要消耗10M 的网络流量。



对于目前的开发团队，无论是软件开发，Web 站点的开发，手机等电子产品的研发，需要进行版本管理的不仅是源代码等文本文件，还需要管理需求文档、设计文档、测试文档、用户手册，图形图像文件，机械/电子设计文件等诸多的二进制文件，CVS 显然不是一个好的选择。



与CVS 不同，Subversion 采用统一的二进制差异算法（binary differencing algorithm），即对文本文件和二进制文件采用相同的差异比较算法，并以相同的方式在版本库中进行存储：每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。



该二进制差异算法不仅应用在版本的存储上，更为重要的是，Subversion 对二进制文件与文本文件一视同仁，当客户端需要获取新的版本时（如执行svn update），在网络上只有版本的差异被传输，从而大大减少对网络带宽的消耗。更多细节参见"七、双向的差异化－压缩网络传输"。



七、 双向的差异化－压缩网络传输



如上所述，CVS 对二进制文件不能进行有效的差异化处理。对于文本文件，CVS 仅仅支持单向的差异化传输：从CVS 到客户端的传输是差异化的，即执行cvs update 时，只有差异的部分从服务器传输到客户端；而当执行cvs commit 时，无论代码变化多少，CVS 都需要从客户端向服务器完整传输被修改文件的全部内容，不能只传输差异。



相反，无论是文本文件还是二进制文件，Subversion 都进行双向的差异化传输，并且差异化内容还要进行压缩/解压缩的过程：在服务器端获取差异显而易见，与CVS 类似；Subversion 在客户端获取差异的秘密在于 — Subversion 在客户端的工作拷贝中隐含了每个文件的一个"只读的、干净的"副本（该副本隐藏在隐含目录.svn 里，通常不可见，该副本还有更多的妙用，参见"十二、更多的本地/离线操作"），通过比较用户在客户端的修改和该隐含的副本，Subversion 获取需要真正传送到服务器的差异，并对差异进行压缩后才进行网络传输。



对CVS 而言，操作的成本（网络带宽消耗是最大的操作成本）与被修改的文件的大小成比例，而与修改本身的大小无关；对Subversion 而言，操作成本只与修改本身的大小成比例，而与被修改的文件的大小无关。因此，与CVS 相比，Subversion 消耗更少的网络带宽（以客户端的存储空间换取更少的带宽消耗在目前的计算环境下应该是个相当不错的选择！）。Subversion 更加适合基于互联网（或广域网）进行协作开发的地理上分布的团队 — 版本服务器集中、单一；客户端广泛分布。



八、高效、快捷创建分支和基线



CVS 和Subversion 都支持分支（branch）和基线（tag），通过分支与合并，可以有效支持大项目的并行开发模式；通过基线管理，可以准确标识一组文件的版本，有效进行软件发布管理和必要时的历史回溯。



但CVS 和Subversion 在实现分支和基线的方式上存在很大的不同。CVS 在创建分支的时候，需要对所有进行分支的文件进行依次的操作，因此分支的建立成本（主要是建立分支所需的时间，或消耗的计算资源）与参与分支的文件数量成比例，项目越大，版本库越大，文件越多，分支的建立成本越高；基线（tag）的建立与此类似。



Subversion 的分支和基线是通过执行"拷贝"来建立的：回想一下在没有引入版本管理工具的时候我们是如何进行所谓的"分支"和"基线"管理的？答案显然是"拷贝" — 我们通过"拷贝"或"备份"来建立基线；同样，为支持多个开发人员可以同时进行开发，我们为每个开发人员创建一份"拷贝"。由此看来，Subversion 通过"拷贝"来建立分支和基线显得非常自然，有点"返朴归真"的意思。



由于Subversion 的全局版本号特性，Subversion 中分支或基线的创建过程，或Subversion中的"拷贝"过程，真正的操作是在版本库中创建一个到某一全局版本号的指针（pointer），不再需要针对众多的单个文件依次执行操作。因此，该操作的成本为一个很小的常数，与项目大小，版本库大小，文件数目的多少无关；并且，分支或基线的建立不需要进行版本的冗余存储，新建立的分支或基线基本不占用版本库空间，分支的后续存储空间的开销也只与修改的大小有关。



九、集成Apache Web Server，提供更多的特性



Subversion 通过与Apache Web Server 的集成，可以提供基于http/https 协议的版本库访问机制，从而支持Subversion 跨越防火墙的安全访问。除此以外，Subversion 还可以利用更多的Apache 特性，包括但不限于：Apache 丰富的用户认证机制（包括通过LDAP服务器如Windows Active Directory 服务器的用户认证），基于目录路径的精细粒度的访问控制，对传输的网络流量进行压缩/解压缩，浏览版本库目录结构等等。



十、支持WebDAV

WebDAV（Web-based Distributed Authoring and Versioning）是一种基于 HTTP 1.1 协议的通信协议.它扩展了HTTP 1.1，在GET、POST、HEAD 等几个HTTP 标准方法以外添加了一些新的方法，使应用程序可直接对Web Server 直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还可以支持文件的版本控制。

Microsoft windows2000/XP 及IE, Office 还有Adobe/MicroMedia 的DW 等都支持WebDAV，这又大大增强了Web 应用的价值，以及效能。对于需要大量发布内容的用户而言，应用WebDAV 可以降低对CMS 系统的依赖，而且能够更自由的进行创作。上传、下载变得轻松自如。

Subversion 通过与Apache Web Server 的集成，支持WebDAV 协议，使得业务用户（business users）或非技术用户在不安装任何版本管理客户端的情况下轻松访问Subversion 版本库，不改变业务用户已有使用习惯，支持分布的业务用户对文档的评审、修改并实现版本控制，真正将软件开发的生命周期从开发/技术团队扩展到项目的全部干系人（stakeholder），避免通过电子邮件传递文档的混乱与无序、通过Windows 操作系统共享造成的安全漏洞、病毒攻击、历史版本被覆盖或丢失、审计困难等诸多典型问题。



十一、更好的冲突标识与处理



CVS 和Subversion 都支持通过分支与合并进行并行开发，并可以自动检测到合并时的冲突（conflicts），并在合并结果中以<<<<<< … >>>>>>标识合并的冲突部分。

在CVS 中，经常会出现由于用户的疏忽（如，没有注意到冲突，或没有完全处理好冲突）而将仍然带有<<<<<< … >>>>>>冲突标识符号的文件直接进行提交（commit），从而在版本库中产生垃圾版本。

Subversion 有效解决了CVS 的以上问题：Subversion 记录并保持文件的冲突状态，只有当用户明确执行svn resolved 命令后，该冲突状态标识才被复位，该文件才能被提交，从而大大减少了将仍然带有<<<<<< … >>>>>>冲突标识符号的文件直接进行提交的可能性。



十二、 更多的本地/离线操作



众所周知，CVS 客户端的工作拷贝中包含了一个隐含目录CVS，该目录中记录了客户端需要的一些管理信息；与此类似，Subversion 的客户端工作拷贝中也包含了一个隐含目录.svn，该目录中同样记录了客户端需要的一些管理信息，如版本库URL，当前访问版本号等。

与CVS 不同的是，Subversion 的.svn 目录中还包含了工作拷贝中每一个文件的一个"只读的、干净的"副本。正是由于该副本的存在，使得Subversion 与CVS 相比，可以执行更多的本地/离线操作，即某些操作不需要访问版本库服务器，因此不需要存在从客户端到服务器的网络链接，当然也不消耗任何网络带宽，这进一步增强了Subversion 对广域网的友好支持。

Subversion 的以下命令可以进行离线操作：

svn status － 显示工作拷贝上的本地修改概况；

svn diff －显示工作拷贝上的本地修改细节，比较修改前后的内容；

svn revert － 撤销工作拷贝上的本地修改；



十三、 对符号链接进行版本管理



在Unix 文件系统中，符号链接（symbolic links，包括硬链接和软链接）是一种重要的文件系统元素。CVS 不能对符号链接进行版本管理；Subversion 则可以对符号链接进行版本管理。



十四、 元数据管理



与CVS 相比，Subversion 增加了元数据（metadata）管理机制。即可以对版本库中的文件或目录附加任意的"属性"（property），并记录属性的变化历史，也就是对元数据进行版本管理。一个Subversion 属性是一个"属性名称/属性值"的二元组，如"BugNumber= 100"就是一个属性，可以将该属性附加到版本N 上，以说明版本N 改正了编号为100的BUG。

Subversion 元数据的目的是提供附件的信息以满足流程或过程自动化的需要，以增强Subversion 的管理能力和自动化程度。Subversion 自身就通过"属性"来存储一些特殊的信息。一个使用Subversion 元数据的例子：可以在一些批处理的脚本程序或Subversion的钩子程序（hooks）中创建、访问、修改"属性"元数据来满足流程自动化的要求。

十五 VSS CVS 比较

VSS适合小团队使用，基本的配置管理功能都有。VSS最大的特点就是部署比较简单，上手比较快。VSS最大的缺点就是安全性问题，目录共享、文件方式存储等。当然VSS还只能在Windows下使用。

CVS了解过，应该说特点也很鲜明。首先CVS是开源软件，根据长期的流传，已经演变了很多版本，适合于不同的平台。因此，在CVS客户端上是多种多样的。其次，CVS的部署稍微复杂点，现对VSS来说，这是其一缺点。最后，CVS在配置管理的理念上，比VSS有所进步。

十六 Vss与Svn 的对比

1. SVN支持重命名，这对 Java开发来说非常重要。

为了得到更好的代码，开发中需要经常进行重构，重构就经常涉及到文件的重构名，而重命名中 VSS 中是不被支持的。

2. 开发的时候不一定要锁定。

一方面导致重构不方便，另一方面，不能离线开发，使用 SVN 就不同，可以带回家继续开发，回来后，提交就行了。

3. 多平台。
可以支持多个平台下的操作


4. 更好的客户端支持。
Eclipse 中的 VSS Plugin 不如它的 SVN Plugin 好用。一个在 Windows 下用的 SVN 客户端 TortoiseSVN 也比 VSS 的客户端好用（VSS 只有微软提供的一个 GUI 客户端）。

5. 更好地与外围工具集成。

各种各样的外围工具（主要是服务器端），满足多种需要。如果有需要，也可以自己写插件或管理脚本，开放的架构，允许我们这样做。

6. 方便。

一个例子：部署应用的时候，以前的做法是找出一个项目中修改过的文件，更新到服务器上去，现在可以在服务器上执行 svn export 命令，把代码库中的最新版本导出，完成部署（也可以替换回老版本）。

7. 速度与稳定性看起来都不错。
学习它的管理、它的工作方式，是值得的。而 VSS 是一个已经被逐渐抛弃的软件。如果时间不是多得没处用，那么就把时间花在最值得花的东西上面。

CVS常用命令速查手册

更多精彩尽在139ya网址导航

CVS常用命令速查手册

作者： 车东 chedong@bigfoot.com
　　
　　内容摘要：
　　
　　CVS是一个C/S系统，多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。工作模式如下：
　　
　　CVS服务器（文件版本库） / | （版 本 同 步） / | 开发者1 开发者2 开发者3
　　开发人员入门可以主要挑选2,6看就可以了，CVS的管理员则更需要懂的更多一些，最后还简单介绍了一些Windows下的cvs客户端使用，远程用户认证的选择，及与BUG跟踪系统等开发环境的集成问题。
　　
　　CVS环境初始化：CVS环境的搭建 管理员
　　CVS的日常使用：日常开发中最常用的CVS命令， 开发人员 管理员
　　CVS的分支开发：项目按照不同进度和目标并发进行 管理员
　　CVS的用户认证：通过SSH的远程用户认证，安全，简单 管理员
　　CVSWEB：CVS的WEB访问界面大大提高代码版本比较的效率 管理员
　　CVS TAG：将$Header$加入代码注释中，方便开发过程的跟踪 开发人员
　　CVS vs VSS: CVS和Virsual SourceSafe的比较 开发人员 管理员
　　WinCVS: 通过SSH认证的WinCVS认证设置
　　基于CVSTrac的小组开发环境搭建：通过CVSTrac实现web界面的CVS用户管理及集成的BUG跟踪和WIKI交流。
　　一个系统20%的功能往往能够满足80%的需求，CVS也不例外，以下是CVS最常用的功能，可能还不到它全部命令选项的20%，更多的功能在实际应用过程中体会，你想用多少就学多少，不时回头看看经常有意外的收获。
　　
　　CVS环境初始化
　　============
　　
　　环境设置：指定CVS库的路径CVSROOT
　　tcsh
　　setenv CVSROOT /path/to/cvsroot
　　bash
　　CVSROOT=/path/to/cvsroot ; export CVSROOT
　　
　　后面还提到远程CVS服务器的设置：
　　CVSROOT=:ext:$USER@test.server.address#port:/path/to/cvsroot CVS_RSH=ssh; export CVSROOT CVS_RSH
　　
　　初始化：CVS版本库的初始化。
　　cvs init
　　
　　一个项目的首次导入
　　cvs import -m "write some comments here" project_name vendor_tag release_tag
　　执行后：会将所有源文件及目录导入到/path/to/cvsroot/project_name目录下
　　vender_tag: 开发商标记
　　release_tag: 版本发布标记
　　
　　项目导出：将代码从CVS库里导出
　　cvs checkout project_name
　　cvs 将创建project_name目录，并将最新版本的源代码导出到相应目录中。这个checkout和Virvual SourceSafe中的check out不是一个概念，相对于Virvual SourceSafe的check out是cvs update， check in是cvs commit。
　　
　　CVS的日常使用
　　=============
　　
　　注意：第一次导出以后，就不是通过cvs checkout来同步文件了，而是要进入刚才cvs checkout project_name导出的project_name目录下进行具体文件的版本同步（添加，修改，删除）操作。
　　
　　将文件同步到最新的版本
　　cvs update
　　不制定文件名，cvs将同步所有子目录下的文件，也可以制定某个文件名/目录进行同步
　　cvs update file_name
　　最好每天开始工作前或将自己的工作导入到CVS库里前都要做一次，并养成“先同步 后修改”的习惯，和Virvual SourceSafe不同，CVS里没有文件锁定的概念，所有的冲突是在commit之前解决，如果你修改过程中，有其他人修改并commit到了CVS库中，CVS会通知你文件冲突，并自动将冲突部分用
　　>>>>>>
　　content on cvs server
　　<<<<<< 　　content in your file 　　>>>>>>
　　标记出来，由你确认冲突内容的取舍。
　　版本冲突一般是在多个人修改一个文件造成的，但这种项目管理上的问题不应该指望由CVS来解决。
　　
　　确认修改写入到CVS库里
　　cvs commit -m "write some comments here" file_name
　　
　　注意：CVS的很多动作都是通过cvs commit进行最后确认并修改的，最好每次只修改一个文件。在确认的前，还需要用户填写修改注释，以帮助其他开发人员了解修改的原因。如果不用写-m "comments"而直接确认`cvs commit file_name` 的话，cvs会自动调用系统缺省的文字编辑器(一般是vi)要求你写入注释。
　　注释的质量很重要：所以不仅必须要写，而且必须写一些比较有意义的内容：以方便其他开发人员能够很好的理解
　　不好的注释，很难让其他的开发人员快速的理解：比如： -m "bug fixed" 甚至 -m ""
　　好的注释，甚至可以用中文: -m "在用户注册过程中加入了Email地址校验"
　　
　　修改某个版本注释：每次只确认一个文件到CVS库里是一个很好的习惯，但难免有时候忘了指定文件名，把多个文件以同样注释commit到CVS库里了，以下命令可以允许你修改某个文件某个版本的注释：
　　cvs admin -m 1.3:"write some comments here" file_name
　　
　　添加文件
　　创建好新文件后，比如：touch new_file
　　cvs add new_file
　　注意：对于图片，Word文档等非纯文本的项目，需要使用cvs add -kb选项按2进制文件方式导入(k表示扩展选项，b表示binary)，否则有可能出现文件被破坏的情况
　　比如：
　　cvs add -kb new_file.gif
　　cvs add -kb readme.doc
　　
　　然后确认修改并注释
　　cvs ci -m "write some comments here"
　　
　　删除文件
　　将某个源文件物理删除后，比如：rm file_name
　　cvs rm file_name
　　然后确认修改并注释
　　cvs ci -m "write some comments here"
　　以上面前2步合并的方法为：
　　cvs rm -f file_name
　　cvs ci -m "why delete file"
　　注意：很多cvs命令都有缩写形式：commit=>ci; update=>up; checkout=>co/get; remove=>rm;
　　
　　添加目录
　　cvs add dir_name
　　
　　查看修改历史
　　cvs log file_name
　　cvs history file_name
　　
　　查看当前文件不同版本的区别
　　cvs diff -r1.3 -r1.5 file_name
　　查看当前文件（可能已经修改了）和库中相应文件的区别
　　cvs diff file_name
　　cvs的web界面提供了更方便的定位文件修改和比较版本区别的方法，具体安装设置请看后面的cvsweb使用
　　
　　正确的通过CVS恢复旧版本的方法：
　　如果用cvs update -r1.2 file.name
　　这个命令是给file.name加一个STICK TAG： "1.2" ，虽然你的本意只是想将它恢复到1.2版本
　　正确的恢复版本的方法是：cvs update -p -r1.2 file_name >file_name
　　如果不小心已经加成STICK TAG的话：用cvs update -A 解决
　　
　　移动文件/文件重命名
　　cvs里没有cvs move或cvs rename，因为这两个操作是可以由先cvs remove old_file_name，然后cvs add new_file_name实现的。
　　
　　删除/移动目录
　　最方便的方法是让管理员直接移动，删除CVSROOT里相应目录（因为CVS一个项目下的子目录都是独立的，移动到$CVSROOT目录下都可以作为新的独立项目：好比一颗树，其实砍下任意一枝都能独立存活），对目录进行了修改后，要求其开发人员重新导出项目cvs checkout project_name 或者用cvs update -dP同步。
　　
　　项目发布导出不带CVS目录的源文件
　　做开发的时候你可能注意到了，每个开发目录下，CVS都创建了一个CVS/目录。里面有文件用于记录当前目录和CVS库之间的对应信息。但项目发布的时候你一般不希望把文件目录还带着含有CVS信息的CVS目录吧，这个一次性的导出过程使用cvs export命令，不过export只能针对一个TAG或者日期导出，比如：
　　cvs export -r release1 project_name
　　cvs export -D 20021023 project_name
　　cvs export -D now project_name
　　
　　CVS Branch：项目多分支同步开发
　　=============================
　　
　　确认版本里程碑：多个文件各自版本号不一样，项目到一定阶段，可以给所有文件统一指定一个阶段里程碑版本号，方便以后按照这个阶段里程碑版本号导出项目，同时也是项目的多个分支开发的基础。
　　cvs tag release_1_0
　　
　　开始一个新的里程碑：
　　cvs commit -r 2 标记所有文件开始进入2.x的开发
　　
　　注意：CVS里的revsion和软件包的发布版本可以没有直接的关系。但所有文件使用和发布版本一致的版本号比较有助于维护。
　　
　　版本分支的建立
　　在开发项目的2.x版本的时候发现1.x有问题，但2.x又不敢用，则从先前标记的里程碑：release_1_0导出一个分支release_1_0_patch
　　cvs rtag -b -r release_1_0 release_1_0_patch proj_dir
　　
　　一些人先在另外一个目录下导出release_1_0_patch这个分支：解决1.0中的紧急问题，
　　cvs checkout -r release_1_0_patch
　　而其他人员仍旧在项目的主干分支2.x上开发
　　
　　在release_1_0_patch上修正错误后，标记一个1.0的错误修正版本号
　　cvs tag release_1_0_patch_1
　　
　　如果2.0认为这些错误修改在2.0里也需要，也可以在2.0的开发目录下合并release_1_0_patch_1中的修改到当前代码中：
　　cvs update -j release_1_0_patch_1
　　
　　CVS的远程认证：通过SSH远程访问CVS
　　================================
　　
　　使用cvs本身基于pserver的远程认证很麻烦,需要定义服务器和用户组，用户名，设置密码等，
　　常见的登陆格式如下：
　　cvs -d :pserver:cvs_user_name@cvs.server.address:/path/to/cvsroot log