不过，无论采用什么平台，所有的参与者都应该学会一些技巧，让我们的交流能更加简单一点。

我看到一条系统信息“SVN求助”，好的，加你入群，然后就出现了这么一句：

有人在吗？

谁答应啊？对此，我常常犹豫不决，没人理，他一定很伤心，可是我接上话，可就要回答了，万一我不会怎么办？

有人会用某某吗？

考别人阿？我会用，不过我不一定帮上你，让我回答吗？

有人用过某某吗？

同上，但我很怀疑自己。

有人熟悉某某吗？

即使我会也不好意思回答是，因为真的很容易面对难以解决的问题。

打扰一下，请教一个问题可以吗？

太有礼貌了，继续吧，既然没经过允许已经问了…

这样的开场白都是失败的，它们的主人如果足够礼貌，一般都会面对一段长时间的等待。其实最简单的做法还是直接说明自己问题，说清楚自己的目标、出现问题的环境、自己所做的各种尝试、以及准确的输出信息。我想，没有人会觉得这是不礼貌，最不礼貌的是自己没有做过任何努力和分析，就把问题没头没脑的抛到群里。另外一种常见的错误是经过太多个人加工的问题，例如“我想解决啥就能解决这个问题”，实际上呢，他只是提出了一个他自己以为的问题，实际的问题被隐藏在了背后，可能很简单。

最后，当我们聊了好长时间后，我最怕看到下面的结果：

虽然你说的和我说的不是一会儿事，但是还是谢谢你？

这让我很伤心。所有努力都已经白费，为什么，是不是我太笨啊？

最后说一下我们的群号码11097243、21860927（近似满）。

更新：在互联网上有一份更全面的“提问的智慧”，希望大家获益，感谢Pan Wenmin。

No related posts.

passwd

对了，这个工具是PHP写的，所以需要一个PHP运行环境。

Related posts:

1. 贫民窟的百万富翁
2. 分支模式-软件配置管理（SCM）模式介绍
3. 疯狂的赛车

SSH登录到Dreamhost主机，下载最新的Subversion源代码包以及dep包：

mkdir soft

cd soft

wget http://subversion.tigris.org/downloads/subversion-1.5.5.tar.gz

wget http://subversion.tigris.org/downloads/subversion-deps-1.5.5.tar.gz

解压缩：

tar xzvf subversion-1.5.5.tar.gz

tar xzvf subversion-deps-1.5.5.tar.gz

进入目录：

cd subversion-1.5.5

设定环境变量

export RUN=${HOME}

因为我的python是自己重新安装的，安装在${home}/opt/bin中，所以还要执行下面这一步：

# ${PYVERS} Python version
export PYVERS=`${RUN}/opt/bin/python -V 2>&1 | cut -d ' ' -f 2`
# ${PYLIBPKG} Python library site packages directory
export PYLIBPKG=`${RUN}/opt/bin/python <<EOF
import sys
print sys.path[-1]
EOF`

然后为了生成python绑定，还要输入如下内容：

SVNPYTHON=" PYTHON=${RUN}/opt/bin/python"

然后运行：

./configure ${SVNPYTHON} ${SVNRUBY} –prefix=${RUN} \ –without-berkeley-db –with-ssl –enable-shared \ ${SVNSWIG}

然后就是漫长的等待，如果没有发现error，下面

make

make install

然后在$HOME/.bash_profile下增加

export PATH=$HOME/bin:$PATH

source $HOME/.bash_profile

最后看结果：

[coke]$ svn –version
svn, version 1.5.5 (r34862)
compiled Jan 16 2009, 00:48:07

Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles ‘http’ scheme
- handles ‘https’ scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles ’svn’ scheme
* ra_local : Module for accessing a repository on local disk.
- handles ‘file’ scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles ‘http’ scheme
- handles ‘https’ scheme

安装完成。

参考文档：

http://wiki.dreamhost.com/Subversion_Installation

Related posts:

1. Subversion: Export changed Files in a revision range
2. Subversion导出修订版本范围中修改过的文件
3. 上传工作拷贝中改变的文件

所以根据上一个导出Subversion指定范围的pythong的脚本，我又写了一个脚本，可以将工作拷贝中修改的文件上传到ftp服务器的对应目录，和上一个脚本一样，这个脚本需要安装pysvn，而我的脚本在http://svn-script.googlecode.com/svn/trunk/tools/svnchanged_ftp.py。

使用方式很简单，将上面的脚本存放到一个位置，在工作拷贝的根目录写一个批处理，内容如下：

python.exe F:\rocksun\svn-script\tools\svnchanged_ftp.py –ftphost 192.168.0.121 –ftpuser username –ftppassword userpassword –ftppath www  F:\websites\rocksun.cn\www

分别通过–ftphost、–ftpuser、–ftppassword、–ftppath分别指定ftp主机的ip、用户、密码和ftp服务器上和工作拷贝对应的根路径，最后的一个参数是本地工作拷贝根的路径，和ftppath对应。

运行这个bat，就可以检查工作拷贝F:\websites\rocksun.cn\www已经修改得文件，然后ftp到对应的服务器目录上。现在只能上传改变的，还不能上传最近修改过但已经提交的文件，一个缺陷，不过这个缺陷可以通过我上一个脚本弥补，要是谁有这个需求，可以告诉我，我将这个缺憾弥补起来。

我用这个脚本帮助我修改本站的模板，很舒服啊，修改了好几个目录的文件，一个批处理就把所有的修改提交了。只是这blog是越来越难看了，技术不行啊。

Related posts:

1. Subversion: Export changed Files in a revision range
2. Subversion导出修订版本范围中修改过的文件
3. Resize Image In Context Menu

The script is  here: http://svn-script.googlecode.com/svn/trunk/tools/svnchanged_export.py. This script needs python 2.5 or greater and pysvn. To export files changed between 20 and HEAD(newest) at URL svn://192.168.101.1/lynx/trunk/ to directory dist, we can input:

python svnchanged_export.py -u username -p password -r 20:HEAD svn://192.168.101.1/lynx/trunk/ dist

The exported files will organized as the original structure, and the revision is HEAD. The -u(–username) and (-p)(–password) is optional. If omited, the script may use the cached authentication information.  The files will export to directory dist. The -r(–revision) also accept integer value like “-r 10:20″, then the exported file’s revision would be 20.

Any problems can comment here.

Related posts:

1. Subversion导出修订版本范围中修改过的文件
2. 上传工作拷贝中改变的文件
3. Subversion 1.5发布说明

虽然svn本身没有支持这个功能，但是TortoiseSVN却提供了这个支持，台湾一位朋友写了一个图形教程，我整理了一下转载到了Subversion中文站。另外还有一套Java的解决方案，可以看老外的这个介绍。

不过，我觉得上面两个都还不够好，一个不是脚本，另一个则有点麻烦，于是我自己写了一个类似的脚本，使用python编写，现在做一些简要的说明。脚本可以在http://svn-script.googlecode.com/svn/trunk/tools/svnchanged_export.py下载，运行这个脚本需要python的pysvn包，可以从http://pysvn.tigris.org/servlets/ProjectDocumentList?folderID=1768下载合适的Windows版本，下载后直接安装即可。

使用这个脚本的方式也非常简单，我们就可以直接运行：

python svnchanged_export.py -u username -p password -r 20:HEAD svn://192.168.101.1/lynx/trunk/ xx\yyy

例如上面的命令，用户是username，密码是password，这两个参数可以省略，那样会使用密码缓存或不需要认证。指定的修订版本范围是20到HEAD，对应的URL是 svn://192.168.101.1/lynx/trunk/。导出的文件存放到xx\yyy，默认是当前目录“.”。上面的命令执行后，xx\yy目录下就会出现修订版本HEAD（最新）和修订版本20之间发生过修改的文件，这些文件都存放在原来的相对目录中，修订版本都是最新的。这个命令还可以写为：

python svnchanged_export.py -u username -p password -r 20:90 svn://192.168.101.1/lynx/trunk/ xx\yyy

这时，比较的修订版本变成了90，而对应的输出的文件都是修订版本90的文件。

这个脚本还没有经过实践的检验，只在我的windows下验证过，所以请大家小心使用，如果有问题，可以告诉我，我会尽快解决。你也可以直接加入我建立的这个项目，自己去修改这个脚本。说实话，pysvn的接口虽好，但文档奇缺，我用到一个接口，google没有任何结果。

Related posts:

1. Subversion: Export changed Files in a revision range
2. 上传工作拷贝中改变的文件
3. Dreamhost上编译Subversion

The most obvious indication is that you click on open/save/save as and nothing happens. What is happening is that the file browser window is failing to open. There are two fixes; Either change JAVA_HOME to point to a JRE rather than a JDK or edit the Freemind.bat file to use the absolute path to the correct java and start Freemind with the bat file. It will be something like “C:\Program Files\Java\jre1.6.0_05\bin\java” instead of just java. Note the use of quote marks and that your java path may not be the same as the example.

照着做了，可是还是没有效果，不过提示我运行Freemind.bat，结果发现保存时的错误为：

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at javax.swing.ImageIcon.(ImageIcon.java:161)
        at javax.swing.ImageIcon.(ImageIcon.java:147)

原来如此，可能是AWT的问题，于是我尝试修改LookAndFeel，在Tools->Preference->Appearance-> LookAndFeel中，我设置为Gtk，结果重启后就好了，样子很难看，想去试一下别的，发现都不行，只好留着Gtk了。但是总算能用了。为什么我的JRE只在Gtk下工作正常？下次装一个新的JDK再看看。

Related posts:

1. Dreamhost上编译Subversion
2. FEST — 一个GUI测试框架
3. Subversion: Export changed Files in a revision range

• http://www.subversion.org.cn/svnbook/
• http://process2.cn/svnbook/

另外，提供最新的TortoiseSVN文档浏览和下载：

TortoiseSVN文档

TortoiseSVN是一Windows下优秀的客户端软件，多数成员在i18n-zh中开发，最新文档可以如下：

• 文档浏览
• PDF下载

TortoiseMerge文档

TortoiseMerge是TortoiseSVN配套的比较合并工具：

• 文档浏览
• PDF下载

不过最近这些文档翻译的进度不是很好，例如TortoiseSVN，以前有一段时间大家突击翻译了许多，但是最新的还是差的挺多的，所以这里也想征集一下志愿者，主要有如下一些内容的翻译：

翻译项目

Subversion FAQ翻译（急）

Subversion的官方FAQ是一个很不错的资源，现在征集翻译，欢迎您的参与。项目源代码在：http://svncndoc.googlecode.com/svn/trunk/faq，最好你有一个google帐号，可以访问google的源代码库。如果你有兴趣，可以给我发信息 daijun@gmail.com。

Submerged中文版翻译（急）

Submerged是Subversion开发者的一个很好的Blog，通过这个Blog你能够及时获取最新的Subversion各个方面的知识，Submerged中文版在http://rocksun.cn/svn，欢迎您的加盟。如果你有兴趣，可以给我发信息 daijun@gmail.com。

TortoiseSVN和TortoiseMerge文档翻译（急）

http://tortoisesvn.net/translation是官方网站，部分成员在http://code.google.com/p/i18n-zh/，本站有最新文档：http://www.subversion.org.cn/tsvndoc和http://www.subversion.org.cn/tmedoc现在进展较慢，如果你有兴趣，可以联系我。要求是了解docbook，并能通过我们的指导使用ant编译文档。如果你有兴趣，可以给我发信息 daijun@gmail.com。

Related posts:

1. About Me
2. 分布式版本控制工具Bazaar
3. 我家的大水坑

• 合并跟踪（基础）
• 稀疏检出（通过新的–depth选项）
• 交互式的冲突解决
• 变更列表支持
• svn:externals的相对URL和peg修订版本
• 对于ra_svn和svnserve的Cyrus SASL支持
• 通过sharding对于FSFS的大规模开发的支持
• FSFS优化，通过不变的文件隔离
• WebDAV的透明通过代理写
• copy 和move的改进
• 速度改进，取消响应改进
• 更简单的使用试验ra_serf DAV访问模块
• API改变、改进以及语言绑定
• 超过150的bug修正，改进

Subversion 1.5是以前Subversion发布版本的超集，可以认为是当前“最好的”版本。包含所有1.0.x到1.4.x的，以及以前版本没有的修正和特性。所有的新特性将会写入Subversion book，见svnbook.red-bean.com。

兼容性问题

以前的客户端和服务器可以直接与1.5的服务器和客户端交互，然而，如果服务器和客户端不全是1.5时，一些新的1.5特性（例如合并跟踪）将会不可用，而另外一些特性如稀疏检出，在服务器是旧的，客户端是新的时，可以运行但是效率比较低。

没有必要转储并重新加载版本库，subversion1.5可以读取以前创建的版本，升级只需用最新的库和二进制程序覆盖原来的程序。

Subversion 1.5 maintains API/ABI compatibility with earlier releases, by only adding new functions, never removing old ones. A program written to the 1.0, 1.1, 1.2, 1.3, or 1.4 API can both compile and run using 1.5 libraries. However, a program written for 1.5 cannot necessarily compile or run against older libraries.

Subversion会维护与先前版本API/ABI的兼容，只会增加新的特性，而不会删除旧的特性。根据1.0, 1.1, 1.2, 1.3或1.4 的API编写的程序，可以使用1.5的库编译，为1.5编写的程序不必为旧库编译或运行。

新特性的兼容性表格

工作拷贝和版本库格式更改

工作拷贝格式已经升级，这意味着1.4和更老的Subversion客户端不能与Subversion1.5的工作拷贝上工作，工作拷贝是自动升级的。

类似的，版本库格式也已经改变，意味着直接访问库的1.4以及旧的版本的程序如svnserve，mod_dav_svn，svnadmin等不能读取Subversion1.5的版本库，但是版本库是不能自动升级的。

工作拷贝升级

警告：如果一个Subversion1.5客户端遇到了一个1.5以前的工作拷贝，它会在接触到工作拷贝时自动升级工作拷贝格式，并使旧的Subversion客户端不能再读这些工作拷贝了。如果你在机器上使用多个版本的Subversion，请确认你对工作拷贝是用的subversion版本，防止意外升级工作拷贝。（但是这种自动升级行为不会发生在版本库上，只发生在工作拷贝。）

如果你意外的将工作拷贝从1.4升级到1.5，并希望降级到1.4，可以使用change-svn-wc-format.py ，详情看这篇文章，也可以以–help运行来查看使用指导。

版本库升级

Subversion 1.5服务器可以与1.4和以前的版本库工作，如果不使用svnadmin upgrade命令，版本库不会自动升级到1.5。这意味仅仅升级服务器不能直接得到某些特性，你也需要升级版本库。（我们决定不使用自动升级版本库是因为我们不希望subversion1.5偷偷的升级成1.4不可用的版本库。）

在运行svnadmin upgrade之后，你或许希望对版本库运行svn-populate-node-origins-index 程序。Subversion1.5为每个版本库维护了一个节点起源的索引，为了得到一些信息，偶尔构建这个索引。但是对于包含许多修订的老版本库，最好一次创建这个索引，使用前面说道的工具，而不会因为自己构建这个索引而影响查询的性能，更多细节见issue #3024。

命令行输出的变更

尽管我们希望尽可能让命令行程序的的输出与以前版本保持兼容，但是还是要添加一些信息，这会破坏一些精确依赖输出的脚本。不幸的是，我们不能列出1.5输出的所有改变，但有一条可以确定的是冲突标记的行结束符号会和文件的eol-style匹配。

SASL和svn://的兼容性

所有1.x的客户端，包含或不包含Cyrus SASL支持的，都可以通过在Cyrus SASL没有开启时认证正常。注意CRAM-MD5和ANONYMOUS机制是Subversion内置的，所以即使Cyrus SASL插件不在，我们也可以使用。

没有Cyrus SASL支持的1.x客户端不能通过开启Cyrus SASL，允许CRAM-MD5 和ANONYMOUS机制的1.5+的subversion服务器认证，

包含Cyrus SASL支持的1.5+客户端可以通过开启SASL功能的1.5+服务器认证，只要保证服务器支持的某个机制客户端也支持。

关于Cyrus SASL的更多信息可以看这个部分。

自定义revprops现在需要通过pre-commit钩子的检验

Subversion每个修订版本都有一组关联的修订版本属性；除了标准的日志信息，作者和日志，可以设置任意的用户定义的属性。这些属性本身不是版本化的，所以不能恢复修改的内容。因此，如果我们没有设置pre-revprop-change，我们就不能修改提交修订版本的revprops。在Subversion1.5之前，我们只能在提交时提供这三个标准的revprops；管理员使用钩子来控制这三个标准修订版本属性的内容，需要在pre-commit和pre-revprop-change检查，但是对于自定义的属性，只有pre-revprop-change是相关的。

Subversion1.5添加了svn commit包含--with-revprop选项，允许用户在提交时为修订版本指定属性，因此在Subversion 1.5允许在没有pre-revprop-change钩子时设置修订版本属性，pre-commit可以在提交之前检查事务修订版本属性（就像许多服务器已经使用pre-commit来检查正确格式化的log）。

这意味着如果你以前依赖pre-revprop-change to 钩子控制对于修订版本属性的修改（不仅仅你是跟踪它们的历史），那你先现在也需要在pre-commit添加类似的控制。

新特性

合并跟踪（基础）（客户端和服务器）

合并跟踪的意思是Subversion保持哪些变更从哪里合并过来，这减轻了维护分支的负担，也给了用户一个方式来查询合并的变更—或需要合并的内容—在不同的开发线上。

Subversion1.5支持的合并跟踪是“基础的”：最重要的部分已经实现，但是在我们最初的规格中还有一部分需要去实现（特别是对于reflective merges的正确支持，更好的change-availability reporting和更好的tracking of renamed files），虽然在1.5还要加入一些主要的特性，但我们不希望为等待某个特性延迟我们的发布。更多的合并跟踪改进希望在Subversion1.6或以后的版本出现。

概述

Subversion的合并跟踪设计为：

• 减少分支维护的记录负担
• 防止常见的“重复合并”问题
• 允许对于变更的cherry-picking

每个变更集都可以通过修订版本号识别，通过新的svn:mergeinfo属性在合并的目标存放在合并变更集的信息（通俗来说就是“合并信息（mergeinfo）”），Subversion会自动保持合并信息的为最新，但是也有办法手工记录/消除合并信息，这是因为总会有些时候人们知道一些Subversion不知道的事情。

用户界面

从主干合并分支不再需要指明修订版本范围，每当你希望与trunk同步，你可以这样做：

   $ cd BRANCH_WORKING_COPY
   $ svn merge URL_TO_TRUNK

Subversion能够计算出从URL_TO_TRUNK有哪些变更没有合并，并只处理这些变更，当将分支合并回主干，我们只需要：

   $ cd TRUNK_WORKING_COPY
   $ svn merge --reintegrate URL_TO_BRANCH

下面是所有合并跟踪相关接口变更的正式描述。

svn merge命令使用两个新的选项：--record-only 和--reintegrate。

–record-only选项至于-r结合工作，并且和你所想的一样：它只是用来将修订版本标记为已合并（或未合并的，使用“-”作为否定语法），而实际上除了合并信息（mergeinfo），什么也没有做。例如，当因为效率某个人手工修改了这个文件而合并了这个其他地方修改的变更时，这非常有效，与其让让变更在下次合并时加入进来，从而引起文本冲突，我们不如记录这个变更已经合并。（细节见Subversion书的merge-tracking requirements, and Blocking Changes 。）

–reintegrate选项在将分支合并回主干时使用；它会检查一些防护措施条件并快速有效的进行合并，更多内容见Subversion book的Keeping a branch in sync。

新的svn mergeinfo命令可以显示一个目录已经接收的变更集，以及哪些变更集还适合接收，Subversion手册的Mergeinfo and Previews有更多信息。

svn log 和svn blame 命令有了新的-g (--use-merge-history) 选项，使之将mergeinfo纳入考虑，如果没有提供这个选项，它们就会参考合并信息。

使用-g选项的原因是有时候忽略合并历史会更好，在blame输出中，有时候你希望看到合并变更的人物B，而有些时候你希望看到最初作出这些修改人物A；使用-g可以得到后者的信息。在日志输出中，你有时候希望看到某一行提交的修订版本，而有时你希望看到最初的修改做合并修订版本转移走了；再次，-g显示后者的信息（使用”Merged via: “标识，后面是合并发生的修订版本号码），见Subversion手册的Merge-Sensitive Logs and Annotations。

合并跟踪和兼容性

前面已经说了，在随server升级版本库以前不支持合并跟踪。

如果你正在使用svnmerge包裹程序来进行合并，而现在希望使用Subversion1.5本身的合并跟踪功能功能，你一定要使用svnmerge-migrate-history.py 脚本来转化svnmerge的自定义属性为Subversion使用的svn:mergeinfo属性。

已知问题

1.5.0的合并跟踪还有许多已知的问题，我们首先解决了最重要的，下面是：

• issue #3128: merge --reintegrate 应该更好的处理重命名
• issue #2897: 对反向合并的更好支持
• issue #3126: 更好已知变更报告（svn mergeinfo显示了太少或太多的合适修订版本）
• issue #2837: 当执行循环合并时合并跟踪能起效果
• issue #3056: 防止以智能方式重复合并
• issue #2898: 当删除/添加子时无需处理合并信息
• issue #3067: 在合并范围内不存在的树不应该破坏合并
• issue #3157: 从路径的自然历史合并变更会创建引用自己的合并信息
• issue #3174: 合并算法需要对重命名的子树特别关注

（可以看list of all merge-related open issues，尽管很多不是关于合并跟踪）

Issue #3157可能是会很容易遇到的，所以下面是如何解决这个问题的详细描述：

合并跟踪信息现在可以保存在路径的“本身历史”中，当从trunk的特定修订版本x创建了一个分支，然后将分支的所有变更合并回trunk时，如果没有明确的限制合并范围并且没有使用--reintegrate 选项时，后果是，trunk的合并跟踪信息将会列出x之前的信息。这对以后的合并操作没有坏处，但是对于trunk上的svn log -g会使用以前修订版本的合并跟踪信息（而不只是HEAD）。

注意，这一定不会是一个发布分支（也叫做“维护分支”）的问题，因为一个人通常不会将其合并回主干，相反，推荐的时间是对于进入trunk的新变更使用特性分支，可以在分支的生命周期结尾一次合并到主干。

一个办法是在提交合并修订之前修正合并跟踪信息，通过恢复“本身历史”信息：svn merge --record-only -rX:1。另一个方案是完全防止这种情形，通过在第一次就明确的指定合并范围，例如-rX:HEAD，更多信息可以看这个邮件 。

当合并一个特性分支，最佳方案是使用--reintegrate选项

深入阅读

Subversion 1.5合并跟踪的更多内容可以看：

• Chapter 4: Branching and Merging in the Subversion book
• Subversion 1.5 merge-tracking in a nutshell (blog post by Ben Collins-Sussman)
• The merge tracking design documents (requirements, use cases, functional spec, design)

稀疏检出（Sparse checkouts）（客户端和服务器）

许多用户都有很大的目录树，但他们只希望检出特定的部分。在Subversion以前的版本，checkout -N没有真的完成这个任务。Subversion 1.5引入了checkout、switch和update子命令的--depth选项，这个选项替代了-N，允许用户构建只包含他们需要内容的工作拷贝，而不管其他的东西。

Depth概述

每个目录现在理解了depth的概念，可以有四种值：empty、files、immediates、infinity，值的定义如下：

• –depth=empty: 更新不会拉出任何不存在的文件或目录
• –depth=files: 更新会拉出所有的文件，但不包括子目录
• –depth=immediates: 更新会拉入所有不存在的文件或子目录；但子目录的设置为depth=empty。
• –depth=infinity: 更新会拉入所有不存在的文件和目录，子目录的设置为depth=infinity，与目前的缺省更新行为方式相同。

--depth 选项设置depth的值在更新工作拷贝时按照上面说的方式更新

用户界面

影响的命令：

• checkout
• switch
• update
• status
• info

-N选项开始成为这些子命令的--depth=files选项的一个别名，这改变了现存的-N行为方式，但是以一种很琐碎的方式（见下面）。

现在对于不使用--depth或-N 的checkout来说和以前一样。没有--depth或-N 的switch和update命令现在只和工作拷贝完全的depth-infinity相同，没有--depth或-N 的switch或update不会改变depth值（例外：在命令行中指定的不存在的目录会拉入）。

结果是，checkout与checkout --depth=infinity相同，但是switch和update与switch --depth=infinity和update --depth=infinity不同，前者根据现存的depth值更新，而后者获取所有的内容。

作为开始，可以使用--depth=empty或--depth=files选项checkout文件，如果需要额外的文件或目录，可以使用合适的--depth选项的update命令来获取。除了其他的状态信息，svn status必须列出目录周围的depths。当调用的目录的depth不是缺省值（depth-infinity）时svn info命令也会列出其depth。

注意： 当前对于稀疏检出没有反选的接口—也就是说，在引入到工作拷贝后（尽管有一些相对简单的方法可以获取此目标），没有命令可以取消选择或“折叠”子目录，详细信息见issue #2843。

与以前服务器的兼容性

--depth特性显然需要客户端是1.5以上的，也需要1.5以上的服务器才能最有效的工作，然而，客户端仍然需要在1.4.x服务器时工作正常；只是有较差的效率。

这是因为以前的服务器不会理解—因而会忽略—不会清楚客户端说的“depth”的含义。所以当客户端请求比depth-infinity更浅的depth，以前的服务器会返回比客户端需要更多的数据，然而Subversion1.5+的客户端知道是与旧的服务器通话，并会过滤这些多余的数据，因此，操作会更长一些，因为服务器发送了许多客户端忽略的数据，但是最终在客户端产生的数据相同。（注意旧的服务器理解网络协议的recurse，而1.5+客户端根据depth发送标记；这减轻了额外的网络惩罚。）

进一步阅读

• The Sparse Directories section in the Subversion book.
• The design/implementation document in the repository.

交互式冲突解决（客户端）

在update/switch/merge 子命令的操作中，现在冲突解决是使用交互式的命令行客户端完成，客户端库提供了一个callback函数，所以其他客户端也能以同样的方式工作。

下面是使用命令行客户端例子：

   $ svn up
   U    contrib/client-side/svnmerge/svnmerge_test.py
   Conflict discovered in 'contrib/client-side/svnmerge/svnmerge.py'.
   Select: (p) postpone, (df) diff-full, (e) edit,
           (s) show all options: s
     (p)  postpone    - mark the conflict to be resolved later
     (df) diff-full   - show all changes made to merged file
     (e)  edit        - change merged file in an editor
     (r)  resolved    - accept merged version of file
     (mf) mine-full   - accept my version of entire file (ignore their changes)
     (tf) theirs-full - accept their version of entire file (lose my changes)
     (l)  launch      - launch external tool to resolve conflict
     (s)  show all    - show this list

   Select: (p) postpone, (df) diff-full, (e) edit,
           (s) show all options: tf
   G    contrib/client-side/svnmerge/svnmerge.py
   Updated to revision 25685.
   $

这个特性可以使用–non-interactive选择关闭，或者通过设置运行配置文件中的“[miscellany] interactive-conflicts = no”永久关闭。

交互式冲突解决的API通过一个callback函数公开，并有如下数据类型：

• svn_wc_conflict_resolver_func_t,  callback API本身
• svn_wc_conflict_description_t,  传递给callback的冲突描述
• svn_wc_conflict_action_t,  冲突描述中尝试工作内容的部分
• svn_wc_conflict_reason_t,  冲突描述中冲突类型部分
• svn_wc_conflict_result_t,  返回的冲突解决尝试结果
• svn_wc_conflict_choice_t,  用户选择动作的列表

客户端通过设置他们的svn_client_ctx_t的conflict_func字段提供了他们的callback函数，并可以通过对应的conflict_baton字段提供额外的callback状态。

变更列表支持(changelist)（客户端）

Subversion客户端现在包含了变更列表（changelist）的改变，一组与选定名称关联的文件，当工作在同一个工作拷贝的不同集合的文件时这样非常有效，Subversion1.5允许你为每组文件关联一个变更列表，大多数可以将一组文件作为目标的命令现在也接受--changelist选项，会根据changelist的成员过滤目标，变更列表的成员可以使用changelist子命令编辑。

变更列表完全是客户端控制的。他们不会发送到服务器，对同一个版本库其他用户都不可见。另外，--changelist 选项不是添加剂；如果一个文件在没有--changelist的时候加入到目标的列表，它也不会加入进去，它不会管changelist的成员。当前，一个文件一次只能属于一个变更列表，目录不能作为变更列表的成员。

下面的子命令支持--changelist选项：

• changelist
• commit
• diff (only wc-wc and wc-repos cases)
• info
• propget
• proplist
• propset
• propdel
• revert
• status
• update

进一步阅读

• The Changelists section in the Subversion book.
• The design/implementation document in the repository.

svn:externals中的相对URL，peg revisions（客户端）

对svn:externals 特性的两个增强

对于URL的Peg revision语法

兼容性和新的语法：由于兼容性原因，1.5以前的svn:externals语法继续不理解peg revisions，引入了一种支持URL中peg revisions的新语法。

以前的格式是：

   foo             http://example.com/repos/zig
   foo/bar -r 1234 http://example.com/repos/zag

不支持peg revisions，如下的外部定义不能工作（除非目录名就是zig@HEAD and zag@HEAD）：

   foo             http://example.com/repos/zig@HEAD
   foo/bar -r 1234 http://example.com/repos/zag@HEAD

新格式将跟在外部定义后面的路径URL移动到第一位；如果有一个操作（-r）修订版本，则在URL之前，下面是四个外部定义行：

   http://example.com/repos/zig foo1
   -r 1234 http://example.com/repos/zag foo/bar1
   http://example.com/repos/zig@HEAD foo2
   -r 1234 http://example.com/repos/zag@HEAD foo/bar2

换句话说，操作（“r”）和peg（“@”）都是允许，但都不是必须的。

对相对URL的支持

在Subversion1.5之前，svn:externals中的URL必须是绝对路径，现在他们可以是相对的。现在支持四种相对外部引用。（在下面的例子里，假设我们有两种版本库：一个是在http://example.com/svn/repos-1 ，另一个在http://example.com/svn/repos-2，我们检出http://example.com/svn/repos-1/project1/trunk，而svn:externals 设置为trunk。）

../

svn:externals属性设置目录的相对路径，则URL是以../开始，例如：

   ../../project2/trunk common/project2/trunk

这就是将http://example.com/svn/repos-1/project2/trunk 加入到common/project2/trunk。外部URL相对于设置svn:externals属性的目录的URL，而不是写到磁盘的外部的目录。

^/

相对于库的根。

   ^/project2/trunk common/project2/trunk

这就是将http://example.com/svn/repos-1/project2/trunk加入到common/project2/trunk。

你可以容易使用相对URL来引用其他的版本库：

   ^/../repos-2/foo/trunk common/foo/trunk

就是http://example.com/svn/repos-2/foo/trunk加入到common/foo/trunk。

//

相对于模式，这就是拷贝了检出或导出URL的模式到svn:externals，当同一个主机必须依赖于网络位置按照不同的模式访问；例如局域网的客户端使用http://，而外部客户使用svn+ssh://。

   //example.com/svn/repos-1/project2/trunk common/project2/trunk

这将会把http://example.com/svn/repos-1/project2/trunk提取到common/project2/trunk，如果工作拷贝是通过svn+ssh://example.com/svn/repos-1/project1/trunk 检出的，那么URL将会是svn+ssh://example.com/svn/repos-1/project1/trunk。

/

服务器root的相对URL，这是检出或导出的模式和主机名的URL拷贝到svn:externals。

   /svn/repos-1/project2/trunk common/project2/trunk

这会提取http://example.com/svn/repos-1/project2/trunk到common/project2/trunk。如果工作拷贝是从svn+ssh://example.com/svn/repos-1/project1/trunk 检出，那么URL将会是svn+ssh://example.com/svn/repos-1/project1/trunk。

旧的svn:externals格式依然支持相对URL（不会支持peg revisions）。

当Subversion见到不使用绝对URL的externals ，会将第一个参数作为相对URL，第二个作为目标目录。

进一步阅读

See The svn:externals section of the Subversion Book.

ra_svn和svnserve的Cyrus SASL支持（服务器和客户端）

来自Wikipedia：“SASL是网络协议的认证和数据安全框架，它将认证机制与应用协议解耦，从理论上讲，允许任何SASL支持的认证机制应用到使用SASL的应用协议上”

在实践中，服务器发送会发送一组它支持的认证机制，客户端会根据客户端的支持选择一种认证机制，并通知服务器这个决定。之后，会有一些信息交换，直到成功或者失败发生，在后一种情况，允许客户端重新认证。

svn:// 协议会一直支持这种类型的协商，然而只是实现了CRAM-MD5和ANONYMOUS。Cyrus SASL支持所有这些，此外，提供了其它如DIGEST-MD5, OTP (One-Time Passwords), GSSAPI (used for Kerberos authentication), NTLM (NT LAN Manager), SRP (Secure Remote Password)以及其他机制的支持。支持机制的准确列表依赖于SASL是如何编译的，有一些还有外置依赖，或不是缺省编译。另外，因为每种机制实际上是一个共享库，会在运行中加载，有许多分布的包位于核心库外单独存放。

关于使用1.5并开启SASL与1.5前的客户端工作的更多信息请看兼容性部分，关于Subversion的SASL支持可以看sasl.txt。

对于FSFS大规模开发的改进支持，通过sharding （服务器）

FSFS文件系统后端在各自的文件存放每个修订版本，在Subversion1.5之前，所有的文件都存放在版本库一个普通的目录里，现在新创建的FSFS库会使用二级的目录树，每个目录最多1000个文件。这种版本库只能与Subversion1.5客户端兼容，但是当然，Subversion1.5仍然可以使用以前格式的版本库，而没有问题。

这样做的主要原因是允许修订数量能够超越文件系统的目录树的限制，当现代文件系统能够成支持每个目录有百万条目，它会变得很慢，而且管理工具会变得笨拙或失败。

关于FSFS sharding的更多信息可以看这个blog entry。

svnadmin create创建后，使用版本库之前，shard大小可以通过编辑“db/format”中的“layout sharded”来调整。

改进的FSFS优化，通过不可变的文件隔离（服务器）

FSFS版本库永远不会在写入修订版本后进行修改，尽管最好让操作系统永远缓存所有的文件，某些文件系统（例如NFS）缺省可以通过这种缓存获益，现在FSFS版本库为此将不变的文件存放在子目录“db/revs”和“db/txn-protorevs”，这允许这些目录加载到开启缓存（在Linux可以看nfs部分的“nocto”）的挂接点上。

因为提交事务存放在db/txn-protorevs” 而不是”db/transactions”，后者的目录不必在同一个挂接点，如果版本库存放在较慢的文件系统（例如NFS），提交效率可以通过将目录移动到本地磁盘（使用符号链）改进。如果你在一个网络负载平衡器之后使用多个svn服务器，你必须配置负载平衡器在一个事务中转向到同一个服务器，这通常叫做“客户端喜好”。

WebDAV透明通过代理写（服务器）

Subversion1.5引入了svnsync — 一提供从一个版本库复制内容到另一个版本库的工具。尽管很有用，但svnsync只能从一个版本库拖入修订版本，但是不能将额外的提交返回给master。Subversion1.5为mod_dav_svn添加了WebDAV代理支持，有效的使用mod_dav_svn允许双向的修订版本历史复制。

所有的客户端与slave服务器交互，但是slave会透明的将所有的写活动传递给master（根据需要重写数据），slave实质上是只读的，但是它们本地都有一个完整的版本库，服务器分流master服务器的读压力，某些情况下非常可观。

如果使用支持HTTP DAV的缓存代理，这个模型非常有好处，在这个情况下，每个slave可以对应所有对应的只读请求，而无需传递给master后端。

要求

• Subversion 1.5或更新的。
• Apache HTTP Server 2.2.0或更高，并开启mod_proxy （许多mod_proxy 修正的bug没有回到httpd的2.0版本）

实例配置

参与者：

• Slave → slave.example.com （可以很多）
• Master → master.example.com （可能只有一个）
• A WebDAV client (ra_neon, ra_serf其他WebDAV客户端)

客户端做：

    % svn co http://slave.example.com/repos/slave/
    ...
    % svn ci
    % ...etc...

（客户端可以操作如常）

每个slave配置：

    <Location /repos/slave>
      DAV svn
      SVNPath /my/local/copy/of/repos
      SVNMasterURI http://master.example.com/repos/master/
    </Location>

master必须有一个post-commit钩子可以更新所有的slave，一个例子使用svnadmin dump/svnadmin load ，ssh作为支持。svnsync可以完成同样的事情。

此外，如果master版本库支持锁定，锁定数据库需要通过post-lock和post-unlock保持同步，将master状态传递到slave。（用户名保留作为读者的练习），如果不传递锁定信息，用户需要能够精确的检测是否有一个锁定-但是锁定会一直工作。

一个实例的同步脚本可能如下：

   #!/bin/sh
   REPOS="$1"
   REV="$2"
   SLAVE_HOST=slave.example.com
   SLAVE_PATH=/my/local/copy/of/repos

   # Ensure svnadmin is in $PATH on both this machine and the remote server!
   svnadmin dump --incremental -r$2 $1 > /tmp/$2.dump
   scp /tmp/$2.dump $SLAVE_HOST:$SLAVE_PATH
   ssh $SLAVE_HOST "svnadmin load $SLAVE_PATH < $SLAVE_PATH/$2.dump"
   ssh $SLAVE_HOST "rm $SLAVE_PATH/$2.dump"
   rm /tmp/$2.dump

进一步阅读

关于WebDAV代理的更多信息可以看in the repository。

改进和bug修正

Copy/move-related improvements (client and server)

The abilities and behavior of copy and move operations are significantly improved in 1.5+.

Improved copy-handling during updates (client and server)

A common problem in older versions of Subversion was the way in which svn update handled incoming copies and moves.

Consider this scenario: Harry runs svn move foo bar; svn commit, and meanwhile Sally makes local changes to ‘foo’, and then runs svn update. In earlier versions of Subversion, the server would send down a completely new file ‘bar’, and unversion the file ‘foo’ (if it had no uncommitted changes, Subversion would remove it entirely.) From Sally’s point of view, her changes seem to be lost; the newly added ‘bar’ file has the older content, and the file ‘foo’ has been taken out of version control.

In Subversion 1.5, the client and server both attempt to be smarter about this. The server doesn’t send a whole new file during the update, but rather instructions to copy something that likely already exists in the working copy. So Sally’s ‘foo’ file is copied to ‘bar’ (with local edits intact!).

In theory, this is the best-case scenario. There are a few caveats: this “proper copying” of existing working-copy resources only works on files, not (yet) on directories. Also, if an incoming move-operation deletes ‘foo’ before it attempts to copy it to ‘bar’, then the copy will fail, and the client reverts to the old behavior of fetching a pristine copy of the file from the repository. We hope to address this in svn 1.6.

See issue #503 for more.

Peg revisions (client)

Copy and move operations now accept sources with peg (“@”) revisions.

See issue #2546 for more.

Multiple working copy copy/move operations (client)

Clients may now perform chained copy/move operations locally on a single object in a working copy:

   svn mv path1 path2
   svn mv path2 path3

See issue #756 for more.

Improved handling multiple copy/move sources (client)

Clients now accept multiple sources for copy and move operations, with the ability to copy/move each of the sources to the specified directory. This mirrors the behavior of standard command-line copy and move tools, such as cp and mv. For example:

   svn mkdir new_subdir
   svn mv foo.txt bar.txt baz.txt new_subdir

In practice, this means users can take advantage of shell globbing when doing a local copy or move:

   svn cp *.c dir

Multiple source copy/move also works for all previously defined copy/move working copy and repository combinations.

See issue #747 for more.

Copy takes -rBASE (client)

Copy now understands the special revision “BASE” in a working copy (as in: “-rBASE“).

See issue #1643 for more.

Creation of intermediate directories with copy/move (client and server)

See the section on the new –parents option for more about this.

Cancellation improvements (client)

Clients operations are now significantly more responsive to cancellation (e.g. via control-c). In pre-1.5 releases, after directing an operation to stop, one sometimes had to wait for some time (e.g. while I/O occurred) before the operation would actually stop.

Command-line client improvements (client)

There are far too many enhancements and new options to the command-line client to list them all here. Aside from all the ones mentioned already in these release notes, below are a few more that we consider important, but please see the 1.5.0 section in the CHANGES file for a complete list.

New “resolve” subcommand replaces “resolved”

A new resolve subcommand replaces the “resolved” subcommand (the latter is deprecated, but still present for compatibility). The new subcommand takes a --accept=orig|mine|repo option to select which version of a file to retain (which means Subversion now supports batch-style conflict resolution).

See issue #2784 for more.

Create intermediate directories if asked

Add, mkdir, copy, and move take a new --parents option, which makes intermediate directories as necessary to create the destination path.

See issue #1776 for more

New –keep-local option retains path after delete.

Delete (remove) now takes a --keep-local option to retain its targets locally, so paths will not be removed even if unmodified.

Commit now takes a –with-revprop option.

Commit now takes a --with-revprop option allowing one to set revision properties

See issue #1976 for more.

Easier to try out experimental ra_serf DAV access module (client)

Subversion 1.4 introduced the experimental ra_serf repository access module for accessing HTTP[S] DAV Subversion servers. This uses the serf library instead of the Neon library which the original DAV support uses. serf supports pipelined requests which may lead to better performance. However, Subversion 1.4 required you to choose which module to use for accessing DAV servers at build time, which made it difficult to find out which module performs better for your usage patterns.

Subversion 1.5 allows you to build both modules at the same time; you can choose which library to use on a global or host-by-host basis by setting the http-library variable in your run-time server configuration file (~/.subversion/servers). In recognition of the fact that both libraries are DAV clients, we have renamed ra_dav to ra_neon.

API changes, improvements and language bindings (client and server)

There are too many new and revised APIs in Subversion 1.5.0 to even begin to list them all here. See the Subversion API Documentation page for general API information. If you develop a 3rd-party client application that uses Subversion APIs, you should probably look at the header files for the interfaces you use and see what’s changed.

One general change is that most APIs that formerly took a recurse parameter have been upgraded to accept a depth parameter instead, to enable the new sparse checkouts feature.

Language bindings have mostly been updated for the new APIs, though some may lag more than others.

Bug fixes (client and server)

A great many bugs have been fixed. See the 1.5.0 section in the CHANGES file for details.

Subversion 1.3.x series no longer supported

The Subversion 1.3.x line is no longer supported. This doesn’t mean that your 1.3 installation is doomed; if it works well and is all you need, that’s fine. “No longer supported” just means we’ve stopped accepting bug reports against 1.3.x versions, and will not make any more 1.3.x bugfix releases, except perhaps for absolutely critical security or data-loss bugs.

Subversion Dependencies Distribution: Binary Compatibility Issues

Background

APR 0.9.x and 1.x are binary-incompatible. This means if you are already using Subversion with APR 0.9.x, and then upgrade your libapr to 1.X without rebuilding Subversion, things will break. Things will also break if your Subversion server libraries are linked to one version of APR but your Apache HTTPD server is linked to a different version.

For a long time, Subversion’s main source distribution included APR 0.9.x, which was the latest available at the time, along with a few other things (e.g., Neon, zlib) that weren’t yet widespread on installation systems.

Subversion 1.5.0 Dependencies Distribution

Today, these dependencies are no longer exotic, so our source distribution contains just Subversion itself. Those building Subversion are expected to have the necessary libraries already installed, or to be able to fetch them easily. But for convenience, we still offer a “deps” distribution: it doesn’t contain Subversion, it just has source code for those third-party libraries.

Until Subversion 1.5.0, the deps distribution contained APR 0.9.x, but as of 1.5.0, we’re finally upgrading it to APR 1.x. This is because by now there are very few systems that will have binary compatibility issues, and of those, few are likely to build using the “deps” dist.

If you already have a Subversion installation using APR 0.9.x, it’s still possible to move to APR 1.x safely (although you are not required to, unless you use the deps dist). Just be sure to recompile Subversion, and Apache httpd if necessary, after upgrading APR.

Note that it’s perfectly safe to use APR 1.x from the beginning. In fact, we recommend it. If you’re building Subversion for the first time, there’s no compatibility issue to worry about, so just grab the latest version of APR (or use our deps dist).

Related posts:

1. Subversion: Export changed Files in a revision range
2. 使用svnserve的SASL认证
3. FTP image with Conext Menu

SASL核心发布目前支持认证协议有：

• ANONYMOUS
• CRAM-MD5
• PLAIN
• GSSAPI (MIT Kerberos 5 or Heimdal Kerberos 5)
• DIGEST-MD5

也支持如下的认证协议：

• LOGIN
• SRP
• NTLM
• OTP
• KERBEROS_V4

Windows下这些模块可能都保存为dll，你可以选择自己编译，也可以选择获取二进制程序，现在还不清楚官方的Subversion发布会不会包含所有的模块，但是现在已知的Collabnet Subversion包含了几乎所有的模块，下载地址为：

http://merge-tracking.open.collab.net/servlets/ProjectProcess?pageID=3711

SASL配置

linux下的配置文件好说，windows下SASL配置文件需要使用注册表配置，要在你的系统配置SASL，第一步就是设置注册表：

[HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library]
“SearchPath”=”C:\\Program Files\\CollabNet Subversion Server”
“ConfFile”=”C:\\Program Files\\CollabNet Subversion Server”

这个是安装Collabnet Subversion时自动创建的，可以看到有两个键，其中“SearchPath”指明所有的扩展认证方式库存放的路径（那些dll），而ConfFile指明SASL配置文件的路径，在上面的配置里，配置文件应该是“C:\\Program Files\\CollabNet Subversion Server\\svn.conf”。下面看看我们的这个svn.conf文件：

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: ANONYMOUS CRAM-MD5
sasldb_path: C:\svn_repository\sasldb

其中pwcheck_method指明检查的方法，这里是“auxprop ”，这个pwcheck_method还对应了如启动一个代理作为认证服务等方式，而现在的意思就是使用本文件说的方式去检查。然后我们指明auxprop_plugin为sasldb，也就是使用一个文件存放用户名密码，也就是“C:\svn_repository\sasldb”,其它的认证信息存放plugin还有sql和ldapdb。而mech_list指明了认证信息传递机制，现在指明的是ANONYMOUS和CRAM-MD5。 这里还需要做的是创建那个“C:\svn_repository\sasldb”文件：

saslpasswd2 -c -f C:\svn_repository\sasldb -u myrealm username

然后输入密码，这样就在sasldb建立了一个用户，注意“myrealm ”，后面我们还会用到，要想查看建立的用户，可以用：

sasldblistusers2.exe -f C:\svn_repository\sasldb

好的，到此为止SASL部分已经好了，需要注意的是，前面svn.conf的修改要生效必须重启svnserve，这与以前我们修改svnserve.conf立即生效不一样了。我们再去对svnserve作出相应的修改。

svnserve配置

打开一个svnserve管理的库，打开svnserve.conf，把下面这行的注释去掉

use-sasl = true

然后修改realm为前面的myrealm：

realm = myrealm

总结

好的，现在可能就好了，checkout一个工作拷贝，然后提交看看，是不是用了sasldb中的用户名密码。

比较愁人的是，SASL的文档实在太少了，而各种各样的说明也非常不清楚，我也是在不断的整理中逐渐澄清了一些问题。其实SASL更多的是提供了很多认证信息传递的协议，而对于密码保存的方式，他目前只是支持了文件、SQL和LDAP等方式，对于很多人希望的域认证来说，似乎要送ldap访问Active Directory方式入手（后面实际尝试一下），而前面所说的NTLM，只是说认证协议是NTLM的，并不能支持使用现有的域用户认证。

参考资料

• Subversion关于SASL的说明：http://svn.collab.net/repos/svn/trunk/notes/sasl.txt
• Cyrus SASL下载（里面有一些文档，但是要好好看才行）：ftp://ftp.andrew.cmu.edu/pub/cyrus-mail

Related posts:

1. Dreamhost上编译Subversion
2. Windows编译Subversion简要说明
3. Subversion: Export changed Files in a revision range