本控制之于程序员，就好比安全网之于高空秋 千表演者。知道安全网就在那里，万一自己摔落它能够提供保护，高空秋千表演者才能放心大胆地在空中飞跃。同样，版本控制使您有能力去冒以往想都不敢想的风 险。如果哪儿出了错，您总是可以使自己的代码回复到一个已知的、工作正常的版本。您可以在不触及主干的分支中进行试验，而不会影响到其他小组成员。在已经 发布的产品的较老版本中发现 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 在过去的十年中，为社区提供了优质的服务，但它陈旧的劣势开始体现出来。首先，它实际上仅能处理 ASCII 文件。Unicode 文件会令 CVS 严重混乱。此外，CVS 存储库更改起来极为困难。CVS 没有任何关于 “移动” 操作的概念。它只能注意到，一个文件在一处被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。设置 CVS 存储库时，您必须非常谨慎地为每个文件选择准确的位置，因为在设置之后，您几乎就要一直使用这个位置了。
CVS 已经不再适合现代开发，这一点越来越明显。特别是 CVS 只能满足老式 C 程序员的 ASCII 需求，而对 Web 开发人员和其他非传统用户来说，CVS 实际上根本不起作用。在您开始考虑存储整个 Web 站点时，在 CVS 中，将文件从一个目录移动到另外一个目录是关键考虑事项。因此，在几年前，许多核心 CVS 开发人员认为，已经到了利用他们多年来使用 CVS 时学到的经验和教训、从头开始创建新一代开放源码 存储库的时机。在 2004 年年初，他们的努力结出了丰硕的果实，那就是 Subversion 1.0。
程序员（特别是那些依赖版本控制的程序员）是一个非常谨慎的群体，Subversion 着实用了很长一段时间，才得到他们的广泛接受。很少有程序员愿意冲在易于流血的最前沿，即便是他们已经因为 CVS 受了伤。甚至是在 Subersion 变得可靠之后，仍然用了好几年的时间，所有第三方编辑器、IDE 和文档规范才相继跟进。而 Subversion 依然在不断改进，BBEdit 和 Eclipse 等第三方工具现在已经有了足够好的 Subversion 支持。逐渐地，新项目也纷纷选择 Subversion 满足其版本控制需求，而老项目正在向 Subversion 移植。最近，Apache Software Foundation 已移植到 Subversion。已实现移植的项目包括 Xerces XML 解析器、Apache HTTP Server 和 Spamassassin。
如果您已进行了更改，其他开发人员也进行了更改，那么您就必须手动合并文件。对于绝大多数简单更改，Subversion 可推断出需要进行怎样的处理，无需人工干预。但对于较大、较为复杂、存在冲突的更改，您可能需要参与进来，手动合并更改。
Subclipse 在这里可提供一些帮助，但实际上我发现，在一个独立的窗口或选项卡中直接实现一个临时文件副本，通过存储库更新本地副本以覆盖我的更改，然后通过临时副本 重新输入更改，这样做往往更容易。若存储库中的更改与我做出的更改相比较少，我就会从存储库实现临时副本，并通过它进行提交，而不是更新。随后我会重新应 用那些更改。这听上去非常复杂，但事实通常并非如此，它的发生几率几乎与您希望的一样低。即便是您出了错，忘记重新应用更改或是错误地应用了更改，总是可 以找到所有更改的完整历史（包括您覆盖的那些更改）供您参考。实际上您从未彻底丢失任何东西。
如果您不确定已更改了哪些文件，同步视图可以为您显示这些文件。您还可打开标签修饰（label decoration）来查看上次提交/更新后哪些文件发生过更改。选择 Help | Preferences ，然后再选择 General/Appearance/Label Decorations 。然后选中 SVN 复选框 。（实际上该复选框在默认情况下就是选中的。）
- SmartSVN注册方法
- "C:\Program Files\SmartSVN 6\jre\bin\java.exe" -jar keyfilemaker.jar
tools/export backbup 导出
modify/relocate 迁移地址
update/revision 退回到之前的版本
window/reset to default
目录（文件）-》右键-》ignore 忽略上传
使用：
1.在工作目录下 右键 Git create repository here(创建一个仓库)
2.git commit-> master(将当前代码添加到本地仓库中)
3.create branch(创建分支)
4.switch/checkout 切换到分支（主干中代码自动会添加到分支中）
5.在分支中修改代码，并 commint
6.switch/checkout切换到主干 merge 可以选择分支 比如：test 就可以将代码合并了
