对SVNSYNC的调用应该阻塞还是不处于后提交钩子中？

Question

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

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

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

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

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

更新：

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

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

svnsync ... &
wait $!

我认为这两个世界的最佳结合，但时间将显示它有多有效-请让我知道你对整个问题的看法，以及你可能需要分享的建议。

Update2:它没有解决这个问题--显然，当钩子被杀死时，它也会杀死它的子进程:(

有谁会对如何解决这个问题有什么建议吗？我非常希望我的用户能够知道并相信，当他们看到提交完成时，这意味着所有站点都是同步的。

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

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

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

Answer 1

我会考虑将它从后提交钩子转移到incrond任务，后者将使用inotify监视存储库中的更改，然后运行svnsync任务。

作为一个更模块化的设置，它将为我提供更多的灵活性与统一的配置-也就是说，我将不必继续更新各种用户的后提交挂钩。