• Trac 0.10，Trac程序
• Apache 2.0.59，Web服务器
• subversion 1.4.3，代码版本管理工具
• Python 2.4.4，Python解释器
• mod_python，Python的Apache模块
• ClearSilver 0.9.4，Python的模版工具
• mxDateTime 2.0.3，Python必须库文件
• PostgreSQL 8.2.3，数据库服务器
• pyPgSQL 2.5.1，Python访问PostgreSQL数据库的模块

很遗憾subversion现在仍然不支持最新的Apache 2.2系列，因此我们只能使用Apache 2.0系列。而pyPgSQL 2.5.1版和ClearSilver 0.9.4不支持Python 2.5，因此只能用 Python 2.4。

另外，虽然Trac支持SQLite，但SQLite支持的SQL语法有限，实际应用中会有诸多不便，因此我们选择了PostgreSQL作为后台数据库。

安装错误时怎么办？

如果你安装过程中发现某些地方不正常，记住按照下面的方法来纠正：

1. 查看错误信息，看是否能找到提示
2. 检查有无忘了装的软件
3. 检查httpd.conf是否有误
4. 修改之后记得重新启动Apache

安装Apache和subversion

在Apache官方网站上下载2.0.59版的msi安装包，执行即可。为方便起见，建议将Apache安装到根目录下，例如 D:\Apache。安装时的一些细节可以参考这篇文章。安装完毕后用浏览器访问 http://localhost/ ，如能看到Apache的起始页面即安装成功。

从subversion上下载zip包解压缩即可，目前最新版本为svn-win32-1.4.3.zip。假设解压到 D:\svn下。

然后将subversion与Apache集成在一起（也可参考这篇文章）。将 D:\svn\bin 下的以下文件复制到 D:\Apache\modules 目录下：

• mod_authz_svn.so
• mod_dav_svn.so

将 D:\svn\bin 下的以下文件复制到 D:\Apache\bin 目录下：

• libdb44.dll
• intl3_svn.dll

然后建立代码仓库目录 D:\repos。

然后修改 D:\Apache\Apache2\conf\httpd.conf，查找下面这一行，去掉前面的 # 号。

 LoadModule dav_module modules/mod_dav.so

然后在其附近添加以下这一行：

 LoadModule dav_svn_module modules/mod_dav_svn.so

之后在 httpd.conf 的末尾添加以下内容：

 <Location /repos>
     DAV svn
     SVNParentPath D:/repos
 </Location>

然后重新启动Apache。之后试着访问一个不存在的页面，如 http://localhost/abc，你会看到Not Found页面下方的内容如下：

 Apache/2.0.59 (Win32) SVN/1.4.3 DAV/2 Server at localhost Port 80

如果这里显示了 SVN/1.4.3 则说明安装成功。

安装Python、mod_python和SVN binding

从Python官方网站下载Python 2.5的msi安装包进行安装，假设安装到D:\Python25目录下。

从mod_python的下载页面 上下载mod_python 3.3.0b的Win32版(mod_python-3.3.0b.win32-py2.4-Apache2.0.exe)。安装时它会问你Apache的安装位置，输入 D:\Apache\Apache2 即可。

最后打开 D:\Apache\Apache2\conf\httpd.conf，查找 LoadModule，加入下面这一行：

 LoadModule python_module modules/mod_python.so

然后重新启动Apache。之后试着访问一个不存在的页面，如 http://localhost/abc，你会看到Not Found页面下方的内容如下：

 Apache/2.0.59 (Win32) SVN/1.4.3 mod_python/3.3.0b Python/2.4.4 DAV/2 Server at localhost Port 80

如果这里显示了 mod_python/3.3.0b Python/2.4.4 则说明安装成功。

最后要安装subversion binding使Python支持subversion。到刚才下载subversion的地方 下载 svn-win32-1.4.3_py2.4.exe 文件并安装。

安装PostgreSQL和pyPgSQL

到PostgreSQL官方主页下载最新版8.2.3(postgresql-8.2.3-1.zip)并安装。

为了让Python支持PostgreSQL，我们还需要安装pyPgSQL模块。到pyPgSQL主页下载2.5.1版并安装。

安装结束之后，需要将 bin 目录下的以下文件复制到 D:\Python24\Lib\site-packages\pyPgSQL\libpq 下。

• libpq.dll
• comerr32.dll
• libeay32.dll
• libintl-2.dll
• libiconv-2.dll
• krb5_32.dll
• ssleay32.dll

安装ClearSilver和mxDateTime

在ClearSilver的下载页面选择0.9.4的py2.4版下载 (win32/clearsilver-0.9.14.win32-py2.4.exe)并安装。

Trac官方文档中虽然没有说明mxDateTime，但是建立项目时Trac会报错，要求你安装mxDateTime库。从mxDateTime主页下载并安装。

安装Trac

最后终于轮到主角Trac出场了。在Trac下载页面上下载 Trac安装程序(trac-0.10.3.win32.exe)并安装。

然后建立项目目录 D:\projects。

然后打开 D:\Apache\Apache2\conf\httpd.conf，在最末尾添加以下内容：

 <Location /projects>
     SetHandler mod_python
     PythonHandler trac.web.modpython_frontend 
     PythonOption TracEnvParentDir D:/projects
     PythonOption TracUriRoot /projects
 </Location>

然后重新启动Apache，访问 http://localhost/projects/，你会看到Available Projects字样，则说明安装成功。至此安装全部完毕。

建立项目

下面我们要建立一个实际开发中使用的项目。我们为这个项目命名为 hello。

首先要建立一个代码仓库。打开命令行，输入以下命令：

 D:
 cd D:\repos
 md hello
 cd hello
 D:\svn\bin\svnadmin create .

然后打开浏览器，访问 http://localhost/repos/hello/ 。如果你上面的设置都正确，你将会看到下面的内容：

 Revision 0: /
 ----------------------------------------------
 Powered by Subversion version 1.4.3 (r23084).

即说明代码仓库建立成功，而 http://localhost/repos/hello/ 就是代码仓库的 URL。

然后建立数据库。从开始菜单中启动PostgreSQL的 pg Admin III工具，新建一个数据库 hello，注意将字符编码设置为UTF8。

然后建立Trac项目。打开命令行，输入以下命令：

 D:
 cd D:\projects
 D:\Python24\python.exe D:\Python24\Scripts\trac-admin hello initenv

trac-admin 为Trac的管理工具，hello为项目名，initenv命令指示Trac新建一个项目。然后按照下面的内容输入：

 Project Name [My Project]> Hello World
 Database connection string [sqlite:db/trac.db]> postgres://<username>:<password>@localhost/hello
 Repository type [svn]> svn
 Path to repository [/path/to/repos]> D:/repos/hello
 Templates directory [D:\Python24\share\trac\templates]>

数据库连接那一行，<username>和<password>分别为安装PostgreSQL时设置的用户名和密码。如果创建失败，则需要删除 D:\projects\hello 之后再重试。

最后打开浏览器，访问 http://localhost/projects/hello 即可看到Trac的界面了。

设置HTTP认证

在Trac界面右上方有个Login菜单，通过这个菜单登录之后，创建bug或者做其他修改时就不用每次都输入用户名。不过这个菜单需要单独配置才能正常工作。

首先我们要生成密码文件。打开命令行，输入以下命令：

 D:
 cd D:\projects
 D:\Apache\Apache2\bin -c .htpasswd admin
 Automatically using MD5 format.
 New password: *****
 Re-type new password: *****
 Adding password for user admin

即可生成密码文件 .htpasswd。以后向该密码文件里追加用户只需这样即可。

 D:\Apache\Apache2\bin .htpasswd user

然后编辑 httpd.conf，在最末尾加入以下内容：

 <LocationMatch "/projects/[^/]+/login">
     AuthType Basic
     AuthName "Trac"
     AuthUserFile D:/projects/trac.htpasswd
     Require valid-user
 </LocationMatch>

然后重新启动Apache

二、评估项目

三、评估对象

四、评估方法

五、评估结果

版本控制系统或资源管理系统是现代软件开发的一个重要方面。不使用版本控制系统就如同超速驾驶一辆汽车：很刺激，也可能会更快抵达目的地，但事故却在所难免。本文概述了软件配置管理（SCM）系统及其优势，内容涵盖 CVS、Subversion、Arch 和 Git。本文还讨论了最常见的 SCM 体系结构。本文在最后给出了新出现的一些方法及这些方法与先前方法的区别。

什么是软件配置管理？

在学校学习的重要工具中，通常不会 包含 SCM。软件（或资源）控制，正如其名字所暗示的那样，是一种工具和一种相关的过程，而这种过程被用于维护源代码及其演进。SCM 提供的主要功能如下：

• 在存储库（repository）中维护一个文件。
• 在存储库中维护文件的修订。
• 检测源更改冲突并为多个开发人员的环境提供合并。
• 跟踪变更的发起方。
• 为了实现一致、可重复的构建提供文件（相关修订）的配置管理。

SCM 的适用性 资源控制 主要是指源代码和相关文件的控制，而资源管理 则可应用于任何类型的资源。包含超文本标记语言（HTML）和二进制图像文件、一般文本文档或其他任何文件的 Web 站点是 SCM 系统进行修订控制的对象。

所以，SCM 允许您控制存储库中的一组文件并跟踪这些文件的修订。其他开发人员更改了存储库中的这些文件后，SCM 会标识出这些变更与您所做的变更之间存在的冲突，然后自动将其合并或通知您存在冲突。这个功能非常重要，因为它允许多个开发人员修改同一组文件。SCM 还能跟踪出谁做了何种变更。SCM 还允许您将文件按逻辑划分为相关的文件组，比如组成软件图像或可执行文件的源文件。

SCM 的术语

在深入研究 SCM 体系结构的类型和细节之前，先要熟悉一下术语的含义。存储库 是文件存储和管理的中心位置（有时又被称为树）。从存储库中取出文件放到本地系统的工作文件夹的过程被称作签出。如果变更了本地文件而又想同步变更存储库，就需要执行更新。如果要将变更后的文件签入到存储库，就需执行提交。如果所变更的文件先前已经被变更并已由别人提交，则会发生合并，表明两组变更集将会被合并在一起。若由于变更冲突的原因不能合并时，则必已发生了冲突。在此情况下，提交被拒绝，并要求开发人员手工合并变更。当提交了变更之后，就会创建此文件的一个新的修订。

一个或多个开发人员可以对主树（存储库的当前头）或位于主树旁的单个的分支进行操作。这就让开发人员可以操作分支而不会影响到主树。当分支稳定后，再将分支与主树进行合并。

要标记源树演进过程中的重要阶段，可以对一组文件修订应用标签。这会将这组文件组合成一个有用的集合（有时会用作针对于惟一构建的文件的一个发布）。

回页首

体系结构

各种 SCM 间有许多的差异，其中有两种最基本的区别很值得研究：

• 集中式存储库与分布式存储库
• 变更集模型与快照模型

集中式存储库与分布式存储库

现代 SCM 体系结构的最为重要的差异之一是存储库是集中式的还是分布式（分散的）。当前最为常见的体系结构是集中式存储库。这个星型 体系结构由中心的源存储库和工作于这个存储库的多个开发人员组成（参见图 1）。开发人员从中心存储库签出源代码到本地的沙箱内，进行变更后，将它提交回中心存储库。其他开发人员就可以再访问这些变更。

中心存储库也可以创建分支，允许多个开发人员协作于针对位于存储库（但必须在 mainline 或 tip 之外）的资源的一组变更。

分布式体系结构则允许开发人员为其变更创建其自己本地的存储库。本地开发人员的存储库与原始的存储库（已被分布）很相似。主要的区别是：在集中化的方式中，变更是在沙箱内完成的，而在分布式方法中则允许开发人员工作于分离的存储库。开发人员进行变更、提交变更到其本地的存储库，之后，在不影响主干的前提下，与其他开发人员的变更合并。这样，本地开发人员就使得变更集对上线（upline）开发人员可用（参见图 2）。

分散体系结构很有意思，因为它允许不同的开发人员在对等网络内同步工作。当工作准备好（最好是稳定）后，开发人员可以分发变更集（或修补）以使他人也可以使用这些特性。这是当今许多开源系统的模型，包括 Linux® 内核。

变更集模型与快照模型

早先的和现代的 SCM 的体系结构的另一个有趣的区别是 delta 变更的存储方式。它们理论上是相同的，且产生的结果也相同，但在修订的存储方式上二者却大不相同。

在快照模型中，整个存储库的每个修订（带优化以减少树的大小）的全部文件都被存储。而在变更集模型中，只有 delta 被存储于修订之间，这样就创建了一个精简的存储库（参见图 3）。

从图 3 可以看出，模型不同但结果却相同。在快照模型中，可以快速获得修订，但需要更多的空间来存储它们。而变更集模型需要的空间少，但需要更多时间来获得某个修订，原因是 delta 必须应用于基本修订。在本文后面的部分将介绍如何建立优化来最小化必须要应用的 delta 的数量。

回页首

示例 SCM

让我们来看一下按体系结构（集中或分布）划分的一些 SCM。您很快就会看到，其中一些 SCM 支持两种模型。

CVS

并发版本系统（Concurrent Versions System，CVS）是当今最为常用的 SCM。它是一种集中式的解决方案，采用了快照模型，开发人员使用集中式的存储库来进行软件的协作开发。CVS 十分常见而且是 Linux 发布版的一部分。其简单和方便的语法（对大多数人而言）使其迅速成为了多个或单个开发人员 SCM 的一种理想选择。

清单 1 给出了一组 CVS 命令示例和简短的相关描述。要获得关于 CVS 的更多信息，请参阅 参考资料 部分。

# Create a new repository
cvs -d /home/user/new_repository init

# Connect to the central repository
export CVSROOT=:pserver:user@example.com:/cvs_root

# Check out a sandbox for module project from the central repository
cvs checkout project

# Update a local sandbox from the central repository
cvs update

# Check in changes from the local sandbox to the central repository
cvs commit

# Add new files to the local sandbox (need to be committed)
cvs add <file/subdirectory>

# Show changes made in the local sandbox
cvs diff

对于喜欢用指向-单击方式操作的用户，CVS 提供了许多开源的图形化前端以供使用，包括 WinCVS 和 TortoiseCVS（集成了 Microsoft® Windows Explorer）。

尽管 CVS 被广泛采用，但它仍然有一些不足之处。CVS 不允许重命名文件，而且对一些特殊文件（如 symlink）的支持不是很好。变更可以按文件跟踪，而非按变更本身，这点十分讨厌。合并有时也会出现问题（CVS 内部会为此使用 diff3）。

然而，CVS 总体而言还是很有用的，能够实现其需要实现的任务，而且所有主流的平台都支持 CVS。如果喜欢用 CVS 而又想回避其缺点，则可以考虑使用 Subversion。

Subversion

Subversion（SVN）是为了替代 CVS 而设计的，消除了 CVS 原有的问题和缺点。与 CVS 一样，Subversion 也是一种集中化的解决方案，采用的是快照模型。它的命令也模仿了 CVS 的，但增加了一些对诸如删除文件、重命名文件或恢复为原始文件等的处理功能。

Subversion 还允许远程访问，可以采用很多协议，比如超文本传输协议 (HTTP)、安全 HTTP或定制的 SVN 协议，此协议还支持通过 Secure Shell (SSH)的隧道技术。

清单 2 给出了 Subversion 所支持的一些命令及 CVS 中所没有的一些扩展。要获得关于 Subversion 的更多信息，请参阅 参考资料 部分。很明显，Subversion 的命令集和 CVS 的很相似，这使它极受 CVS 用户的欢迎。

# Create a new repository
svnadmin create /home/user/new_repository

# Check out a sandbox from the central repository
svn checkout file:///server/svn/existing_repository new_repository

# Update a local sandbox from the central repository
svn update

# Check in changes from the local sandbox to the central repository
svn commit

# Add new files to the local sandbox (need to be committed)
svn add <file/subdirectory>

# Show changes made in the local sandbox
svn diff

# Rename a file in the local sandbox (requires commit to the repository)
svn rename <old_file> <new_file>

# Remove files (also removed from repository, requires commit)
svn delete <file/subdirectory>

与 CVS 一样，Subversion 集成了一些图形化的前端如 ViewCVS 和 TortoiseSVN。另外也有一些工具可以把 CVS 存储库转化为 Subversion（例如 cvs2svn.py），但这些工具并不能处理复杂版本的分支和标记。和许多开源项目一样，随着时间的推移，这种情况会有所改变。Subversion 还集成了 TortoiseMerge 作为一个单独的查看器和修补程序。

Subversion 解决了许多让 CVS 用户困扰的问题，比如特殊文件的版本化和自动的提交和签出。如果您喜欢用 CVS 和集中式存储库的方式，那么 Subversion 就是您所需的 SCM。

现在让我们先放下对集中方式的讨论，看看被人们视为 SCM 未来的协作式分散存储库。

Arch

Arch 是分散 SCM 的规范，它提供许多不同的实现，包括 ArX、Bazaar、GNU arch 和 Larch。Arch 不仅可以作为一种分散 SCM 运作，如 图 2 所示，还可使用变更集模型（参见 图 3）。Arch SCM 是开源开发的一种很流行的方法，因为开发人员可在单独的存储库上进行开发，同时又能够控制全部资源。这是因为分布式存储库就是具有修订控制的实际存储库。可以在本地存储库利用变更创建一个修补来供上游的开发人员使用。这就是分散模型的真正的强势所在。

与 Subversion 相似，Arch 解决了 CVS 中所存在的许多问题，包括元数据的变更，例如修订文件许可、处理文件删除和重命名以及自动的签入（将签入组在一起而非作为单独的文件）。

清单 3 中显示了 Arch SCM 中的一些常见命令，还给出了 GNU arch，因为它是由 Arch 的设计者 Tom Lord 开发的。GNU arch 提供了 SCM 应有的一些基本功能，包括 Subversion 中的一些新特性。

# Register a public archive
tla register-archive http://www.mtjones.com/arch

# Check out a local repository from the upstream repository
tla get project@mtjones.com--dev/project--stable myproject

# Update from the local repository
tla update

# Check in changes to the local repository
tla commit

# Add new files to the local repository (need to be committed)
tla add <file>

# Show changes made in the local repository (patch format)
tla what-changed

# Rename a file in the local repository (requires commit to the repository)
tla mv <old_file> <new_file>

# Remove files (also removed from repository, requires commit)
tla rm <file>

Arch 还允许用 star-merge 合并来自上游存储库的变更。为了最小化必须应用到基本修订的修补的数量（根据变更集模型）， cacherev 命令将会在存储库中创建基本修订的一个新的快照。

Arch 的优势之一是虽然它是为分散操作所设计的，但也可以用于集中存储库范例。

tla 用户对其不满之处是它太过复杂。其他的 Arch 实现，例如 baz 则非常简单。如果 tla 不能满足要求，可以尝试使用后者。

现在让我们来看一下最后一个分散式的 SCM，它由 Linux 内核的维护者 Linus Torvalds 本人编写。

Git

Git SCM 由 Linus Torvalds 开发，用来替代 Bitkeeper SCM（参阅 参考资料 部分）。 它非常简单，是一种分散式的基于变更集的 SCM 且用作 Linux 内核的 SCM。它使用文件组模型而非跟踪单个的文件。使用 SHA1 压缩并混编变更集以验证其完整性（参见清单 4）。

# Get a Git repository (first time)
git clone \
  rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
  linux-2.6

rsync -a \
  --progress rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
  .git/

# Update a Git repository from the defined upstream Git repository
git pull rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

# Checkout from the Git repository into the local working repository
git checkout

# Update from the local Git repositor3
git-update-cache

# Commit changes to the local Git repository
git commit

# Add new files to the local repository
git-update-cache --add <file>

# Show changes made to the local working directory
git diff

# Remove files (requires commit)
git-update-cache --remove <file>

Git SCM 在其自己的 Git 存储库内是自托管的，这意味着您必须引导 Git 来将其安装到本机。Git 的命令集与您到目前为止看到的那些命令十分类似，而且相对简单。

您可能会问：“为什么不使用现有的 SCM 中的一种呢？” 问得很好。 Git 非常有趣，吸引着许多 Linux 内核黑客，所以它很可能成为下一个主流的 SCM。Linus 将 Git 描述为一个高速的目录内容管理器，虽然它所做的工作不多但完成得十分高效。

回页首

收益

无论您使用何种 SCM，都会获得一些普遍的收益。使用 SCM，可以跟踪文件中的变更来判断变更对软件的影响程度。当发生不正确的变更时，可以发现这些变更并将它们恢复回原始资源中。可以组合文件修订集并标记它们来制作发布，而发布又可以在任何时间签出以供重复构建代码的特定发布（SCM 的要求）。

不管使用集中式存储库还是分布式存储库，使用快照模型还是变更集模型，所带来的收益都是相同的。因为任何现代软件开发项目都必须要有 SCM，所以越早越多地使用它们就会受益越多。

回页首

前景展望

本文只讨论了现在最为常用的 SCM 的一些最基础的知识。还有许多其他的开源 SCM 可以使用，例如 Aegis、Bazaar-NG、DARCS 和 Monotone。当然，SCM 也引起了一些争论，而这些争论通常很难有正确的答案。如果使用一种工具后效率极高，那就使用这种工具吧！SCM 大多时候都用在团队开发的情况下，而很少用于孤立的个人开发的环境中（除非您是个独断专行的老板，喜欢自己做所有决定）。所以，您尽可以尝试所有的可能性来熟悉一些不同的风格。SCM 是软件开发中的必需工具，也是您的开发工具箱中的必备部分。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• 在 LinuxMafia，浏览大量的 Linux SCM 。
  
  
• 阅读 David Wheeler 关于开源 SCM 的 有趣论文，内容涵盖 CVS、Subversion、Arch 和 Monotone。
  
  
• Nick Moffitt 在 Revision Control with Arch: Introduction to Arch（Linux Journal，2004 年 11 月）中为我们介绍了 Arch 的一个十分有趣的方面。
  
  
• Tom Copeland 在 “StatCVS 提供了对 CVS 储存库活动的深入观察”（developerWorks，2005 年 2 月）一文中展示了如何用 StatCVS 从 CVS 历史数据中创建图表。
  
  
• 在 “Torvalds Gives Inside Skinny on Git”（eWeek，2005 年 4 月）一文中向 Linus 本人学习 Git 的更多知识。
  
  
• 在 Kernel Hackers' Guide 中了解 Git。
  
  
• 这里的 版本控制系统比较 提供了多种 SCM 间的对比。
  
  
• 通过本文作者编著的 GNU/Linux Application Programming 一书（Charles River Media，2005 年 1 月）全面学习 Linux 编程，从工具到 API 等等。
  
  
• 要获得关于 CVS 的更详尽的信息，请参阅 开发者和爱好者的 CVS（developerWorks，2001 年 3 月）。
  
  
• 在 developerWorks Linux 专区可以找到为 Linux 开发人员准备的更多资源。
  
  
• 随时关注 developerWorks 技术事件和网络广播。

• CVS 是应用最早和最广泛的 SCM 之一。
  
  
• Subversion 是 CVS 的一个强有力的替代品。
  
  
• GNU arch 是由 Tom Lord 完成的 Arch SCM 规范的一个实现。
  
  
• 参阅 sourceforge 的 Aegis，这是一个基于事务的 SCM。
  
  
• 关于 IBM 的 SCM，请访问 Rational change and configuration management 页面。
  
  
• 订购 SEK for Linux，这有两张 DVD，含最新的 IBM for Linux 的试用软件，包括 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere®。
  
  
• 使用 IBM 试用软件 构建您的下一个 Linux 开发项目，这些软件可以从 developerWorks 直接下载。
  
  

• 通过参与 developerWorks blogs 加入 developerWorks 社区。
  

      在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件， 嵌入式系统 ，人机界面，办公套件， 操作系统 ，编译器，数据库，游戏等。同时，各个行业几乎都有 计算机软件 的应用，比如工业，农业，银行，航空，政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。

      软件工程师是对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为系统分析员，软件设计师，系统架构师，程序员，测试员等等。人们也常常用程序员来泛指各种软件工程师。

     软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。

     (1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。

     (2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。

      (3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

一、软件工程概述

      概念：应需而生

　　软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言，它借鉴了传统工程的原则和方法，以求高效地开发高质量软件。其中应用了计算机科学、数学和管理科学。计算机科学和数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量和成本的管理。

      软件工程这一概念，主要是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO（北大西洋公约组织）会议上。自这一概念提出以来，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，开发了一些结构化程序设计语言（例如PASCAL语言，Ada语言）、结构化方法等。并且围绕项目管理提出了费用估算、文档复审等方法和工具。综观60年代末至80年代初，其主要特征是，前期着重研究系统实现技术，后期开始强调开发管理和软件质量。

      70年代初，自“软件工厂”这一概念提出以来，主要围绕软件过程以及软件复用，开展了有关软件生产技术和软件生产管理的研究与实践。其主要成果有：提出了应用广泛的面向对象语言以及相关的面向对象方法，大力开展了计算机辅助软件工程的研究与实践。尤其是近几年来，针对软件复用及软件生产，软件构件技术以及软件质量控制技术、质量保证技术得到了广泛的应用。目前各个软件企业都十分重视资质认证，并想通过这些工作进行企业管理和技术的提升。软件工程所涉及的要素可概括如下：

      根据这一框架，可以看出：软件工程涉及了软件工程的目标、软件工程原则和软件工程活动。

      目标：我的眼里只有“产品”

      软件工程的主要目标是：生产具有正确性、可用性以及开销合宜的产品。正确性意指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜性是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多问题有待解决，它们形成了对过程、过程模型及工程方法选取的约束。

      软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件体系结构，包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。支持活动包括修改和完善。伴随以上活动，还有管理过程、支持过程、培训过程等。

      框架：四项基本原则是基石

　　软件工程围绕工程设计、工程支持以及工程管理，提出了以下四项基本原则：

      第一，选取适宜开发范型。该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。

      第二，采用合适的设计方法。在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

      第三，提供高质量的工程支持。“工欲善其事，必先利其器”。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

      第四，重视开发过程的管理。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。

      这一软件工程框架告诉我们，软件工程的目标是可用性、正确性和合算性；实施一个软件工程要选取适宜的开发范型，要采用合适的设计方法，要提供高质量的工程支撑，要实行开发过程的有效管理；软件工程活动主要包括需求、设计、实现、确认和支持等活动，每一活动可根据特定的软件工程，采用合适的开发范型、设计方法、支持过程以及过程管理。根据软件工程这一框架，软件工程学科的研究内容主要包括：软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。

      作用：高效开发高质量软件

　　自从软件工程概念提出以来，经过30多年的研究与实践,虽然“软件危机”没得到彻底解决，但在软件开发方法和技术方面已经有了很大的进步。尤其应该指出的是，自80年代中期，美国工业界和政府部门开始认识到，在软件开发中，最关键的问题是软件开发组织不能很好地定义和管理其软件过程，从而使一些好的开发方法和技术都起不到所期望的作用。也就是说，在没有很好定义和管理软件过程的软件开发中，开发组织不可能在好的软件方法和工具中获益。

      根据调查，中国的现状几乎和美国10多年前的情况一样，软件开发过程没有明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全组织的过程改善，采用严格的软件工程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高。

      这一事实告诉我们，只有坚持软件工程的四条基本原则，既重视软件技术的应用，又重视软件工程的支持和管理，并在实践中贯彻实施，才能高效地开发出高质量的软件。

二、软件工程的七条基本原理

      自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续 提出了100多条关于软件工程的准则或信条。 美国著名的软件工程专家 Boehm 综合这些专家的意见，并总结了TRW公司多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。

　　Boehm 认为，着七条原理是确保软件产品质量和开发效率的原理的最小集合。
　　它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。

　　人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。

　　下面简要介绍软件工程的七条原理：

　　1 用分阶段的生命周期计划严格管理
　　这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

　　2 坚持进行阶段评审
　　统计结果显示： 大部分错误是在编码之前造成的，大约占63%; <2> 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。

　　3 实行严格的产品控制
　　开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。

　　4 采纳现代程序设计技术
　　从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。

　　5 结果应能清楚地审查
　　软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限， 尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。

　　软件体系结构表示了一个软件系统的高层结构，主要特点有：1）软件系统结构是一个高层次上的抽象，它并不涉及具体的系统结构（比如B/S还是C/S），也不关心具体的实现。2）软件体系结构必须支持系统所要求的功能，在设计软件体系结构的时候，必须考虑系统的动态行为。3）在设计软件体系结构的时候，必须考虑有现有系统的兼容性、安全性和可靠性。同时还要考虑系统以后的扩展性和伸缩性。所以有时候必须在多个不同方向的目标中进行决策。

　　当前已经有一些关于规范化软件体系结构，比如：ISO的开放系统互联模型、X Window系统等等。软件系统的结构通常被定义为两个部分：一个是计算部件。另一个就是部件之间的交互。如果把软件系统看成一幅图的话，计算部件就是其中的节点，而部件之间的交互就是节点之间的弧线。部件之间的连接可以被认为是一种连接器，比如过程调用、事件广播、数据库查询等等。正确的体系结构设计是软件系统成功的关键。

　　我们理解了软件工程的重要性以后，我们没有相应的工具，我们也很难很好的完成一个系统。在需求分析和设计阶段，我们需要什么样的工具呢？

　　当然最好是基于UML的CASE工具。当前比较流行的就是Rose，它是一个很好的分析和建立对象和对象关系的工具。在具体编码的时候，我们需要版本控制工具，MS的SourceSafe就是一个很好的版本管理工具和项目管理工具。具体的开发工具当然很多，但是如果你是一个对VC侵淫了多年的程序员，你一定会选择它，因为它会让你感到什么是真正的面向对象的编程，而你在用VB，PowerBuilder，Delphi时很少会有同样的感受。至于数据库模式构建，我一向是采用Sybase的S-Design，更好的工具就不知道了。

　　另外需要注意的是，我们需要建立文档编写的若干模板，以便开发人员按照这个模板编写规范的技术和说明文档。帮助文档可以用微软的HTML Help Workshop(hhw.exe)制作，你也可以编译成.chm格式，它打包了文本和图形，只有一个文件，使用和分发比较方便。最后，如果开发人员不是集中在一个地方的话，最好建立一个邮件列表，开发人员可以通过邮件系统讨论开发中的各项事宜。

五、软件开发方法综述

作为目录和文件版本化的补充，Subversion提供了对每一个版本化的目录和文件添加、修改和删除版本化的元数据的接口，我们用属性来表示这些元数据。我们可以认为它们是一个两列的表，附加到你的工作拷贝的每个条目上，映射属性名到任意的值。一般来说，属性的名称和值可以是你希望的任何值，限制就是名称必须是可读的文本，并且最好的一点是这些属性也是版本化的，就像你的文本内容文件，你可以像提交文本修改一样修改、提交和恢复属性修改，当你更新时也会接收到别人的属性修改。

在本小节，我们将会检验这个工具—不仅是对Subversion的用户，也对Subversion本身—对于属性的支持。你会学到与属性相关的svn子命令，和属性怎样影响你的普通Subversion工作流，希望你会感到Subversion的属性可以提高你的版本控制体验。

$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c
property 'copyright' set on 'calc/button.c'
$

$ svn propset license -F /path/to/LICENSE calc/button.c
property 'license' set on 'calc/button.c'
$

$ svn propedit copyright calc/button.c  ### exit the editor without changes
No changes to property 'copyright' on 'calc/button.c'
$

$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
property 'copyright' set on 'calc/Makefile'
property 'copyright' set on 'calc/button.c'
property 'copyright' set on 'calc/integer.c'
…
$

$ svn proplist calc/button.c
Properties on 'calc/button.c':
  copyright
  license
$ svn propget copyright calc/button.c
(c) 2003 Red-Bean Software

$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
  license : ================================================================
Copyright (c) 2003 Red-Bean Software.  All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions 
are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions, and the recipe for Fitz's famous
red-beans-and-rice.
…

$ svn propset license '' calc/button.c
property 'license' set on 'calc/button.c'
$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
  license : 
$

$ svn propdel license calc/button.c
property 'license' deleted from ''.
$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
$

$ svn propset svn:log '* button.c: Fix a compiler warning.' -r11 --revprop
property 'svn:log' set on repository revision '11'
$

$ svn status calc/button.c
 M     calc/button.c
$ svn diff calc/button.c
Property changes on: calc/button.c
___________________________________________________________________
Name: copyright
   + (c) 2003 Red-Bean Software

$

% svn update calc
M  calc/Makefile.in
 C calc/button.c
Updated to revision 143.
$ 

$ svn status calc
 C     calc/button.c
?      calc/button.c.prej
$ cat calc/button.c.prej 
prop 'linecount': user set to '1256', but update set to '1301'.
$

$ svn propset svn:ignore -F .cvsignore .
property 'svn:ignore' set on '.'
$

$ svn status calc
 M     calc/button.c
?      calc/calculator
?      calc/data.c
?      calc/debug_log
?      calc/debug_log.1
?      calc/debug_log.2.gz
?      calc/debug_log.3.gz

calculator
debug_log*

$ svn status
 M     calc
 M     calc/button.c
?      calc/data.c

$ svn status --no-ignore
 M     calc/button.c
I      calc/calculator
?      calc/data.c
I      calc/debug_log
I      calc/debug_log.1
I      calc/debug_log.2.gz
I      calc/debug_log.3.gz

Here is the latest report from the front lines.
$LastChangedDate$
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

$ svn propset svn:keywords "Date Author" weather.txt
property 'svn:keywords' set on 'weather.txt'
$

Here is the latest report from the front lines.
$LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

然而人们希望更人性化的标签名称，像release-1.0。他们也希望可以对一个子目录快照，毕竟，记住release-1.0是修订版本4822的某一小部分不是件很容易的事。

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/tags/release-1.0 \
      -m "Tagging the 1.0 release of the 'calc' project."

Committed revision 351.

$ ls
my-working-copy/

$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag

Committed revision 352.

这种情况下如何使用svn merge？记住这个命令比较两个目录树，然后应用比较结果到工作拷贝，所以要接受这种变化，你需要主干的工作拷贝，我们假设你有一个最初的主干工作拷贝（完全更新），或者是你最近取出了/calc/trunk的一个干净的工作拷贝。

但是要哪两个树进行比较呢？乍一看，回答很明确，只要比较最新的主干与分支。但是你要意识到—这个想法是错误的，伤害了许多新用户！因为svn merge的操作很像svn diff，比较最新的主干和分支树不仅仅会描述你在分支上所作的修改，这样的比较会展示太多的不同，不仅包括分支上的增加，也包括了主干上的删除操作，而这些删除根本就没有在分支上发生过。

为了表示你的分支上的修改，你只需要比较分支的初始状态与最终状态，在你的分支上使用svn log命令，你可以看到你的分支在341版本建立，你的分支最终的状态用HEAD版本表示，这意味着你希望能够比较版本341和HEAD的分支目录，然后应用这些分支的修改到主干目录的工作拷贝。

$ svn log --verbose --stop-on-copy \
          http://svn.example.com/repos/calc/branches/my-calc-branch
…
------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

$

如下是最终的合并过程，然后：

$ cd calc/trunk
$ svn update
At revision 405.

$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn status
M   integer.c
M   button.c
M   Makefile

# ...examine the diffs, compile, test, etc...

$ svn commit -m "Merged my-calc-branch changes r341:405 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 406.

再次说明，日志信息中详细描述了合并到主干的的修改范围，记住一定要这么做，这是你以后需要的重要信息。

举个例子，你希望在分支上继续工作一周，来进一步加强你的修正，这时版本库的HEAD版本是480，你准备好了另一次合并，但是我们在“合并的最佳实践”一节提到过，你不想合并已经合并的内容，你只想合并新的东西，技巧就是指出什么是“新”的。

第一步是在主干上运行svn log察看最后一次与分支合并的日志信息：

$ cd calc/trunk
$ svn log
…
------------------------------------------------------------------------
r406 | user | 2004-02-08 11:17:26 -0600 (Sun, 08 Feb 2004) | 1 line

Merged my-calc-branch changes r341:405 into the trunk.
------------------------------------------------------------------------
…

阿哈！因为分支上341到405之间的所有修改已经在版本406合并了，现在你只需要合并分支在此之后的修改—通过比较406和HEAD。

$ cd calc/trunk
$ svn update
At revision 480.

# We notice that HEAD is currently 480, so we use it to do the merge:

$ svn merge -r 406:480 http://svn.example.com/repos/calc/branches/my-calc-branch
U   integer.c
U   button.c
U   Makefile

$ svn commit -m "Merged my-calc-branch changes r406:480 into the trunk."
Sending        integer.c
Sending        button.c
Sending        Makefile
Transmitting file data ...
Committed revision 481.

现在主干有了分支上第二波修改的完全结果，此刻，你可以删除你的分支（我们会在以后讨论），或是继续在你分支上工作，重复这个步骤。

$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
M  integer.c

$ svn diff
…
# verify that the change is removed
…

$ svn commit -m "Undoing change committed in r303."
Sending        integer.c
Transmitting file data .
Committed revision 350.

$ cd parent-dir
$ svn log --verbose
…
------------------------------------------------------------------------
r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
Changed paths:
   D /calc/trunk/real.c
   M /calc/trunk/integer.c

Added fast fourier transform functions to integer.c.
Removed real.c because code now in double.c.
…

$ svn copy --revision 807 \
           http://svn.example.com/repos/calc/trunk/real.c ./real.c

$ svn status
A  +   real.c

$ svn commit -m "Resurrected real.c from revision 807, /calc/trunk/real.c."
Adding         real.c
Transmitting file data .
Committed revision 1390.

$ cd trunk-working-copy

$ svn update
At revision 1910.

$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
            http://svn.example.com/repos/calc/branches/mybranch@1910
U  real.c
U  integer.c
A  newdirectory
A  newdirectory/newfile
…

默认情况下，钩子的子目录中包含各种版本库钩子模板。

$ ls repos/hooks/
post-commit.tmpl          pre-revprop-change.tmpl
post-revprop-change.tmpl  start-commit.tmpl
pre-commit.tmpl           

对每种Subversion版本库支持的钩子的都有一个模板，通过查看这些脚本的内容，你能看到是什么事件触发了脚本及如何给传脚本传递数据。同时，这些模版也是如何使用这些脚本，结合Subversion支持的工具来完成有用任务的例子。要实际安装一个可用的钩子，你需要在repos/hooks目录下安装一些与钩子同名（如 start-commit或者post-commit）的可执行程序或脚本。

在Unix平台上，这意味着要提供一个与钩子同名的脚本或程序（可能是shell 脚本，Python 程序，编译过的c语言二进制文件或其他东西）。当然，脚本模板文件不仅仅是展示了一些信息—在Unix下安装钩子最简单的办法就是拷贝这些模板，并且去掉.tmpl扩展名，然后自定义钩子的内容，确定脚本是可运行的。Windows用文件的扩展名来决定一个程序是否可运行，所以你要使程序的基本名与钩子同名，同时，它的扩展名是Windows系统所能辨认的，例如exe、com和批处理的bat。

目前Subversion有已实现了五种钩子：

Subversion会试图以当前访问版本库的用户身份执行钩子。通常，对版本库的访问总是通过Apache HTTP服务器和mod_dav_svn进行，因此，执行钩子的用户就是运行Apache的用户。钩子本身需要具有操作系统级的访问许可，用户可以运行它。另外，其它被钩子直接或间接使用的文件或程序（包括Subversion版本库本身）也要被同一个用户访问。换句话说，要注意潜在的访问控制问题，它可能会让你的钩子无法按照你的目的顺利执行。

首先确认系统中是否安装CVS服务：
[root@localhost /]# rpm -qa|grep cvs
cvs-1.11.2-cvshome.7x.1
如果命令输出类似于上面的输出则说明系统已经安装有cvs，否则就需要从安装光盘中安装cvs的rpm包，或者到http://www.cvshome.org下载。

1、建立 CVSROOT

目录，因为这里涉及到用户对CVSROOT里的文件读写的权限问题，所以比较简单的方法是建立一个组，然后再建立一个属于该组的帐户，而且以后有读写权限的用户都要属于该组。假设我们建一个组叫cvs，用户名是cvsroot。建组和用户的命令如下

#groupadd cvs
#useradd -g cvs -G cvs -d /home/cvsroot cvsroot

生成的用户宿主目录在/home/cvsroot（根据自己的系统调整）

2、建立CVS仓库，用cvsroot 用户登陆，用下面命令：

$cvs -d /home/cvsroot init

3、仍然是 cvsroot 用户，修改 /home/cvsroot （CVSROOT）的权限，赋与同组人有读写的权限：　

$chmod 775 -R /home/cvsroot

4、用root登录，加入cvs服务(我的redhath7.3缺省就有cvs服务,所以不用加)

vi /etc/services
cvspserver 2401/tcp #pserver cvs service
cvspserver 2401/udp #pserver cvs service

cvs服务由inted来唤起,因此需要改动inetd提供的服务,如果你的redhat使用的是inetd 方式则在文件/etc/inetd.conf中加入如下的内容:cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver

我的redhat7.3使用的是xinetd方式,所以在xinetd.d目录下添加需要启动的服务:
cd /etc/xinetd.d
vi cvspserver
文件内容:
service cvspserver
{
  disable = no
  flags = REUSE
  socket_type = stream
  wait = no
  user = cvsroot
  server = /usr/bin/cvs
  server_args = -f --allow-root=/home/cvsroot pserver
  log_on_failure += USERID
}

重新启动inetd或者xinetd:
 /etc/rc.d/init.d/xinetd restart

检查cvspserver服务是否已经启动
[root@localhost /]# netstat -lnp|grep 2401
tcp        0      0 0.0.0.0:2401            0.0.0.0:*               LISTEN      1041/xinetd 
则说明cvs服务器已经运行。

二、管理CVS服务器

服务器可以用了，现在大家最关心的就是如何管理服务器，比如，我想让一些人有读和/或写 CVS 仓库的权限，但是不想给它系统权限怎么办呢？

不难，在 cvs 管理员用户（在我这里是 cvsroot 用户）的家目录里有一个 CVSROOT 目录，这个目录里有三个配置文件，passwd, readers, writers，我们可以通过设置这三个文件来配置 CVS 服务器，下面分别介绍这几个文件的作用：

passwd：cvs 用户的用户列表文件，它的格式很象 shadow 文件：

{cvs 用户名}:[加密的口令]:[等效系统用户名]

readers：有 cvs 读权限的用户列表文件。就是一个一维列表。在这个文件中的用户对 cvs只有读权限。

writers：有 cvs 写权限的用户的列表文件。和 readers 一样，是一个一维列表。在这个文件中的用户对 cvs 有写权限。

上面三个文件在缺省安装的时候可能都不存在，需要我们自己创建，好吧，现在还是让我们用一个例子来教学吧。假设我们有下面几个用户需要使用 cvs：

laser, gumpwu, henry, betty, anonymous。

其中 laser 和 gumpwu 是系统用户，而 henry, betty, anonymous 我们都不想给系统用户权限，并且 betty 和 anonymous 都是只读用户，而且 anonymous 更是连口令都没有。

然后编辑 cvs 管理员家目录里 CVSROOT/passwd 文件（cvsroot用户），加入下面几行：

laser:$xxefajfka;faffa33:cvsroot
gumpwu:$ajfaal;323r0ofeeanv:cvsroot
henry:$fajkdpaieje:cvsroot
betty:fjkal;ffjieinfn/:cvsroot
anonymous::cvsroot

注意：上面的第二个字段（分隔符为 :）是密文口令。

密码可以有以下方法生成
vi /home/cvsroot/passwdgen.pl
文件内容:
#!/usr/bin/perl
srand (time());
my $randletter = "(int (rand (26)) + (int (rand (1) + .5) % 2 ? 65 : 97))";
my $salt = sprintf ("%c%c", eval $randletter, eval $randletter);
my $plaintext = shift;
my $crypttext = crypt ($plaintext, $salt);
print "${crypttext}\n";

如果需要密码为:some,则敲入:
./passwdgen.pl some
（注意passwdgen.pl要先设为可执行）
回车即可得到加密密码,用其替换passwd文件中的passwd部分就可以了

编辑 readers 文件，加入下面几行：
anonymous
betty

编辑 writers 文件，加入下面几行：

laser
gumpwu
henry

注意：writers中的用户不能在readers中，要不然不能上传更新文件。

对于使用CVS的用户要修改它的环境变量，例如laser用户的环境变量，打开/home/laser（laser的宿主目录）下的.bash_profile文件，加入

CVSROOT=/home/cvsroot
export CVSROOT

用laser登陆就可以建立CVS项目，如果要root使用，可以修改/etc/profile文件。

现在我们各项都设置好了，那么怎么用呢，我在这里写一个最简单的（估计也是最常用的）命令介绍：

首先，建立一个新的CVS项目，一般我们都已经有一些项目文件了，这样我们可以用下面步骤生成一个新的CVS项目：

进入到你的已有项目的目录，比如叫 cvstest：

$cd  cvstest
运行命令：
$cvs import -m "this is a cvstest project" cvstest     v_0_0_1     start

说明：import 是cvs的命令之一，表示向cvs仓库输入项目文件。 -m参数后面的字串是描述文本，随便写些有意义的东西，如果不加 -m 参数，那么cvs会自动运行一个编辑器（一般是vi，但是可以通过修改环境变量EDITOR来改成你喜欢用的编辑器。）让你输入信息，cvstest 是项目名称（实际上是仓库名，在CVS服务器上会存储在以这个名字命名的仓库里。）
v_0_0_1是这个分支的总标记。没啥用（或曰不常用。）
start 是每次 import 标识文件的输入层次的标记，没啥用。
这样我们就建立了一个CVS仓库了。

　　建立CVS仓库的文件夹应该是“干净”的文件夹，即只包括源码文件和描述的文件加，而不应该包括编译过的文件代码等！

内容摘要：

CVS是一个C/S系统，多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。工作模式如下：

       CVS服务器（文件版本库）
     /     |       \
     （版 本 同 步）
   /       |         \
开发者1  开发者2   开发者3

作为一般开发人员挑选2,6看就可以了，CVS的管理员则更需要懂的更多一些，最后还简单介绍了一些Windows下的cvs客户端使用，CVS远程用户认证的选择及与BUG跟踪系统等开发环境的集成问题。

1. CVS环境初始化：CVS环境的搭建 管理员
2. CVS的日常使用：日常开发中最常用的CVS命令， 开发人员 管理员
3. CVS的分支开发：项目按照不同进度和目标并发进行 管理员
4. CVS的用户认证：通过SSH的远程用户认证，安全，简单 管理员
5. CVSWEB：CVS的WEB访问界面大大提高代码版本比较的效率 管理员
6. CVS TAG：将$Id$ 加入代码注释中，方便开发过程的跟踪开发人员
7. CVS vs VSS: CVS和Virsual SourceSafe的比较 开发人员 管理员
8. WinCVS: 通过SSH认证的WinCVS认证设置
9. 基于CVSTrac的小组开发环境搭建：通过CVSTrac实现web界面的CVS用户管理,集成的BUG跟踪和WIKI交流
10. CVS中的用户权限管理：基于系统用户的CVS权限管理和基于CVSROOT/passwd的虚拟用户管理
    

一个系统20%的功能往往能够满足80%的需求，CVS也不例外，以下是CVS最常用的功能，可能还不到它全部命令选项的20%，作为一般开发人员平时会用cvs update和cvs commit就够了，更多的需求在实际应用过程中自然会出现，不时回头看看相关文档经常有意外的收获。

CVS环境初始化

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 admin -kkv new_file.css

然后确认修改并注释
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 -d :pserver:cvs_user_name@cvs.server.address:/path/to/cvsroot login
例子：
cvs -d :pserver:cvs@samba.org:/cvsroot login

不是很安全，因此一般是作为匿名只读CVS访问的方式。从安全考虑，通过系统本地帐号认证并通过SSH传输是比较好的办法，通过在客户机的 /etc/profile里设置一下内容：
CVSROOT=:ext:$USER@cvs.server.address#port:/path/to/cvsroot CVS_RSH=ssh; export CVSROOT CVS_RSH
所有客户机所有本地用户都可以映射到CVS服务器相应同名帐号了。

比如:

CVS服务器是192.168.0.3，上面CVSROOT路径是/home/cvsroot，另外一台开发客户机是192.168.0.4，如果 tom在2台机器上都有同名的帐号，那么从192.168.0.4上设置了：
export CVSROOT=:ext:tom@192.168.0.3:/home/cvsroot
export CVS_RSH=ssh
tom就可以直接在192.168.0.4上对192.168.0.3的cvsroot进行访问了（如果有权限的话）
cvs checkout project_name
cd project_name
cvs update
...
cvs commit

如果CVS所在服务器的SSH端口不在缺省的22，或者和客户端与CVS服务器端SSH缺省端口不一致，有时候设置了：
:ext:$USER@test.server.address#port:/path/to/cvsroot

仍然不行，比如有以下错误信息：
ssh: test.server.address#port: Name or service not known
cvs [checkout aborted]: end of file from server (consult above messages if any)

解决的方法是做一个脚本指定端口转向（不能使用alias，会出找不到文件错误）：
创建一个/usr/bin/ssh_cvs文件，假设远程服务器的SSH端口是非缺省端口：34567
#!/bin/sh
/usr/bin/ssh -p 34567 "$@"
然后：chmod +x /usr/bin/ssh_cvs
并CVS_RSH=ssh_cvs; export CVS_RSH

注意：port是指相应服务器SSH的端口，不是指cvs专用的pserver的端口

CVSWEB：提高文件浏览效率

使用的样例可以看：http://www.freebsd.org/cgi/cvsweb.cgi

CVSWEB的下载：CVSWEB从最初的版本已经演化出很多功能界面更丰富的版本，这个是我个人感觉安装设置比较方便的：
原先在：http://www.spaghetti-code.de/software/linux/cvsweb/，但目前已经删除，目前仍可以在本站下载CVSWEB，其实最近2年FreeBSD的CVSWeb项目已经有了更好的发展吧，而当初没有用FreeBSD那个版本主要就是因为没有彩色的文件Diff功能。
下载解包：
tar zxf cvsweb.tgz
把配置文件cvsweb.conf放到安全的地方（比如和apache的配置放在同一个目录下），
修改：cvsweb.cgi让CGI找到配置文件：
$config = $ENV{'CVSWEB_CONFIG'} || '/path/to/apache/conf/cvsweb.conf';

转到/path/to/apache/conf下并修改cvsweb.conf：

1. 修改CVSROOT路径设置：
   %CVSROOT = (
   'Development' => '/path/to/cvsroot', #<==修改指向本地的CVSROOT
   );
2. 缺省不显示已经删除的文档：
   "hideattic" => "1",#<==缺省不显示已经删除的文档
3. 在配置文件cvsweb.conf中还可以定制页头的描述信息，你可以修改$long_intro成你需要的文字

CVSWEB可不能随便开放给所有用户，因此需要使用WEB用户认证：
先生成 passwd:
/path/to/apache/bin/htpasswd -c cvsweb.passwd user

修改httpd.conf: 增加
<Directory "/path/to/apache/cgi-bin/cvsweb/">
AuthName "CVS Authorization"
AuthType Basic
AuthUserFile /path/to/cvsweb.passwd
require valid-user
</Directory>

CVS TAGS: $Id: cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $

几个常用的缺省文件：
default.php
<?php
/*
 * Copyright (c) 2002 Company Name.
 * $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $
 */

?>
====================================
Default.java: 注意文件头一般注释用 /* 开始 JAVADOC注释用 /** 开始的区别
/*
 * Copyright (c) 2002 MyCompany Name.
 * $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $
 */

package com.mycompany;

import java.;

/**
 * comments here
 */
public class Default {
    /**
     * Comments here
     * @param
     * @return
     */
    public toString() {

    }
}
====================================
default.pl:
#!/usr/bin/perl -w
# Copyright (c) 2002 Company Name.
# $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $

# file comments here

use strict;

CVS vs VSS

CVS没有文件锁定模式，VSS在check out同时，同时记录了文件被导出者锁定。

CVS的update和commit， VSS是get_lastest_version和check in

对应VSS的check out/undo check out的CVS里是edit和unedit

在CVS中，标记自动更新功能缺省是打开的，这样也带来一个潜在的问题，就是不用-kb方式添加binary文件的话在cvs自动更新时可能会导致文件失效。

$Header: /home/cvsroot/tech/cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $ $Date: 2003/11/09 07:57:11 $这样的标记在Virsual SourceSafe中称之为Keyword Explaination，缺省是关闭的，需要通过OPITION打开，并指定需要进行源文件关键词扫描的文件类型：*.txt,*.java, *.html...

对于Virsual SourceSafe和CVS都通用的TAG有：
$Header: /home/cvsroot/tech/cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $
$Author: chedong $
$Date: 2003/11/09 07:57:11 $
$Revision: 1.9 $

我建议尽量使用通用的关键词保证代码在CVS和VSS都能方便的跟踪。

WinCVS

cvs Windows客户端：目前稳定版本为1.2
http://cvsgui.sourceforge.net
ssh Windows客户端
http://www.networksimplicity.com/openssh/

安装好以上2个软件以后：
WinCVS客户端的admin==>preference设置
1 在general选单里
设置CVSROOT： username@192.168.0.123:/home/cvsroot
设置Authorization: 选择SSH server

2 Port选单里
钩上：check for alternate rsh name
并设置ssh.exe的路径，缺省是装在 C:\Program Files\NetworkSimplicity\ssh\ssh.exe

然后就可以使用WinCVS进行cvs操作了，所有操作都会跳出命令行窗口要求你输入服务器端的认证密码。

当然，如果你觉得这样很烦的话，还有一个办法就是生成一个没有密码的公钥/私钥对，并设置CVS使用基于公钥/私钥的SSH认证（在general 选单里）。

可以选择的diff工具：examdiff
下载：
http://www.prestosoft.com/examdiff/examdiff.htm
还是在WinCVS菜单admin==>preference的WinCVS选单里
选上：Externel diff program
并设置diff工具的路径，比如：C:\Program Files\ed16i\ExamDiff.exe
在对文件进行版本diff时，第一次需要将窗口右下角的use externel diff选上。

基于CVSTrac的小组开发环境搭建

这里首先说一下CVS的pserver模式下的用户认证，CVS的用户认证服务是基于inetd中的：
cvspserver stream tcp nowait apache /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver
一般在2401端口（这个端口号很好记：49的平方）

CVS用户数据库是基于CVSROOT/passwd文件，文件格式：
[username]:[crypt_password]:[mapping_system_user]
由于密码都用的是UNIX标准的CRYPT加密，这个passwd文件的格式基本上是apache的htpasswd格式的扩展（比APACHE的 PASSWD文件多一个系统用户映射字段），所以这个文件最简单的方法可以用
apache/bin/htpasswd -b myname mypassword
创建。注意：通过htpasswd创建出来的文件会没有映射系统用户的字段
例如：
new:geBvosup/zKl2
setup:aISQuNAAoY3qw
test:hwEpz/BX.rEDU

映射系统用户的目的在于：你可以创建一个专门的CVS服务帐号，比如用apache的运行用户apache，并将/home/cvsroot目录下的所有权限赋予这个用户，然后在passwd文件里创建不同的开发用户帐号，但开发用户帐号最后的文件读写权限都映射为apache用户，在SSH模式下多个系统开发用户需要在同一个组中才可以相互读写CVS库中的文件。

进一步的，你可以将用户分别映射到apache这个系统用户上。
new:geBvosup/zKl2:apache
setup:aISQuNAAoY3qw:apache
test:hwEpz/BX.rEDU:apache

CVSTrac很好的解决了CVSROOT/passwd的管理问题，而且包含了BUG跟踪报告系统和集成WIKIWIKI交流功能等，使用的 CGI方式的安装，并且基于GNU Public License：

在inetd里加入cvspserver服务：
cvspserver stream tcp nowait apache /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver

xietd的配置文件：%cat cvspserver
service cvspserver
{
disable = no
socket_type = stream
wait = no
user = apache
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot pserver
log_on_failure += USERID
}

注意：这里的用户设置成apache目的是和/home/cvsroot的所有用户一致，并且必须让这个这个用户对/home/cvsroot/下的 CVSROOT/passwd和cvstrac初始化生成的myproj.db有读取权限。

安装过程

1. 下载：可以从http://www.cvstrac.org 下载
   我用的是已经在Linux上编译好的应用程序包：cvstrac-1.1.2.bin.gz，
   %gzip -d cvstrac-1.1.2.bin.gz
   %chmod +x cvstrac-1.1.2.bin
   #mv cvstarc-1.1.1.bin /usr/bin/cvstrac
   如果是从源代码编译：
   从 http://www.sqlite.org/download.html 下载SQLITE的rpm包：
   rpm -i sqlite-devel-2.8.6-1.i386.rpm
   从 ftp://ftp.cvstrac.org/cvstrac/ 下载软件包
   解包，假设解包到/home/chedong/cvstrac-1.1.2下，并规划将cvstrac安装到/usr/local/bin目录下， cd /home/chedong/cvstrac-1.1.2 编辑linux-gcc.mk:
   修改：
   SRCDIR = /home/chedong/cvstrac-1.1.2
   INSTALLDIR = /usr/local/bin
   然后
   mv linux-gcc.mk Makefile
   make
   #make install
   
   
2. 初始化cvstrac数据库：假设数据库名是 myproj
   在已经装好的CVS服务器上（CVS库这时候应该已经是初始化好了，比如：cvs init初始化在/home/cvsroot里），运行一下
   %cvstrac init /home/cvsroot myproj
   运行后，/home/cvsroot里会有一个的myproj.db库，使用CVSTRAC服务，/home/cvsroot/myproj.db /home/cvsroot/CVSROOT/readers /home/cvsroot/CVSROOT/writers /home/cvsroot/CVSROOT/passwd这几个文件对于web服务的运行用户应该是可写的，在RedHat8上，缺省就有一个叫 apache用户和一个apache组，所以在httpd.conf文件中设置了用apache用户运行web服务：
   User apache
   Group apache，
   然后设置属于apache用户和apache组
   #chown -R apache:apache /home/cvsroot
   -rw-r--r-- 1 apache apache 55296 Jan 5 19:40 myproj.db
   drwxrwxr-x 3 apache apache 4096 Oct 24 13:04 CVSROOT/
   drwxrwxr-x 2 apache apache 4096 Aug 30 19:47 some_proj/
   此外还在/home/cvsroot/CVSROOT中设置了：
   chmod 664 readers writers passwd
   
3. 在apche/cgi-bin目录中创建脚本cvstrac:
   #!/bin/sh
   /usr/bin/cvstrac cgi /home/cvsroot
   设置脚本可执行：
   chmod +x /home/apache/cgi-bin/cvstrac
   
4. 从 http://cvs.server.address/cgi-bin/cvstrac/myproj 进入管理界面
   缺省登录名：setup 密码 setup
   对于一般用户可以从：
   http://cvs.server.address/cgi-bin/cvstrac/myproj
5. 在setup中重新设置了CVSROOT的路径后，/home/cvsroot
   如果是初次使用需要在/home/cvsroot/CVSROOT下创建passwd, readers, writers文件
   touch passwd readers writers
   然后设置属于apache用户，
   chown apache.apache passwd readers writers
   这样使用setup用户创建新用户后会同步更新CVSROOT/passwd下的帐号
   

修改登录密码，进行BUG报告等，
更多使用细节可以在使用中慢慢了解。

对于前面提到的WinCVS在perference里设置：
CVSROOT栏输入：username@ip.address.of.cvs:/home/cvsroot
Authenitication选择：use passwd file on server side
就可以了从服务器上进行CVS操作了。

CVS的用户权限管理

CVS的权限管理分2种策略：

• 基于系统文件权限的系统用户管理：适合多个在Linux上使用系统帐号的开发人员进行开发。
• 基于CVSROOT/passwd的虚拟用户管理：适合多个在Windows平台上的开发人员将帐号映射成系统帐号使用。

Linux上通过ssh连接CVS服务器的多个开发人员：通过都属于apache组实现文件的共享读写
开发人员有开发服务器上的系统帐号：sysuser1 sysuser2，设置让他们都属于apache组，因为通过cvs新导入的项目都是对组开放的：664权限的，这样无论那个系统用户导入的项目文件，只要文件的组宿主是apache，所有其他同组系统开发用户就都可以读写；基于ssh远程认证的也是一样。

   apache(system group)
/            |           \
sysuser1   sysuser2     sysuser3

Windows上通过cvspserver连接CVS服务器的多个开发人员：通过在passwd文件种映射成 apache用户实现文件的共享读写
他们的帐号通过CVSROOT/passwd和readers writers这几个文件管理；通过cvstrac设置所有虚拟用户都映射到apache用户上即可。

   apache(system user)
/            |            \
windev1     windev2      windev3             

利用CVS WinCVS/CVSWeb/CVSTrac 构成了一个相对完善的跨平台工作组开发版本控制环境。

相关资源：

CVS HOME：
http://www.cvshome.org

CVS FAQ：
http://www.loria.fr/~molli/cvs-index.html

相关网站:
http://directory.google.com/Top/Computers/Software/Configuration_Management/Tools/Concurrent_Versions_System/

CVS--并行版本系统
http://www.soforge.com/cvsdoc/zh_CN/book1.html

CVS 免费书:
http://cvsbook.red-bean.com/

CVS命令的速查卡片 refcards.com/refcards/cvs/

WinCVS:
http://cvsgui.sourceforge.net/

CVSTrac: A Web-Based Bug And Patch-Set Tracking System For CVS
http://www.cvstrac.org

StatCVS：基于CVS的代码统计工具：按代码量，按开发者的统计表等
http://sourceforge.net/projects/statcvs

图1.安装Subclipse插件

图2.添加一个仓库定义

　　(三) 检出（Check Out）一个工程

　　一旦建立一个仓库，你就可以在SVN Repository视图中浏览所有的内容(见图3)。我们后面将会看到，这个视图是一种与Subversion进行交互的非常方便的方式。

图3.SVN Repository视图。

　　现在，让我们把一个工程检出到你的Eclipse工作区中。这只需选择你需要的Subversion仓库，打开上下文菜单，并且选择"Checkout"即可。这将打开一个具有两个选项的向导：

　　· Check out as a Project configured using the New Project Wizard-这个选项打开新工程向导，这可以让你使用内建的Eclipse工程类型配置工程。这个选项通常是最好用的，因为它让你使用相同的工程模板和配置屏幕，而当你创建一个常规工程时你经常使用它们。

　　· Check out as a Project in the Workspace-这个选项简单地在你的包含检出源码的工作区中创建一个Eclipse工程。

　　在以上两种情况下，你仍然需要更新工程的构建路径，因为在检出该工程源码之前，Eclipse不能确定这些Java源码所在的位置。

　　(四) 把一个新工程导入到仓库中

　　如果你只是启动了一个新的工程，那么你需要把它导入到Subversion仓库。Subclipse提供了一种方便的方式来直接从你的IDE内部实现这一点。为此，只需要从Package Explorer视图下选择你的工程，并且在上下文菜单中选择"Team>Share Project"。你可以使用现有仓库之一或创建一新的仓库定义。在你指定仓库和工程名之后，你能指定你想放到仓库中的文件和目录并且提供一个初始注释(见图4)。这种方法特别有用，因为它让你有选择地导入仅由Subversion管理的文件，即使该工程还包含其它文件（例如生成的类，临时文件或其它不是必需的内容等）。

图4.把一个工程导入到一个Subversion仓库中

图5.大多数Subversion命令能被经由Team菜单存取 图6.你可以在Package Explorer中看到本地文件的状态

图7.与仓库保持同步

图8.把一个Subversion属性添加到一个文件中

图9.创建一个新的branch或tag

图10.历史资源

　　Subversion (SVN)是一个版本控制系统，是CVS的极具竞争力的替代品。它支持CVS所缺少的一些重要特性，比如版本化的重命名、目录和元数据；还支持原子提交和通过HTTP/HTTPS的远程访问。许多开源项目使用Subversion作为版本控制系统，其中包括BEA的dev2dev CodeShare 站点上的项目。 有一个简短的指南介绍了如何为CodeShare建立支持Windows的命令行SVN客户端和Tortiose SVN。然而，使用自己的IDE中的Subversion库才有意义。

　　 本文描述如何在Eclipse IDE中使用Subversion，具体来说，介绍了Subclipse插件的安装和使用。顺着这个思路，我还将展示如何使用产生的配置来修改或扩展Subclipse插件本身。

安装Subclipse

　　安装Subclipse的最好方法是使用Eclipse Update Manager。在Eclipse 3.1中，它位于Help -> Software Updates -> Find and Install...菜单下。请选择Search，查找要安装的新特性，并以http://subclipse.tigris.org/update作为URL添加New Remote Site。

图1：使用Eclipse Update Manager安装Subclipse

　　 扫描完更新后，您会看到一个可用特性的列表。我写这篇文章时，Subclipse 0.9.33是最新的更新版本。

图2：选择最新的Subclipse更新版本

　　 在接下来的界面中，会请求用户接受许可证并选择安装位置。建议不要将新插件（包括Subclipse）安装在默认的Eclipse安装目录下，最好将其放在一个外部扩展位置中。这会使手动卸载这些特性更加容易，如果需要的话；同时也使插件可以在多个版本的Eclipse安装之间共享，比如发行版、尝鲜(early access)稳定版（M1、M2等等）和集成IDE版本。

图3：选择安装位置

　　 此时，Update Manager已下载并安装了所选特性，然后请求重启Eclipse。

　　 一旦重启Eclipse，用户就会在Preference对话框中看到一个新的SVN区域，并且还会看到有关Subversion活动的其他视图。可以使用Window -> Show View -> Other...菜单将这些视图添加到Java Perspective中。

图4：添加关于Subversion活动的视图

　　 我通常将SVN Repository视图添加到Quick Views中，而将SVN Resource History添加到位于Java Perspective工作区底部的一个标签组中。这样，在开发过程中，这两个视图就近便可用了，同时也便于利用拖放来运行某些任务，比如“获得资源历史”（从诸如Navigator、Package Explorer、SVN Repository和Synchronize之类的面向资源的视图到SVN Resource History视图）。

在Subclipse中配置SVN接口

　　可以配置Subversion服务器来使用下列协议之一：

• SVN协议，一种轻量级的有状态协议，由独立的Subversion服务器（svnserve）所使用。安全版本svn+ssh使用基于ssh的隧道。
• http协议，基于WebDAV扩展，通常被作为模块部署在Apache HTTP服务器上。安全版本使用https，dev2dev CodeShare上的Subclipse安装使用的就是该协议。
• file协议，用于访问本地可用的Subversion库（例如，共享驱动器上的Subversion库），它是最少选择的库。

　　Subclipse使用专门的适配器抽象化来利用上述协议。可以在Window -> Preferences -> Team -> SVN对话框的插件属性中选择下列适配器中的一种。

图5：选择适配器

　　 每一种适配器都有其自身的优点：

• JavaSVN是惟一完全基于Java的Subclipse客户端，是默认支持的。注意，JavaSVN不支持file:///协议。
• JavaHL是包装本地Subclipse API的瘦包装器。该适配器是为Win32平台预构建的，但是在其他所有的平台上必须手动构建（除非Unix发行版中包含它）。
• 命令行适配器，只有在不能安装JavaHL并且Subclipse库使用file:///协议时才可以使用。

　　大多数情况下都可以使用JavaSVN；只有需要时才选择JavaHL或命令行适配器。参考资料小节中的链接可以帮助解决特定用例，如配置HTTP代理、SSL客户端证书，等等。

连接到CodeShare上的SVN库

　　现在就可以连接到Subversion库了。对于dev2dev CodeShare上的项目，可以在访问选项页面中看到一个库的URL，可以从Version控制项目菜单中找到该页面。 这里是一个例子 。CodeShare SVN服务器要求用户使用的用户名和口令与其在dev2dev网站上所使用的相同。

图6：连接到Subversion库

　　 如果连接参数设置正确，就可以看到一个SSL证书确认对话框。

图7：接受SSL证书

　　 接受证书后，应该就可以浏览库并查看现有项目。

图8：查看SVN库中的现有项目

　　 现在已经准备好，要开始使用Subversion和Subclipse插件了！

查看SVN中的现有项目

　　在SVN Repository视图中可以看到，在许多CodeShare项目以及使用Subversion的其他项目中都可以看到一种共同的布局，通常如下所示：

  https://xjms-ra.projects.dev2dev.bea.com/svn/xjms-ra
   +-- branches
       +-- www
       +-- xjms-ra
           +-- mqseries (work in progress)
           +-- activemq
   +-- tags
       +-- xjms-ra
           +-- 0.0.1 (stable versions or releases)
           +-- 0.0.2
   +-- trunk
       +-- www     (project web site)
       +-- xjms-ra (project source)

　　trunk文件夹中包含主线开发源代码；tags文件夹中包含稳定版或发行版；branches文件夹中包含来自替代开发线上的代码。在Subversion中，标签和分支仅仅是选中的源代码快照的版本化副本。若想获得更多详细内容，请参阅Subversion book。

　　 可以在SVN Repository视图中选择当前项目的主线或者特定的标签或分支，并从弹出菜单中选择Check Out As...动作。接着就会出现一个指导性的标准New Project Wizard，它允许用户选择项目类型（例如，Java或Simple Project）、项目名称和位置，并在需要时配置Java build路径。

为新的CodeShare项目配置SVN库

　　版本控制库是任何项目的基础架构的重要部分，对于开源项目（包括CodeShare上的项目）而言，它还在开发人员与其他社区成员之间的交流中起着重要作用。例如，它允许终端用户为最新的代码捐献补丁，并为重要的修复提供早期更新机制。由于它的重要作用，为一个新项目配置SVN库并从一开始就将所有的项目代码置于版本控制之下就显得非常重要了。

　　 创建了新CodeShare项目之后，SVN库就包含了trunk、tags和branches文件夹，以及trunk下的www模块，它包含项目Web首页的index.html文件。可以在SVN Repository视图中验证这些，并使用该视图中的弹出菜单上的动作创建缺少的文件夹。

　　 我们假设所有的源代码、build脚本、文档和其他项目资源被组织为一个Eclipse项目，那么就可以在Package Explorer或Navigator视图中使用弹出菜单中的Team -> Share Project...动作。Share Project Wizard会要求用户选择SVN库类型，然后在下一个页面中，可以选择一个现有库或配置一个新库。

图9：在Share Project Wizard中选择SVN库类型

　　 在接下来的界面中指定模块名。为了与CodeShare项目布局相匹配，我们应该在trunk文件夹下创建模块，因此，指定trunk/<project name>作为模块名，比如trunk/xjms-ra。

图10：指定模块名

　　 经过确认后，Subclipse会创建模块，并将所有的项目文件导入SVN库。

使用SVN库

　　当项目连接到SVN库以后，在Package Explorer和Navigator视图中会弹出一个Team菜单，显示特定于Subversion的全部动作。可以直接运行Commit、Update、Add to svn:ignore，以及Version Control with Subversion一书中所描述的其他动作。该书中的内容也可以在Help -> Help Contents -> Version Control with Subversion下的Eclipse帮助系统中找到。

　　 Subclipse插件还允许使用Eclipse的Team Synchronize视图，它可以使用户从库中清楚地观察到哪些项将要提交、哪些项已经被其他开发人员更改并需要更新。从这个Synchronize视图中还可以执行大多数的SVN命令。

　　 可以使用弹出的Team -> Synchronize with Repository菜单或位于主工具栏上的Synchronize...向导按钮将项目或工作集添加到Synchronize视图中。如果看不到该按钮，那么请将Team命令添加到当前视图中；可以使用Customize Perspective对话框添加，该对话框可从主工具栏上的弹出菜单中获得（单击任意空白处），然后，使用Window -> Save Perspective As...菜单以相同的名称保存透视图。

图11：将命令组添加到当前透视图中

　　 在工具栏下拉菜单中选择Synchronize...动作来启动向导。在第一个界面中，它又让用户选择SVN版本跟踪系统，然后会显示标准资源选择面板，用户可以选择同步整个工作区，也可以选择某组项目或者一个指定的工作集。

图12：同步工作区、工作集或选中的资源

　　 一旦完成创建，Synchronize视图就可以使用版本控制系统安排自动刷新的时间。可以通过Synchronize视图菜单中的Schedule...菜单对其进行配置。这将有助于用户保持最新状态，还可以看到其他开发人员所做的所有改动。

图13：安排自动刷新的时间

　　 由于Subclipse仍在发展，所以用户可能会遇到bug或者无法找到真正希望获得的一些特性。这带我们进入下一个话题。

修补Subclipse

　　当在Subclipse中遇到问题时，可以有多种选择。如果是瑕疵问题，那么可以简单地选择不使用该产品或等待下一个版本。还可以搜索问题跟踪系统以及邮件列表档案user@subclipse.tigris.org和dev@subclipse.tigris.org，有可能找到当前问题的应对措施或解释。如果这样没有帮助，那么可以在邮件列表中咨询此问题；如果有兴趣试着自己解决，那么，下面的段落将简要介绍如何开始调试和修补Eclipse。但是，如果非常希望有所捐助，那么一种好的方法是订阅dev@subclipse.tigris.org邮件列表，从而使您所做的努力与其他开发人员相协调，根据项目路线图调整您的想法。

　　 着手开始真的非常容易，即使您以前从没有使用过Eclipse插件。需要将Subclipse项目放入Eclipse工作区中。Subclipse项目的Subversion库位于http://subclipse.tigris.org/svn/subclipse/，可以使用以前安装的Subclipse插件或者诸如命令行Subversion客户端或TortoiseSVN之类的外部工具来查看代码。还有一种非常好的办法是在tigris.org Web站点上注册，并请求Subclipse项目的Observer角色。然后，就可以使用相同的用户名连接到Subversion库了（也可以用“guest”/“guest”进行只读访问），还可以在问题跟踪器（一个集成的Bugzilla库）上发表评论，并附上对问题的补丁（如果有的话）。

　　 一旦连接到版本控制库，就需要在自己的工作区中检查下述项目。对每一个模块选择Check Out As...，选择一个位置和项目名（建议使用下表所列出的实际的插件名），并单击Finish。

　　对于开发和测试，只需要org.tigris.subversion.subclipse.core, org.tigris.subversion.subclipse.ui以及org.tigris.subversion.javahl.win32或svnClientAdapter;其他的模块仅在打包整个插件特性或构建更新站点时需要。

　　 当所有的项目都在Eclipse工作区中之后，就可以试着运行了。使用Run -> Run...菜单（或Debug，在调试器下运行），启动新的Eclipse Application类型，并在Workspace Plug-Ins列表中选择Subclipse插件。如果使用已安装的Subclipse运行IDE，那么应该在External Plug-Ins列表中取消对Subclipse插件的选择，但是要使其他插件均保持选中状态。

图14：运行Eclipse应用程序

　　 单击Run（或Debug），如果一切都配置正确，那么就会出现第二个Eclipse Workbench窗口；应该可以打开Subclipse视图，并像Eclipse本身的实例一样连接到库。此时，如果是在调试器下运行，就可以开始将断点放到Subclipse类、或Subclipse所使用的Eclipse核心类中，调试器会停在这些断点上。一个非常好的起点是org.tigris.subversion.subclipse.ui插件中的org.tigris.subversion.subclipse.ui.actions包，它包括菜单或工具栏中特定于Subclipse的UI动作。注意，可以使用UI注册这些动作，可以在plugin.xml中声明式地注册（通常是action元素），或者是在Java代码中编程式地注册，因此，这两个地方都要查看。

　　 假定已经完成了最棘手的部分，并且已经设法实现了更改，那么现在就该创建补丁并将其附在Subclipse 问题跟踪库中的原始问题上了。在创建补丁以前，请确保从版本控制库中选择最新的更改（如果有的话），并最后一次测试更改。如果一切都没有问题，那么就使用Team -> Create Patch...菜单来启动向导。选择Save To Clipboard或Save In File System，并指定是否需要对子目录进行循环扫描来查看更改。

图15：创建补丁

　　 创建了补丁之后，就可以将其发送至dev@subclipse.tigris.org邮件列表了，或者也可以在问题跟踪器中创建问题并将其附上。

结束语

　　诸如Subclipse插件之类的Eclipse平台开源扩展可以提高开发人员的生产力，降低出错的可能性，并增强开发团队内部的交流。本文演示了如何安装、配置和使用Subclipse插件来从Eclipse IDE内部与Subversion版本控制系统进行交互。

　　以Subclipse插件为例，本文还演示了如何设置一个环境以进行Eclipse插件开发、如何调试现有插件、如何创建补丁。事实上，任何Eclipse用户都可以为该开源扩展以及Eclipse平台本身捐献想法和补丁。

参考资料

• Subversion——Subversion主页
• Version Control with Subversion——一本非常不错的Subversion方面的书
• Subclipse - Subversion Plug-in for Eclipse IDE
• JavaHL for Mac OS X
• Building JavaHL from sources
• Configuring an HTTP proxy connection for JavaHL and command-line adapters
• Configuring an HTTP proxy connection for JavaSVN
• Configuring SSL client certificates
• Configuring an svn+ssh:// connection for JavaHL and command-line adapter on Unix
• Configuring an svn+ssh:// connection for JavaHL and command-line adapter on Windows
• Configuring an svn+ssh:// connection for JavaSVN adapter
• Subclipse FAQ
• dev2dev Eclipse Technology Center

原文出处: http://dev2dev.bea.com/pub/a/2005/11/subclipse.html