同期モデル(構成管理モデルとも呼ばれる)(Feiler、1991)は、個々のファイルへの同時かつ並行的な変更を可能にすることで、改訂管理を実現する方法を記述する。
Feiler(1991)は、以下に簡単に説明する4つの異なる同期モデルについて報告している。
チェックアウト/チェックイン モデルでは、ファイルはリポジトリに個別に保存され、ファイルにアクセスするたびにチェックアウトされ、変更があったときにチェックインされます。このリポジトリには、ファイルの複数のバージョンを保存できます。これらのファイルはドキュメントやソース コードである場合もありますが、ファイルの集合である場合もあるため、以降は構成アイテム(CI) という用語を使用します。同時変更による競合を防ぐために使用される基本的なメカニズムは、ロックです。
構成モデルは、チェックアウト/チェックイン モデルの拡張です。このモデルにより、開発者は個々のファイルではなく構成で考えることができます。構成モデルでは完全なチェックアウト/チェックイン モデルが表現されますが、構成管理のサポートを強化することで、さまざまな更新戦略の使用が可能になります。構成は、システム モデルとバージョン選択ルールから構築されると定義されます。システム モデルはどのファイルを使用するかを決定し、バージョン選択ルールはファイルのどのバージョン(たとえば、最新バージョンまたは特定の開発状態)を使用するかを決定します。
ロングトランザクションモデルは、システムが論理的な変更によって構築されるという前提に基づき、より広範なアプローチを採用しています。このモデルは、これらの変更の調整と統合に重点を置いています。基本的には、構成のバージョンとファイルのバージョンを使用します。構成は、別途保存される変更要求に基づいて作成されます。この構成内のファイルは、チェックアウト/チェックインモデルを使用して同期できます。変更が完了すると、完全な構成がリポジトリに保存され、他の変更と統合されます。
変更セットモデルも変更要求に基づいて動作し、ロングトランザクションモデルと多くの共通点があります。ただし、変更のベースとなる特定の構成から始まります。この構成は、個別に寄せられる変更要求に応じて変更されます。そして、ベースラインバージョンに個別に保存された変更のセットを適用することで、製品の新しい構成が作成されます。
この項目では、チェックアウト/チェックイン同期モデルについて、メタモデル(プロセスデータ図)を含めて解説します。チェックアウト/チェックインモデルは、上記で説明した他のモデルにも含まれているため、さらに詳しく説明します。残りの3つの同期モデルと、CIの実際の編集およびそれに関連する手法については、ここでは詳細には触れません。
このセクションでは、チェックアウト/チェックイン同期モデルについて詳しく説明します。

上記のプロセスデータ図は、チェックアウト/チェックイン同期モデルで適用されるさまざまな概念と、それらと実行されるアクティビティとの関係を示しています。メタデータモデル(図の右側)の中心となるのは構成アイテムです。これは1つ以上のリポジトリに格納され、たとえばソースコードファイルや他の構成アイテムの集合体などになります。リポジトリには、複数のブランチとリビジョンのファイルを含めることができます。これらはさらに構成アイテムで構成されます。
メタプロセスモデル(図の左側)は、チェックアウトとチェックインのプロセスを記述したものです。各アクティビティについては、下記の表で説明します。
Feiler(1991)は、チェックアウト/チェックイン同期モデルを評価した。このモデルは、使いやすく理解しやすいという明確な利点がある。しかし、この簡素さゆえに、製品バージョンの追跡や、複数の論理的に接続されたファイル間でのバージョン履歴の確認といった構成管理が不十分になるという欠点がある。
ロックの順番制も、多くの開発者と共同作業を行う際には大きな問題となる。なぜなら、一度ロックされたファイルは他の開発者が編集できなくなるからだ。
チェックアウト/チェックイン同期モデルを説明するために、このセクションではこのプロセスがどのように機能するかの例を示します。下の図は、CIの状態遷移図です。

CI が最初に作成されると、変更されてリポジトリに保存されます。誰かが CI を開くように要求すると、まず開発者のローカル マシンにコピーされます (注: リポジトリで直接編集が行われるシステムもあります。ただし、コピー手順は従来のチェックアウト/チェックイン方式です)。開発者が CI を編集したい場合、ロックを要求します。これは CI を開く要求時に直接行うこともできますが、しばらく読み込んだ後に行うこともできます。CI がまだロックされていない場合、ロックが適用され、開発者が変更できるようになります。変更が完了すると、リポジトリに戻され、ロックが解除されます。ここで、先ほど説明した開発者が、すでにリポジトリにある CI を編集しているとします。リポジトリから CI を開きたいので、ローカル ドライブにコピーされます。読み始めると、変更したい箇所が見つかったので、編集を要求します。しかし、CI はすでにロックされているため、ロックが解除されるまで待つか、ファイルを閉じて別のファイルに進む必要があります。