それは本当にあなたのアプリケーションに依存します。
最も堅牢なシステムは、おそらくCouchDBのようなオブジェクト指向データベースを備えたマスターマスター環境でしょう。
箱から出してすぐに優れたサポートを提供する機能を備えたものもありますが、おそらくより柔軟なアプリケーション側でも実行できます。
ただし、この回答で説明されているアプローチは、ドキュメントエンティティへの変更を要約できる場合にのみうまく機能します。
手順は次のようになります。
すべてのドキュメントはlast_modificationタイムスタンプを受け取ります。
クライアントは、サーバーと最後に同期されたときのタイムスタンプを保存します。
削除されたドキュメントはすぐには削除されませんが、deleted_atタイムスタンプを受け取ります
接続が中断された場合、クライアントはローカルドキュメントの変更を続行できます
接続が再度確立されると、最後の同期タイムスタンプの後に発生したサーバーとクライアントのすべての変更がフェッチされます。
ドキュメントは両方向に更新されます。両側で変更されたドキュメントの競合解決は、lsat_modificationtimestmapに基づいて行われます。
サーバーとクライアントの時間にわずかなオフセットがある可能性があるため、100％信頼することはできないことに注意してください。同期が必要です。また、最初に変更した側で行われた変更を失うことになります。ただし、これはアプリケーションで対処できる問題である必要があります（cvsシステムの競合など）
また、ドキュメントのマージおよび/またはフィールドベースの変更のタイムスタンプがオプションになる可能性があります
すでに述べたように、それは実際にはアプリケーションに依存し、さらにはデータに依存します。
あなたの問題は、ソフトウェア開発（SVNリビジョンなど）のCVSシステムでも発生する問題です。
常にsvnチェックインを実行してからsvn更新を実行することを想像してみてください。Mabyこれは、データをXMLファイルなどに保存する場合にアプリケーションで可能ですか？
SVNは少し古い学校であり、いくつかの欠点があり、信頼性が低いため、この場合は適切ではありませんが、GITはその仕事を非常に行うことができます。
SQL（Mysqlなど）ベースのマスターマスターレプリケーションシステムも非常に強力ですが、保守も非常に難しく、セットアップもそれほど簡単ではありません。
あなたのユースケースについてはよくわからないので、この回答がお役に立てば幸いですが、もう少し詳しく説明していただければ、さらにサポートできる可能性があります。