コピー・マージ方式によるバージョン管理と差分管理

データベースを使わない差分管理では、ファイル本体をチェックイン／チェックアウトで排他制御し、データをダウンロード／アップロードで差分管理し、次回のチェックインのタイミングでマージさせます。

: ITサービス

インターネット技術の急速な発展と普及により、優秀なIT人材を輩出することで知られるジャカルタのビヌス大学（BINUS）やバンドゥンのバンドゥン工科大学、インドネシアコンピューター大学（UNIKOM）の学生の多くがインターネット・WEB業界やソフトウェア業界を志望するようです。

続きを見る

Evernoteの同期処理で発生する競合

僕はPCとスマホでEvernoteを使っており、自宅でPCで修正したノートを車の移動中やスタバで再修正することがよくありますが、4G全盛期に入りつつあるインドネシアの通信事情はまだまだ不安定であり、同期が失敗した状態で1個前のバージョンを元に修正したあとに、電波のいい場所で同期成功したりすると、「競合する変更」が発生します。

自宅であろうと外であろうと、Evernoteを使用する前に必ず同期をする、それが嫌ならEvernote WEBを使え、となるのでしょうが、せっかく有料のプレミアム会員になっているのだから、Tolを高速で走る車の中や電波の悪いジャカルタ郊外の工業団地でもガンガン使いたい。

そうすると「競合する変更」もガンガン増えていくわけですが、そもそもEvernoteに書く内容は「下書き」とか「草稿」の意味あいの強い内容ばかりなので、競合してもどっちか消せば大して困ることはありません。

ところがWEBシステムのチーム開発等では、ソースコードに排他制御かけるとチーム全体の作業効率上NGなので、同一ソースコードの同時修正が発生したとしても、お互いの差分を明確に管理する仕組みが必要になります。

コミットという概念

バージョン管理をする上でコミットという概念が出てくるのですが、元々は英語のcommitmentの略で「結果を約束する」「積極的に関わる」という意味で、データベース上でSQLのUPDATE・INSERT・DELETEを何回か実行する場合には、変更をまとめてデータベースに反映するという意味になります。

Googleスプレッドシートには保存ボタンがありませんが、定期的に変更履歴として自動保存されるので、過去のバージョンに戻って再編集することができます。この過去のバージョンに戻れるポイントが、スプレッドシートが自動的にコミットしてくれたタイミングになります。

WordPressで長文記事を書いているときに、自動保存された30分前のレビジョン（改定）に戻って記事を書き直すということがよくありますが、これはWordPressが自動的にコミットしてブラウザ内に30分前のバージョンを保存してくれていたということになります。

このように過去のバージョンに戻ることができるポイントはコミットにより決定されるわけですが、複数人が同時並行で作業を行う場合は、排他制御（チェックアウト）をかけていない限りEvernoteと同じく競合が発生します。

コピー・マージ方式によるバージョン管理

バージョン管理システムは排他制御をかけるロック方式と、複数ユーザーが1つのファイルをコピーし、同時に修正した場合の差分をマージするコピー・マージ方式がありますが、バージョン管理システムのスタンダードになりつつあるGitはコピー・マージ方式です。

Gitは元々Linuxカーネルのソースコード管理のためのリポジトリ（Gitで管理されたフォルダ）のパッケージですが、今ではシステム開発全般のバージョン管理に汎用化されており、GitのリモートリポジトリのホスティングサービスであるGithubやGitLabのアカウントをとればリモートリポジトリと連携した分散型バージョン管理に基づくチーム開発が可能になります。

ただ一般ユーザーにはCUI（Character User Interface）からGITを操作するのは敷居が高いので、PCからのリポジトリ操作用のGUIクライアント（SourceTreeなど）があります。

Atlassian社SourceTreeによる分散型バージョン管理

ローカル環境にフォルダを作成し、そこにGITでバージョン管理されているリモートリポジトリ（リモートのmasterブランチ）をクローン（複製）することで、ローカルリポジトリが生成される（ローカルのmasterブランチがあるだけの状態）。
ローカルリポジトリのmasterブランチから新規ブランチを作成し、チェックアウト（masterブランチから新規ブランチへ移動）した状態で開発を行い、作業対象をステージ（コミットする対象を確定）してコミット（更新した結果がセーブポイントとなる）することで、masterブランチとmasterブランチから派生した複数のブランチが作成される。
各ブランチをマージすることでローカル内で統合される。

差分管理システムの排他制御とマージ機能

データベースが排他制御によりレコードの整合性を確保するのと同じように、差分管理システムであるAsprovaのDS（データサーバー）では、プロジェクトファイルの本体はチェックイン／チェックアウトで整合性を保ちます。

例えばAさんがプロジェクトファイル本体をチェックアウト（データにロックをかける）して、2月の受注オーダーを追加してリスケジュールしている間に、Bさんがローカルの作業フォルダにプロジェクトファイルをダウンロードして製造BOMを追加してから、Aさんがチェックイン（データを保存しロック解除）したタイミングで、Bさんが製造BOM修正後のファイルをアップロードすると、Bさんの製造BOMの追加分（差分）はtransactionフォルダに圧縮保存され、次に誰かがチェックインしたタイミングでプロジェクトファイルにマージされ、差分はhistoryフォルダに移動します。

チェックアウト／チェックインでプロジェクトファイル本体を排他制御し、ダウンロード／アップロードでテーブルデータの差分管理をし、次のチェックインのタイミングでマージされるという仕組みです。

ただし差分のマージはあくまでテーブルのキーを基準に行なうとはいえ、排他制御を行うのはプロジェクトファイル本体のみで、実績テーブルに排他制御をかけるわけではないので、同一レコードを同時に複数端末から修正を行なう場合は上書きが起こりますので、実績データなどは端末ごとに入力するラインの担当を分けて上書きを防止する必要がありますが、本体がチェックアウトされている期間でも実績データはアップロード可能であり、その本体との差分は次回チェックインのタイミングで本体にマージされます。

ネットワーク上での共同作業には複数端末からの更新をコントロールし整合性を保つ排他制御の仕組みが必要ですが、通常はサーバー上のデータベースがこの機能を担います。

但しデータベースを使わない差分管理システムの場合、ファイル本体と差分を切り離し管理することにより排他制御と統合を実現します。

クライアントからのデータ操作の流れ

ネットワーク上に接続される計画作成端末（MS）や実績入力端末（MES）は、データサーバー（DS）への初回ログイン時にローカルの作業フォルダにワークスペースファイル（as.adw）を生成し、次回以降これをみてサーバーにアクセスします。

端末ごとに作業フォルダを作成し、チェックアウトせずにプロジェクトファイルを取得する場合は「最新バージョンの取得」を行い、作業フォルダにプロジェクトファイル（data.aru）を保存し、「最新バージョンで開き直す」で最新バージョンをチェックアウトせずに開き直します。

MSではチェックアウト前後で表示されるメニューが異なり、プロジェクトファイルをチェックインした後は

最新バージョンの取得（通常は実績端末から行なう）
チェックアウト（計画作成端末からのみ可能）

プロジェクトファイルをチェックアウトした後は

最新バージョンで開き直す（プロジェクトファイル）
チェックイン（プロジェクトファイル）
チェックアウトの取り消し（プロジェクトファイル）
テーブルダウンロード（テーブルファイル）
テーブルアップロード（テーブルファイル）

ネットワーク障害時には、作業フォルダに保存されたプロジェクトファイルをオフラインで修正し、後でチェックインすることも可能です。チェックインとは宿泊手続きを取るのと同じように、ローカルで修正したファイルをDS側に登録管理してもらう手続きのことです。

注意点として、排他制御されるのはプロジェクトファイルのみであり、実績テーブルやBOMは排他制御されないため、データの上書きが発生しないようにライン別に担当者を分けるなど運用でカバーする必要があります。

データサーバーによる差分管理

データサーバーはデータベースを使わないので、ファイル管理機能だけで以下の機能を実現します。

サイト管理（サイトフォルダ内のassite.txt）
ユーザー管理（サイトフォルダ内のasuser.txt）
データ管理（サイトフォルダ）
バックアップ管理（サイトフォルダ）
ログ管理（インストールフォルダ）
ライセンス管理（インストールフォルダ）

プロジェクトファイル本体を排他制御し、本体（オーダテーブル・作業テーブル・BOMなどの集合体）と実績（実績テーブルの差分）の統合を管理するのがデータ管理です。

DS上にサイトフォルダ（D:\Asprova MS）を作成しdata.aruを置き、DSのユーティリティのサイト管理でサイトを登録するとassite.txtが生成され、ユーザー管理からユーザー登録をするとasuser.txtが生成されます。

計画作成担当者が複数人いる環境で、ある計画作成端末（MS）がプロジェクトファイル（data.aru）をチェックアウトすると、DSが排他制御をかけるので他のMS端末はチェックアウトできません。

チェックインすると、まず\history\dataフォルダ内に現行プロジェクトファイルが履歴としてバックアップされ、次に\transactionにあるアップロード済み未統合の差分ファイルをプロジェクトファイル本体に統合し、最後に差分ファイルが\history\tableに履歴として保存されます。つまり\transactionには未統合の差分ファイルが次のチェックインを待っている状態ということになります。

チェックイン（本体）またはアップロード（差分）が発生するたびにデータサーバー（DS）は各端末にファイル更新の通知を送ります。