Subversion中文站 - Subversion 1.2版本发布说明

关注兼容性

旧版本的客户端和服务器可以透明的与新版本的服务器和客户端交互操作，当然，如果不同时是使用新版的服务器和客户端，一些1.2的新特性不会起作用，没有必要升级你的版本库，Subversion可以读取早先版本的版本库，要做到升级，只需要覆盖最新的库和二进制文件。

Subversion 1.2维护API/ABI对老版本的兼容性，只添加新的功能，一个针对1.0或者1.1API的程序，也可以使用1.2的库编译和运行，然而，我们没有必要把一个为1.2写的程序用旧版本的库编译。

命令行输出修改

尽管Subversion开发者非常努力的保持命令行输出的在版本之间的兼容性，有时候必须添加新信息，这也许会破坏依赖于这些输出的脚本的执行，在1.2，如下的输出有所改变：

对于svn的update，paths项目向右移动了两列，因此它会在第五列出现，第三列会在一个锁被破坏或者丢失时显示一个B。.
svn的status在第六列添加锁信息，这个列在以前没有用到过，所以以前的信息会在原来的位置。
svn的info命令添加了许多新行，包括锁信息。

预料之外的Berkeley DB升级

实际上这与Subversion 1.2版本没有关系，但是如果你是使用包分发系统来升级你的系统就会影响到你。

许多操作系统包括了Berkeley DB 4.3，有时候Berkeley DB的库会无意中会因为操作系统的包分发机制升级到4.3 — 例如，升级一个人的Subversion包。如果你遇到这种情况，你需要upgrade existing BerkeleyDB-based repositories to 4.3。

新特性

文件锁定(需要新的客户端和服务器)

"Locking"是一个一致要求的特性，在别的系统通常称作“保留取出“，当然Subversion一直主要是一个拷贝-修改-合并系统，关注于并行工作，但是我们也有一个共识，那就是并不是对于所有的文件都适合合并—如艺术作品、压缩文件、私有格式或者其他任何不是以行为基础的二进制文件。

新的锁定特性是双重作用的，首先，提供了一种方式可以强制的顺序写访问文件，其次提供了一种交流机制来防止用户进行不可以合并的时间浪费。

第一个目标通过svn lock 和svn unlock两个命令完成，当一个用户锁定了一个文件，其他任何用户不可以提交修改或者从版本库里删除这个文件，这个锁作为metadata的一部分被管理和强制执行，工作拷贝暂存着一个锁定令牌来代表版本库锁定，这个锁定令牌是一个授权凭证（随同普通用户认证），给用户排他性的权利来提交对文件的修改，缺省情况下，svn commit命令会释放所有在工作拷贝中发现的锁，尽管这个行为是可以自定义的。

锁是可以发现和检测的，“svn status”命令会显示工作拷贝中所有的锁定令牌，而“svn status -u”会显示版本库中其他的锁定，“svn info”命令现在可以工作在工作拷贝和URL上，它会显示锁定的详细信息：谁做的锁定，什么时候做的锁定和所有相关联的注释，在服务器端，可以直接通过 “svnlook lock”来检测锁定信息。

锁定可以通过“svn lock”或者“unlock”的--force选项来盗取或者破坏，对于管理员可以使用版本库的 pre-lock和pre-unlock钩子程序来制定强制政策来禁止破坏和盗取锁，（事实上，整个的锁定特性可以通过pre-lock的一直返回失败来禁用），也有新的post-lock和post-unlock钩子用来发送关于锁定的声明邮件，管理员也可以使用新的svnadmin lslocks和svnadmin rmlocks命令来发现和销毁锁定，如果一个锁定已经在版本库不再存在，“svn update”命令会去掉工作拷贝中的“死”锁定。

第二个目标 — 防止用户在不可合并修改上浪费时间 — 是通过svn:needs-lock这个新属性实现的，用户（或者是管理员）被鼓励对任何不可合并的文件使用此属性，当使用此属性时，这个属性可以使工作拷贝中的文件知读，除非这个工作拷贝由锁定令牌，文件才是可写的。原理是默认的只读属性可以提醒用户在企图编辑文件前需要锁定文件，需要注意的是尽管此系统十分的有效，它并不完美，，Subversion对于流氓程序强制的修改文件的修改属性无能为力。

在Subversion关于此特性的文档更加完善之前，你可以查看最初的功能规范和UI特定的文档来查看更多的细节。

警告：如果在版本库里的锁定正在使用，1.2版本之前的库不会见到或者执行这个特性，这只对使用file://访问版本库德小组用户有关，举例说明，一个svn 1.2的客户端会锁定一个文件，而一个静态关联的svn 1.1或1.0的客户端（通过file://访问）将会无知的忽略次锁定，这个工作区，为了建立一个真实的服务器进程 — 因此保证只有libsvn_fs 1.2可以访问次版本库。

完全的DAV自动版本化（mod_dav_svn 特性）

自动版本化是这样一个特性，一个原始的WebDAV客户端可以写入到DeltaV服务器（像mod_dav_svn），然后服务器自动在后台静静的执行提交。这意味着如果你使用Apache的httpd作为你的Subversion服务器，然后大多数操作系统可以向网络共享一样装载版本库，非技术用户可以得到“透明的”版本化。（当然，技术用户可以一直使用Subversion客户端来检测版本库历史。）

在Subversion 1.2版本之前，mod_dav_svn只可以部分的与原始DAV客户端交互，Subversion 1.1的手册附录 C记录了做这个练习的考验和煎熬，至多可以使用DAV客户端将文件装载到版本库，但是文件不可以直接作为网路共享来编辑，一些客户端甚至拒绝装载Subversion版本库。

现在版本库支持锁定，原始的DAV客户端可以愉快的执行http的锁定和解锁操作，而且文件可以直接在共享里打开/编辑，目前我们可以说，mod_dav_svn已经完全的根据RFC2518bis规范实现了‘自动版本化’特性。

在非正式的测试里，我们已经成功地通过Windows Web Folders、OS X Finder、Gnome Nautilus、KDE Konqueror和其他DAV客户端读写Subversion版本库。

为了激活自动版本化，只需要简单得在httpd.conf里设置Subversion部分的SVNAutoversioning属性，需要警惕的是，设置你的版本库对于原始DAV客户端可写会导致大量的小提交，当一个DAV客户端保存一个文件时，事实上会包括许多写操作，每个引起一个单独的提交。实际试验也许会有所改变。

新的子命令开关:

svn log --limit N
显示N次修订，然后停止。（注意：对于1.2的服务器不是必须如此，但是强烈推荐，一个1.2之前的服务器会一直尝试通过网络返回所有的修订，即使1.2的客户端只会显示部分）

svn info --revision (-r)
显示旧版本项目的详细信息。

svn list --xml
使用XML输出列表。

svn propset --force
Allow unusual propsets, such as svn:eol-style on a file with a binary svn:mime-type..

svn diff --force
Show differences even on files with binary mime-types.

svn checkout/update/status/export --ignore-externals
Don't process any svn:externals during operation.

svn export --non-recursive (-N)
不输出子目录

svnversion --help
显示svnversion的帮助

svnlook diff --no-diff-added
不显示添加的文件的区别，类似的有 --no-diff-deleted.

svnlook propget/proplist --revprop
检查修订小道具，来代替普通的版本属性。

svnadmin load --use-pre-commit-hook / --use-post-commit-hook
在加载输出文件到版本库时调用pre-commit或者post-commit的钩子程序。

改进和修正

使用xdelta压缩算法（服务器）来加速对旧版本的访问

版本库现在使用xdelta差别算法（替代vdelta）来存储压缩的区别数据，当你升级到Subversion 1.2，工作中的版本库会一直工作正常，修订历史会混合xdelta和vdelta区别。

xdelta算法在构建历史文件时会非常快，而且因为我们有动机输出和重新加载已存在的版本库，如果你这样做，你会被强制使用xdelta 算法重新压缩所有的版本库历史，这会导致显著的加快构建历史的速度：svn blame、svn checkout、 svn update、svn diff、 svn merge等等，甚至输出版本库也会加快。

注意：这样会有一个速度与磁盘空间的交换，如果你选择使用xdelta来重建你的版本库，它的大小会增大10%到15%。

FSFS版本库作为缺省设置 (服务器)

经历1.1系列FSFS版本库的巨大成功，我们修改svnadmin使之缺省是创建FSFS版本库，这会给新用户一个友好的用户体验。

注意：Berkeley DB版本库不会准备淡出和废弃，我们遇到的可靠性问题并不是源于Berkeley DB本身，而是Subversion使用Berkeley DB独特方式，为了解决这个问题的协作工作目前正在进行中（使用Sleepycat 引擎），Berkeley DB版本库模式在扩展性方面还是比FSFS版本库更老道，经过更好的测试，项目推荐你阅读本书中关于两个后端来作出选择。

缓存的密码加密保存在Windows (Windows客户端)

在Windows 2000或者更晚的操作系统，命令行客户端在使用远程的Subversion服务器（通过 http://或者svn:// protocols）会加密和缓存用来认证的密码，已存在的未加密的缓存密码会自动地在第一次使用时被加密。

这个特性不会扩展到存储客户端SSL的 passphrases。

注意：客户端使用标准的Windows加密服务来加蜜和解密密码，因此这意味着加密关键字是被Windows管理的，只可以被拥有这个关键字的帐户来访问，如果一个管理员被强制重置帐户密码，加密关键字（随之产生的缓存密码）将不能继续访问到（顺便提一句，同保持NTFS加密的文件一样）， Subversion客户端会检测并且在密码不可知时继续操作，它会在必要时提示用户输入密码。

Bug修正:

超过50个新Bug被修正，察看修改文件来得到详细信息