Subversion中文站 - SVN|TortoiseSVN|论坛|教程|下载|安装|配置

1、Subversion 1.4有什么新东西？

Subversion 1.4在之前版本的基础上提供了更多功能，我们认为它是目前“最好”的一个版本。1.4版本继续支持1.0.x、1.1.x、1.2.x和1.3.x中的全部功能，此外，1.4还包含了很多新的特性并修复了之前版本中发现的bug。1.4版本的新特性将会在1.4版本的free Subversion book中详细描述，参见svnbook.red-bean.com。

2、兼容性

旧版本的客户端和服务器端软件能够直接与1.4版本的服务器端和客户端软件交互。然而，某些1.4版本中新增的特性只有在客户端和服务器端软件皆为最新版本时才可用。Subversion 1.4能够直接访问旧版本创建的版本库，因此无需导出导入原有的版本库资源。如要升级至新版本，只需将新版本的库文件和可执行文件直接覆盖旧版本文件即可。
Subversion 1.4保持了与旧版本间的API/ABI兼容，仅仅在原来的基础上增加了新的功能。使用1.0、1.1、1.2、1.3版本API编写的程序同样能够在1.4版本的程序库上编译运行。然而，基于1.4版本编写的程序无法保证能够在之前的版本上编译或运行。

2.1、工作副本及版本库的格式变化

由于针对工作副本库的某些改进和bug修复的需要，工作副本格式的版本号增加了。这也意味着，1.4版本之前的各个版本客户端软件将无法操作Subversion 1.4生成的工作副本。同样，版本库格式也有了变化，也就意味着1.4版本之前需要直接访问版本库的Subversion工具（如svnserve、mod_dav_svn、svnadmin）无法读取Subversion 1.4创建的版本库的内容。

警告：如果Subversion 1.4客户端软件遇到旧版本的工作副本，将会自动将其升级至新版本工作副本格式，这将会导致就版本Subversion客户端软件无法访问此工作副本。如果你需要同时使用多个版本的Subversion，那么要特别小心对于工作副本的访问，以避免无意中将工作副本格式升级。新的版本库格式不具备类似的“自动升级”的功能。

2.2、命令行输出的变化

尽管Subversion的开发者们尽力保持各个版本间命令行程序输出的兼容性，但是有时必须要添加一些必要的新信息。这可能会影响到依赖于输出格式的脚本程序。在1.4版本中，输出内容的变化如下：
·文件冲突标记匹配文件定义的eol风格。

3、新特性

3.1、svnsync（某些功能需要1.4版本的服务器端软件支持）

标准发布包中包含了一个全新的工具－－svnsync。这个工具能够将一个版本库的历史信息复制到另一个版本库中。这种复制操作可以一次完成，也能够以增量的方式进行（反复执行“sync”即可）。此工具基于抽象网络（RA）API开发，因此，本地版本库和远程版本库都可以作为源版本库和目的版本库。

兼容性问题：因为导入操作是通过传统的网络提交方式实现的，因此此工具能够向任何版本服务器上的目的版本库中导入信息。但是，需进行导出操作的源版本库必须搭建在1.4版本（或更新的）的服务器上。

此工具的使用方法很快将在Subversion book中予以描述，目前，svnsync help命令可以给出足够的使用信息；svnsync的子命令并不多，并且帮助系统中也有完整的描述。

3.2、工作副本性能提升（客户端）

Subversion客户端软件在管理工作副本的方法上有了本质的改进。.svn/entries文件不再是XML格式，并且客户端软件在管理和储存属性元数据的方法上更加智能化。

以上改变的结果是，性能得到了本质上的提升。新的工作副本格式使得客户端软件能够更快的搜索工作副本、检测文件变更、管理属性元数据和处理大文件。由于不再需要那么多inode，工作副本占用的磁盘空间也减少了。此外，许多于合并、复制操作相关的、长期无法解决的bug也得以修复。

警告：Subversion 1.4版本客户端软件会自动将旧版本的工作副本升级至新版本，并且不会给出警告信息。升级操作会导致工作副本无法被旧版本客户端工具访问。参见上文中，“工作副本格式变化”。

3.3、BerkeleyDB 4.4和自动恢复（服务器端）

之前版本Subversion的一个通病是服务器端软件的崩溃可能会导致基于BerkeleyDB的版本库处于一种不可用的“楔住”的状态，需要管理员手工干预和修复。（注意：这并非源于BerkeleyDB自身的bug，而是由于Subversion对其非正规的操作方式！）

现在Subversion 1.4能够在支持“自动恢复”功能的BerkeleyDB 4.4的基础上编译。如果Subversion服务器端软件进行崩溃并导致版本库处于不稳定状态，则下一个试图访问版本库的进程会注意到这个问题，它会夺取此版本库的独占控制权，并自动恢复它。理论上来说（我们的测试也能够证明），这个新功能使基于BerkeleyDB的版本库与基于FSFS的版本库具有同样的防楔能力。

警告：虽然，升级至最新的Berkeley DB不需要导出导入版本库，但是依照Berkeley DB的升级指南进行必要的更改仍然是需要的，这样可以保证版本库能够被最新版本的库访问。Berkeley DB环境参数的升级参见http://sleepycat.com/docs/ref/upgrade/process.html。

3.4、二进制增量编码改进（客户端和服务器端）

Subversion使用xdelta算法计算字节串之间的区别。此算法的输出以一个名为“svndiff”的特定格式储存。svndiff数据就是版本库中储存的关于文件不同版本间差别的数据，svndiff数据也在客户端和服务器端之间传输（比如更新和提交时）。

在Subversion 1.4中，svndiff格式在占用磁盘空间上有了较大改进－－在某些情况下可以比普通文本文件节省50%的空间。因此，如果你选择重新导出导入版本库，新版本库应该比原来的版本库占用更少的磁盘空间（注意要使用svnadmin 1.4版本的svnadmin工具创建新的版本库）。此外，如果客户端和服务器端软件均为1.4版，网络传输的内容也会更少，速度也会更快。

警告：svnadmin 1.4创建的版本库无法被旧版的Subversion库和工具访问。为了获得更小的数据格式，你必须重新导出导入版本库中的数据。如果未使用svnadmin 1.4创建新的版本库，则其还将保持旧格式（体积大），并且能够被旧版的subversion工具访问。

3.5、新的子命令开关

Subversion的新版本增加了一些新的命令行客户端软件的开关和选项。它们是：

svn blame --force
    显示blame的输出，即使文件是二进制格式的。
svn merge/blame -x
    合并和blame命令现在可以传递参数给外部diff3程序。
svn diff/merge -c/--change
    现在可以通过-c N来查看或合并一个单独的修正，以代替之前复杂的 -r N-1:N。
svn diff --summarize
    仅显示有变化的文件，显示的格式与“svn status”相同。此选项可以直接从版本库中获取变化信息，而“svn status”仅能从工作副本中获取本地变化。
svn diff -x [-u | -b | -w | --ignore-eol-style]
    Subversion内部的diff引擎现在在计算变化时能够忽略白空格和eol风格的变化。

4、改进和bug修正

4.1、svnserve作为Windows服务（服务器端）

svnserve服务器现在可以作为Windows服务程序运行了。这使得svnserve可以在系统启动时自动运行，不需要用户登录也不需要外部服务“包装”程序。设置svnserve服务的信息参见http://svn.collab.net/repos/svn/ ... windows-service.txt。

4.2、OS X Keychain支持（客户端）

在OS X上，svn客户端软件现在可以缓存Keychain中的密码而不再是~/.subversion/auth/。

4.3、API改进（客户端和服务器端）

如果使用Subversion API开发第三方客户端程序，可以关注一些新的API：
·RA重放API（在svnsync中用到），提供了一次获得所有与某些修订版本相关的数据。
·许多API修正至新版本。

4.4、其它bug修正（客户端和服务器端）

迄今为止，共修正bug40余处。细节参见http://svn.collab.net/repos/svn/trunk/CHANGES。

5、Subversion 1.2.x系列停止支持

Subversion 1.2.x产品线将不再获得支持。这并不意味着1.2版本难堪重负。如果它工作得很好，并且能够满足要求，那么无需更多担心。“不再获得支持”只是说我们将停止接受和处理任何与1.2.x版本有关的bug报告，并且不再提供任何bug修正版本，除非是导致数据丢失的最危急安全的bug。

翻译:leasun
原文参见：http://subversion.tigris.org/svn_1.4_releasenotes.html