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

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

目标存储库不知何故留下了一个未释放的锁-据我所知，这可能是由于svnsync操作中止所致，我怀疑这可能是因为在提交后挂钩中，我在阻塞模式下执行svnsync，而不是通过&将其推到后台

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

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

更新：

从以上两个选项中，我决定选择第三个；）

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

svnsync ... &
wait $!

---

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

提交后钩子（顾名思义）将在源存储库中创建完全提交和新修订后运行。所以问题是：谁应该如何按下“中止”按钮？另一方面，为什么要执行阻塞操作？我会同步，例如，每15分钟等。独立于提交…如果你真的是新的另一种方式，那么通过代理写入呢？

---

最重要的问题是，为什么每次提交时都需要这样的同步？

@khmarbaise:当你处理乌龟时，提交操作似乎一直在等待，直到提交后钩子完成并在失败时显示输出—即使钩子执行时已完成对主存储库的提交—当您按下“取消”时，我认为同步可能会中止。至于为什么要执行阻止操作-我需要确保两个存储库始终同步，因为许多客户端都在生产中使用这两个存储库，15分钟的不同步会破坏我正在构建的系统（它必须是透明镜像，而不是过期镜像）。据我所知，您可以停止在服务器上启动的执行。另一方面，为什么有两个复制的存储库而不使用一个？（可能会想到Wandisco用于实时复制？）像往常一样-这很复杂：）我使用SVN作为后端为许多机器提供数据-数据必须进行版本控制，分支等。在美国和欧洲有一些站点，存储库目前的大小约为70GB，因此在另一侧安装镜像确实有助于提高流量；）Wandisco可能也能很好地工作，但它并不是真正需要的，因为提交到单个存储库并不是一个问题，现在只需要本地读取就足够了。