com之间的双向同步可能吗

com之间的双向同步可能吗

本文介绍了gerrit和github.com之间的双向同步可能吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

对于github.com私有存储库中存在的项目,我正在设置gerrit代码审查。

我正在使用gerrit的复制插件来保持gerrit存储库与github.com同步。



但如果有人提交(比如 commit-a )并直接推送到github.com,<$ c当gerrit执行复制过程时(因为它仅复制gerrit镜像中的内容),$ c> commit-a 被github.com覆盖。



但我想实现双向同步。就像每当推向gerrit时,它都必须检查github.com并用新代码更新其镜像,然后继续合并。



是那可能吗?

解决方案

这是一个难题。您所描述的多主设置在很多地方都存在,但依靠所涉及的系统进行高度集成和构建以支持此功能。



我看到两个选项:


  • Gerrit和Github都必须能够相互通话,并允许服务器A上的git被锁定,而服务器B更新其REF。一旦B被更新,数据被复制到A,并且A被解锁。此功能不存在,可能永远不会。

  • 接收推送的服务器可能是乐观的,希望并发更新不会发生。对于一个中等繁忙的服务器来说,这大多数时间都不会发生,但如果发生这种情况,那么必须有一个理智的恢复策略。如果并发检查是异步完成的,即使不是不可能,恢复变得困难得多,即,例如, Gerrit在推动Github事务实际上确保交易之前发出信号okay。同步更新可以解决这个问题,但对性能和可靠性不利。


For a project exisitng in github.com private repository, I am setting up gerrit code review.

I am using the gerrit's replication plugin to keep the gerrit repository in sync with github.com.

But if someone commits (say commit-a) and pushes directly to github.com, the commit-a is overwritten in github.com, when gerrit does the replication process (because, it replicates only the things in gerrit mirror).

But I want to implement a 2-way sync. Something like, whenever a push is made to gerrit, it has to check github.com and update its mirror with new code from there and then to continue the merge.

Is that possible?

解决方案

This is a hard problem. Multi-master setups like what you describe exist in many places, but rely on the involved systems to be heavily integrated and built to support this.

I see two options:

  • Both Gerrit and Github would have to be capable of talking to each other and allow the git on server A to be locked while server B updates its ref. Once B has been updated, the data is replicated to A, and A is unlocked. This feature does not exist and probably never will.
  • The server receiving a push could be optimistic and hope that a concurrent update won't happen. For a moderately busy server this won't happen most of the time, but if it does happen there must be a sane recovery strategy. Recovery becomes much more difficult if not impossible if the concurrency check is done asynchronously, i.e. if e.g. Gerrit signals "okay" on the push before actually securing the transaction with Github first. Synchronous updates would solve this but would be detrimental to performance and reliability.

这篇关于gerrit和github.com之间的双向同步可能吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-05 00:08