svn - 如何修复 SVN 409 冲突错误

Question

我曾经在 OS X Leopard 上使用 SVN 1.4，一切都很好。几周前，我安装了 OS X 10.6 的新副本。 Snow Leopard 自带的 SVN 版本是 1.6.5。我继续使用 1.6.6 构建了自己的副本。我正在使用内置的 apache 服务器，只是在本地托管存储库。

在我真正尝试提交某些内容之前，一切似乎都运行良好。每次我尝试提交更改时，都会收到以下消息:

Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/svn/svn2': 409 Conflict (http://localhost)

这发生在我的旧存储库中，因此我创建了几个新存储库。同样的交易。我也试过使用系统自带的1.6.5版本……一样。最后，我尝试升级到最新的稳定 SVN(1.6.9)，但仍然遇到同样的问题。

Apache 错误为每个失败的提交记录以下内容:

[Mon Mar 29 19:53:10 2010] [error] [client ::1] Could not MERGE resource "/svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1" into "/svn/svn2".  [409, #0]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] An error occurred while committing the transaction.  [409, #2]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] Can't open directory '/usr/local/svn/svn2/db/transactions/5-6.txn/\xeb\xa9\x0f\x1f': No such file or directory  [409, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Could not DELETE /svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1.  [500, #0]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] could not open transaction.  [500, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Can't open file '/usr/local/svn/svn2/db/transactions/5-6.txn/props': No such file or directory  [500, #2]

并从访问日志中:

::1 - - [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 401 401
::1 - user [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 200 188
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/vcc/default HTTP/1.1" 207 398
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/bln/6 HTTP/1.1" 207 449
::1 - user [30/Mar/2010:13:02:20 -0400] "REPORT /svn/svn2/!svn/vcc/default HTTP/1.1" 200 1172

奇怪的是，提交确实提交了更改，但工作副本没有看到这一点，一切都变得困惑了。

对于这个问题，我已经尝试搜索所有我能想到的变体，但搜索结果几乎毫无用处。我没有使用 TortoiseSVN 或任何特殊的东西，并且在新存储库上提交失败，所以我知道我的旧存储库没有问题。

任何帮助将不胜感激。

更新
我尝试将自动版本控制添加到我的 svn.conf 文件中。这是我的文件所说的:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNAutoversioning on

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /usr/local/etc/svn-auth-file

  # only authenticated users may access the repository
  Require valid-user
</Location>    

更新(解决方案)

我只是想用实际的解决方案来更新它，以防其他人对完全无用的错误消息有同样的问题。问题出在 apr 和 apr-util 部分(正如 scherand 建议的那样)。我正在使用 subversion 依赖包构建两者的副本。 OS X 10.6 也有它自己的版本。两个版本都是 1.3.8。显然，我需要使用默认 apache 安装使用的版本。

所以，我从我的 subversion 构建中删除了 apr 和 apr-util 文件夹，以确保我不会再次构建我自己的副本。我再次从源代码构建 svn，这次使用以下配置:

./configure --with-apr=/usr/bin/ --with-apr-util=/usr/bin/ --with-ssl

再次构建后，我重新启动了 apache，并创建了一个新的 svn repo。我能够检查它，进行更改并提交，没有任何问题。然后我尝试了我的旧存储库，它们也运行良好。

感谢大家的帮助!

Answer 1

我在这里如履薄冰(409 不是很具体)，但我能够提出两个问题:

是否有任何提交前或提交后的钩子(Hook)？

是否启用了“Autoversioning”？

如果有任何钩子(Hook)，您确定它们不包含任何错误吗？您可以禁用它们进行测试吗？如果未启用 Autoversioning，您可以尝试启用它进行测试吗？这应该按照以下方式工作

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on
</Location>

使用 mod_dav_svn 时(请参阅上面的自动版本控制链接)。

也许这有助于阐明您的问题，我们(和/或 Google :))可以从那里着手。

顺便说一句:您发布的日志不是来自同一个提交，对吧？时差会很大？!？

编辑:
抱歉，如果您很久以前就发现了，但我会试一试: Could not MERGE resource on COMMIT (Apache 2.0.55)是谷歌为我找到的东西 :)

那里的 OP 写道“Apache 规定要使用的 APR 的版本”。这意味着您必须在编译 SVN 时引用正确的 APR 版本。我通过 MacPorts 安装了 SVN (v1.6.9)在我的系统上(OS X 10.6)。我不在本地使用 WebDAV 或 Apache，但我安装了 APR 1.3.12_1(仅供引用)。 OP 建议使用 --with-apxs=/path/to/bin/apxs在编译 SVN 时，虽然我不确定这是否适用于您的情况(我很久以前就开始猜测，您可能会注意到 :))。

您是否有机会检查 Apache 期望的 APR 版本与用于构建 SVN 的版本(例如，如果您使用 MacPorts，您可以使用 sudo port installed apr 来查看系统上存在哪些 APR 版本)？

仅供引用 Building Apache the Way You Want It 的摘录:

apxs is a stand-alone utility for compiling modules dynamically without the need to use the configure script or have the Apache source code available. It does need Apache’s header files, though, which are copied to the location defined by --includedir when Apache is installed. However, it’s important to use an apxs that was built with the same configuration options as Apache; otherwise, it’ll make erroneous assumptions about where Apache’s various installation locations are.