我打算将我公司的 subversion 服务器从 1.6 升级到 1.7。服务器在 linux (Ubuntu AFAIK) 上运行。
我已经阅读了所有这些：
我也读过这些帖子：
subversion-client-version-confusion
如何升级-svn-server-from-1-6-to-1-7
此时此地，我知道如何执行此操作。没什么大不了的。我最关心的是当前的 hooks 基础设施。bash 和 perl 中有几个脚本。
就目前而言，我没有发现任何有关挂钩基础设施更改的信息，但也许我错过了一些已知问题？我应该知道有什么反对升级的吗？
PS：Try and see what comes方法绝对不可用。我希望升级尽可能流畅。存储库用户甚至不应该注意到任何更改。在这件事上我不能让自己失败。
试试看什么方法是绝对不可用的...
是的，可以使用 try and see what come 方法。您构建您的 Subversion 1.6 环境的副本，对 Subversion 1.7 进行更改，并测试直到一切正确。
除非您复制和测试，否则我看不出如何实现安静升级的目标。
Subversion 兼容性保证你的钩子脚本在 1.6 和 1.7 中的调用完全相同。在 1.7（和未来版本）中，可以将更多参数传递给脚本，但旧参数仍然与旧行为匹配。因此，如果您像模板一样创建脚本，忽略“额外”参数，您应该不会看到差异。
Subversion 1.7 自 1.6 以来没有更改存储库格式，因此您甚至可以（意外地）在升级后使用 1.6 中的 svnlook 访问存储库。
我想这取决于你用钩子做什么......
如果你的钩子正在使用svnlook，你应该没有问题。如果您使用的是 API（如 Python API），那么只要您在做某种svnlook类型的事情，您可能也可以。
如果你在不应该戳和戳的地方戳和戳，你可能会开始遇到问题。例如svnlook，你不做，而是做svn。有几个地方的参数发生了变化。另外，如果你做了一个 svn checkout（一个绝对禁止的钩子）然后查看.svn目录，你会得到一个惊喜。遵守规则，线条上的颜色，你的钩子不会有任何问题。
我不知道从 Revision 1.1 到 Revision 1.7 的任何问题会影响行为良好的 hooks，而且我怀疑只要我们还在 Subversion 1.x 中你就不会遇到任何问题。当 Subversion 2.x 出来时，所有的赌注都没有了。
是的，钩子的工作方式发生了一些变化。start-commit 钩子有一个 1.4 及更早版本中没有的额外字段（功能字段），但不会影响当前钩子。而且，在 Subversion 1.5 或 1.6 中，用户现在可以在提交时设置修订属性。这些不会影响当前的挂钩，但可能是您想要合并到当前挂钩中的功能。
升级已执行并成功。Subversion 服务器已更新，没有问题。挂钩的设计没有任何黑客或斜线，尊重规则和常识。这是有风险的，但很有前途，而且是有利可图的（现在结账速度很快）。
只是为了完整起见：有一个连续的集中管理客户端升级。并且存在一些问题，但不是关键和可预测的。转换 svn 客户端 1.6 -> 1.7.7 工作副本格式更改后。每个现有的工作副本都必须手动升级（或清除并再次检查干净）。
服务器升级是安全的。