这是我在这里的第一个问题，实际上是从 StackOverflow 移来的，因为我认为这个网站将与主题更加同步。
我已经设置了我的存储库的镜像并且它运行良好，但是最近我遇到了一个问题。
目标存储库不知为何留下了一个未释放的锁 - 从我读到的内容来看，这可能是由于 svnsync 操作中止引起的，我怀疑可能是因为在我的提交后挂钩中，我以阻塞模式执行 svnsync 而不是通过 & 将其推送到后台。
我这样做是为了让用户可以确信，如果提交完成，那么它现在就在所有存储库中，但也许会带来他们点击取消并停止提交挂钩的风险？
我找不到明确的指导方针或建议，不知道哪个更好，或者最佳实践是什么，或者即使点击取消会导致提交后挂钩和从中执行的同步中止 - 在大多数情况下，我看到人们使用 & 在后台取消同步 - 如果用户在同步过程中按下取消提交，这是否可以防止锁定损坏？您如何确保两个存储库确实同步或报告问题？您是否需要为此提供单独的通知机制？
更新：
从以上两个选项中我决定选择第三个；）
我在后台调用 svnsync，但同时我让钩子等待它完成：
svnsync ... &
wait $!
我认为这很好地结合了两全其美的优势，但时间将证明它的有效性——请让我知道您对整个问题的看法以及您可能对此有什么建议。
更新2：它没有解决问题-显然当钩子被杀死时它也会杀死它的子进程:(
有人能提供一些关于如何解决这个问题的建议吗？我真的希望我的用户能够知道并相信，当他们看到提交完成时，这意味着所有网站都同步了。
更新 3：时间流逝，问题也随之出现 - 大约 2 年来，我的方法一直效果很好 - 我启动了同步非阻塞，没有等待它 - 上周我们的镜像崩溃了，可能是因为用户在同一秒执行了 2 次不同的提交（在主服务器上都成功了 :) ） - 结果是 svnsync 无法正确复制修订属性，但也创建了一些奇怪的修订（它基本上复制了一个提交并从中创建了一个单独的修订并将其归因于 svnsync 用户）。然后抱怨“某人”直接对镜像存储库进行更改。由于无法在 SVN 中删除提交，我不得不从 0 转到 HEAD-2，对于一个 162GB 的强大存储库来说，这花了很长时间。现在 - 经过几天的恢复操作 - 我按照下面的建议稍微修改了我的同步。
- 在提交钩子中我只需触碰一个触发文件。
- 我会在 cron 作业中每分钟检查此文件是否存在 - 如果存在，我会获得“同步锁”并执行提交。
这保证了系统响应合理，并且 svnsync 永远不会被调用超过一次——一旦有更多数据，我将用信息更新它。
答案1
我会考虑将其从提交后挂钩移至 incrond 任务，该任务将使用 inotify 监视存储库的更改，然后运行 svnsync 任务。
作为一个更加模块化的设置，它将通过统一的配置为我提供更多的灵活性 - 即我不必不断更新各种用户的提交后挂钩。