对 SVNSYNC 的调用是否应该在提交后挂钩中阻塞？

Question

这是我在这里的第一个问题，实际上是从 StackOverflow 移过来的，因为我认为该站点将与该主题更加同步。

我已经设置了我的存储库的镜像并且它运行良好，但我最近遇到了一个问题。

目标存储库以某种方式留下了一个未释放的锁 - 从我读到的这可能是由 svnsync 操作中止引起的，我怀疑这可能是因为在我的提交后钩子中，我在阻塞模式下执行 svnsync 而不是推送它通过 & 进入后台。

我这样做是为了让用户可以确定，如果提交完成，那么它现在在所有存储库中，但也许它会带来他们点击取消并停止提交挂钩的风险？

我找不到明确的指导方针或建议，说明哪个更好或最佳实践是什么，或者即使点击取消会导致 post commit hook 中止和从它执行的同步 - 在大多数地方我看到人们使用 & 踢在后台同步 - 如果用户在同步过程中按下取消提交，这是否可以防止锁损坏？您如何确保两个存储库真正同步或报告问题？你需要一个单独的通知机制吗？

更新：

从以上两个选项中，我决定选择第三个 ;)

我在后台调用 svnsync 但同时我让钩子等待它完成：

svnsync ... &
wait $!

我认为这很好地结合了两全其美，但时间会证明它的有效性 - 请让我知道您对整个问题的看法以及您可能需要分享的建议。

更新 2：它没有解决问题 - 显然，当钩子被杀死时，它也会杀死它的子进程:(

有没有人有任何关于如何解决这个问题的提示？我真的希望我的用户能够知道并相信，当他们看到提交完成时，这意味着所有站点都已同步。

更新 3：时间流逝，问题出现 - 大约 2 年我的方法运行良好 - 我启动了同步非阻塞并且没有等待它 - 上周我们的镜像爆炸可能是由于执行了 2 个不同的提交用户在同一秒（都在主服务器上成功:)）-结果是 svnsync 未能正确复制修订属性，但也创建了一些奇怪的修订（它基本上复制了一个提交并从中创建了一个单独的修订并将其归因于它给 svnsync 用户）。然后抱怨“某人”直接对镜像存储库进行了更改。由于无法删除 SVN 中的提交，我不得不从 0 转到 HEAD-2，这对于 162GB 的强大存储库需要很长时间。现在 - 经过几天的恢复操作 - 我按照下面的建议稍微修改了我的同步。

1. 在提交钩子中，我只是触摸了一个触发器文件。
2. 在 cron 作业中的每一分钟我都会检查这个文件是否存在——如果它存在，我会得到一个“同步锁”并执行提交。

这保证了系统的合理响应，并且 svnsync 永远不会被调用一次 - 一旦时间提供更多数据，我将用信息更新它。

Answer 1

我会考虑将其从提交后挂钩移至 incrond 任务，该任务将使用 inotify 监视存储库的更改，然后运行 ​​svnsync 任务。

作为一个更加模块化的设置，它将为我提供更大的灵活性和统一的配置 - 即我不必不断更新各个用户的提交后挂钩。