模板
教程
环境
性能
功能
管理
Subversion 简介
版本控制之于程序员，就好比安全网之于高空秋千表演者。知道安全网就在那里，万一自己摔落它能够提供保护，高空秋千表演者才能放心大胆地在空中飞跃。同样，版本控制使您有能力去冒以往想都不敢想的风险。如果哪儿出了错，您总是可以使自己的代码回复到一个已知的、工作正常的版本。您可以在不触及主干的分支中进行试验，而不会影响到其他小组成员。在已经发布的产品的较老版本中发现 bug 时，您可以轻松检出特定版本，以确认、修订，并生成该 bug 的修补程序。如果没有版本控制，您必须极为慎之又慎，缓慢地推进，总而言之，生产力会更低。
Subversion 是一种开放源码的全新版本控制系统，支持可在本地访问或通过网络访问的数据库和文件系统存储库。不但提供了常见的比较、修补、标记、提交、回复和分支功能性，Subversion 还增加了追踪移动和删除的能力。此外，它支持非 ASCII 文本和二进制数据，所有这一切都使 Subversion 不仅对传统的编程任务非常有用，同时也适于 Web 开发、图书创作和其他在传统方式下未采纳版本控制功能的领域。
本文介绍了使用 Subversion 追踪项目的基础知识，以使您在编写代码时能够承受更多的风险、享受更多的乐趣。
版本控制简史
当我还是一名刚刚毕业的学生时，我第一次在国家太阳观察站（National SSolar Observatory）接触到了如今版本控制系统的鼻祖 —— SCCS。今天，已经出现了数不胜数的版本控制系统，而 SCCS 也早已被更强大的产品所取代，如 Visual SourceSafe、BitKeeper、Perforce 和开源 CVS（参见 参考资料 部分）。
在开放源码程序员间，CVS 已成为一种事实上的 标准。Codehaus、Sourceforge、Savannah 和 Java™ 社区的 java.net 等站点中驻留的免费 CVS 使得为开源项目建设存储库更为简单。以 CVS 为中心，已发展起一个大型的附件市场，包括 TortoiseCVS、ViewCVS 和 Fisheye 等工具。
与其他版本控制系统相比，CVS 最令人称道的地方就是其非锁定 存储库，这使多个开发人员能够同时检出同一个文件。CVS 在提交时解决冲突问题，这就避免了冲突成为发展的瓶颈。CVS 第二个出色的特性就是它是一种网络存储库。处于许多不同系统上的程序员可以通过公共的 Internet 访问相同的存储库。
逐渐失去优势的 CVS
CVS 在过去的十年中，为社区提供了优质的服务，但它陈旧的劣势开始体现出来。首先，它实际上仅能处理 ASCII 文件。Unicode 文件会令 CVS 严重混乱。此外，CVS 存储库更改起来极为困难。CVS 没有任何关于 “移动” 操作的概念。它只能注意到，一个文件在一处被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置 CVS 存储库时，您必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，您几乎就要一直使用这个位置了。
CVS 已经不再适合现代开发，这一点越来越明显。特别是 CVS 只能满足老式 C 程序员的 ASCII 需求，而对 Web 开发人员和其他非传统用户来说，CVS 实际上根本不起作用。在您开始考虑存储整个 Web 站点时，在 CVS 中，将文件从一个目录移动到另外一个目录是关键考虑事项。因此，在几年前，许多核心 CVS 开发人员认为，已经到了利用他们多年来使用 CVS 时学到的经验和教训、从头开始创建新一代开放源码存储库的时机。在 2004 年年初，他们的努力结出了丰硕的果实，那就是 Subversion 1.0。
Subversion 的支持与采纳
程序员（特别是那些依赖版本控制的程序员）是一个非常谨慎的群体，Subversion 着实用了很长一段时间，才得到他们的广泛接受。很少有程序员愿意冲在易于流血的最前沿，即便是他们已经因为 CVS 受了伤。甚至是在 Subersion 变得可靠之后，仍然用了好几年的时间，所有第三方编辑器、IDE 和文档规范才相继跟进。而 Subversion 依然在不断改进，BBEdit 和 Eclipse 等第三方工具现在已经有了足够好的 Subversion 支持。逐渐地，新项目也纷纷选择 Subversion 满足其版本控制需求，而老项目正在向 Subversion 移植。最近，Apache Software Foundation 已移植到 Subversion。已实现移植的项目包括 Xerces XML 解析器、Apache HTTP Server 和 Spamassassin。
  |
|
通过 IDE 使用 Subversion
您可通过命令行使用 Subversion，但若将其与您的 IDE 集成更为便捷。IntelliJ IDEA 5.0 及后续版本均包含对 Subversion 的内置支持。NetBeans 还不支持 Subversion，但相关工作已经在开展，未来版本中将提供支持。对于 Eclipse，您需要安装 Subclipse 插件。本文使用 Eclipse 作为 IDE。
Subclipse 的安装与其他 Eclipse 插件类似：
- 在 Eclipse 中，选择 Help Software Updates | Find and Install...。
- 在向导的第一个面板中，单击 Search for new features to install 单选按钮，并单击 Next。
- 在向导的第二个面板中，单击 New Remote Site。输入
Subclipse作为名称，输入http://subclipse.tigris.org/update_1.0.x作为 URL。然后单击 Finish。
这将启动另外一个小的向导。下一个对话框应为您提供一个可安装的特性 —— Subclipse。选中它并单击 Next。
- 接受许可协议，完成安装。
程序包目前未经过数字签名，但只要您是按照第三步的 URL 下载的，就是安全的。
|
|
安装程序包后，您必须重新启动 Eclipse，随后才能使用 Subversion。完成之后，您就可以与如今使用 CVS 大体相同的方式使用 Subversion 了，只有为数不多的区别。
检出项目
设置一个新的 Subversion 存储库，特别是网络存储库相对来说较为复杂。但若您正在连接一个现有项目，第一次检出文件就相当轻松。在 File 菜单中选择 New/Other...。这些步骤将为您打开如 图 1 所示的对话框：
图 1. 通过 Subversion 启动一个新项目
接下来，打开 SVN 文件夹，选择 Select Checkout Projects from SVN，并单击 Next 以显示如图 2 所示的对话框：
图 2. Select/Create Location
第一次从存储库检出时，您需要选择 Create a new repository location 并单击 Next。这将为您打开如图 3 所示的对话框：
图 3. 为存储库键入 URL
您在这里提供存储库的 URL。这只是一个普通的 http URL，如 http://svn.apache.org/repos/asf/xerces/java/。这一次单击 Next 时，Eclipse 连接到存储库，并查找可检出的文件夹。通常有三个文件夹：branches、tags 和 trunk，如图 4 所示。Branches 文件夹用于试验。Tags 通常标识较老的、已发布的软件版本。而大多数时候，您都希望在主分支上工作（CVS 称之为 HEAD），因此选择 trunk 并单击 Next。
图 4. 选择要检出的修订版
您现在有两个选择：Check out as a Project configured using the New Project Wizard 或 Check out as a project in the workspace，如图 5 所示。您可按自己的需要任意选择，您可能希望为项目命名，因为默认名称为 “trunk”。最后，单击 Finish。
图 5. 检出项目的两种方法
Eclipse 现在从您选择的分支、主干或标记中下载所有源文件。如果您选择的是 Check out as a project in the workspace，则必须完成 Eclipse 的 New Project 向导，以设置编译器级别、项目布局和其他选项。如果您未使用 New Project 向导，则需要手动设置构建路径和其他选项，就像您在自己的文件系统的一个目录中创建了一个项目那样。确实，您所做的与那极为相似。所有文件都是本地存储的。对于构建、运行和调试这样的普通操作，Eclipse 不关心文件是否已为版本控制检出。
|
|
验证设置
此时，最好进行一次快速、明智的检查，确保您已正确地设置了构建路径。如果没有明显的问题，并且能够运行单元测试，那么即可放心地继续下去了。
如果存在问题，检查项目属性，以确保正确地设置了源路径和类路径。使之差一非常常见，无论是多一还是少一。因此，最终 Eclipse 会认为您的类的名称类似于 src.org.apache.xerces.parsers.SAXParser 或 apache.xerces.parsers.SAXParser，而不是 org.apache.xerces.parsers.SAXParser。在多文件夹项目中，Eclilpse 也常常会错误地将一个数据文件夹标记为源文件夹或遗漏了一个源文件夹。如果发生了以上任何一种小故障，您都必须修复错误，然后才能基础。
|
|
要检查错误，选择 Project | Properties，然后找到 Java Build Path。您可在 source 选项卡中修订任何向导做错的地方。您可能还要添加另外一个项目需要的 JAR 归档，Eclpse 在检出时不会注意到此归档。您还可在 library 选项卡的 Java Build Path 中添加此归档。
请做好心理准备，您可能要在这里花上一点时间。Eclipse 很少会在第一次就让一切正确无误，每个项目组织其文件和库的方式又总会有所不同。
与存储库同步
接下来您就可以照常编辑文件了。作出您希望的任何更改。运行单元测试。优化代码。更正注释中的拼写错误。完成部分工作后，使用上下文菜单并选择 Team/Commit...。您将看到图 6 所示的对话框，要求您输入提交注释：
图 6. Subclipse 的提交对话框
同样，若其他人更改了您希望应用于您的副本的存储库，只要在 Package Explorer 中选中文件，并从上下文菜单中选择 Team/Update 即可。这会以主副本替换您的副本。
|
|
合并
如果您已进行了更改，其他开发人员也进行了更改，那么您就必须手动合并文件。对于绝大多数简单更改，Subversion 可推断出需要进行怎样的处理，无需人工干预。但对于较大、较为复杂、存在冲突的更改，您可能需要参与进来，手动合并更改。
Subclipse 在这里可提供一些帮助，但实际上我发现，在一个独立的窗口或选项卡中直接实现一个临时文件副本，通过存储库更新本地副本以覆盖我的更改，然后通过临时副本重新输入更改，这样做往往更容易。若存储库中的更改与我做出的更改相比较少，我就会从存储库实现临时副本，并通过它进行提交，而不是更新。随后我会重新应用那些更改。这听上去非常复杂，但事实通常并非如此，它的发生几率几乎与您希望的一样低。即便是您出了错，忘记重新应用更改或是错误地应用了更改，总是可以找到所有更改的完整历史（包括您覆盖的那些更改）供您参考。实际上您从未彻底丢失任何东西。
如果您不确定已更改了哪些文件，同步视图可以为您显示这些文件。您还可打开标签修饰（label decoration）来查看上次提交/更新后哪些文件发生过更改。选择 Help | Preferences，然后再选择 General/Appearance/Label Decorations。然后选中 SVN 复选框。（实际上该复选框在默认情况下就是选中的。）
|
|
修补
如果您不具备正在使用的存储库的提交权限，就需要制作一个修补程序，然后将其发送给维护人员。只要选中您希望比较的文件，然后从上下文菜单中选择 Team/Create Patch... 即可。您可以随自己的方便将修补程序保存到文件或剪贴板中。随后可通过电子邮件将其发送给维护人员，或者在 bug 报告中附上该修补程序。修补程序本身采用的格式与 CVS 所使用的 diff 格式相同。
应用他人发送给您的修补程序就没那么复杂了，只要选中您想修补的文件或项目。从上下文菜单中选择 Team/Apply Patch... ，然后平台上惯用的 open file 对话框选择修补程序文件即可。
|
|
比较
如果您已作出了一些更改，并且希望看看您的副本与存储库中的版本有怎样的差别，只需在上下文菜单中选择 Compare/Latest From Repository 即可。这实际上与 CVS 中比较功能的工作方式完全相同。图 7 显示了比较功能的工作情况：
图 7. 在 Subclipse 中比较两个文件
|
|
删除
删除文件也很轻松。只要在 Eclipse 的程序包管理器中删除文件，然后提交父文件夹即可。删除目录要略微复杂一点。您可以选择一个目录并删除它。目录中的所有文件将会立即被删除。但在您删除后，目录本身及其所有子目录又会立即出现在原来的位置。要真正地删除一个文件夹，您需要选中 “已删除” 的文件夹并提交它。同一规则也适用于将一个文件从一个位置移动到另外一个位置的情况。
|
|
在您删除了一个文件或一个文件夹之后，依然可以通过存储库使其还原，即便是已经提交了删除。一旦您将任何内容放进存储库，那么就永远不会真正、永久地失去它，这有时候会产生问题。例如，假设您发现有人意外的检入了其整个主目录，包括其 Quicken 数据文件和所有来自其爱人的情书归档。您很希望能够彻底消除 这些被误提交的文件，这样就不会有其他人得到这些文件。尽管这是一个非同寻常的操作（无论如何，版本控制系统的目的就在于永远地保留每一个文件的每个修订版），但有时也是必要的。令人沮丧的是，Subversion 漏掉了这个重要的特性。
由于没有彻底消除的命令，所以我在为外部可见的存储库使用 Subversion 时非常不安。CVS 也没有这样的命令，但在 CVS 中，您完全有可能在不毁掉存储库的情况下手动删除错误提交的文件。
|
|
结束语
对于内部存储库，Subversion 提供了远超过 CVS 的改进。如果添加了某种类型的彻底消除功能，它也应同样适于外部存储库。尽管像 Eclipse 这样的工具对 Subversion 的第三方支持还不像 CVS 支持那样普遍，但形势正在迅速地发生变化。Subversion 会成为新项目的默认源代码存储库。尚无源代码控制的现有项目应尽快检入 Subversion。而已有 CVS 存储库的现有项目可能仍在观望，希望等到他们所依赖的全部工具均全面支持 Subversion 后再进行切换。但这些项目最终也会移植到 Subversion。Subversion 中的改进如此显著，令人难以忽略。未来必将属于 Subversion。
