バージョン管理におけるコピー・マージ方式【チェックアウト/インで排他制御しダウン/アップロードで差分管理】

ファイル管理システムはファイル本体をチェックイン／チェックアウト機能で排他制御し、データをダウンロード／アップロードで差分管理し、次回のチェックインのタイミングでマージさせますが、排他制御をかけるわけではないので、データの上書きがないように作業分担が必要です。

Evernoteのバージョン管理

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

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

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

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

Asprova DSの排他制御とマージ機能

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

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

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

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

バージョン管理システム

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

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

PCからのリポジトリ操作はGUIクライアント（SourceTreeなど）から行なえるので、個人の業務ファイルの履歴管理等でも使えます。

実績入力の方法

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

ただし差分のマージはあくまでテーブルのキーを基準に行なうとはいえ、排他制御をかけるわけではないので、同一レコードを同時に複数端末から修正を行なう場合は上書きが起こりますので、実績データなどは端末ごとに入力するラインの担当を分けて上書きを防止する必要があります。

本体がチェックアウトされている期間でも実績データはアップロード可能であり、その本体との差分は次回チェックインのタイミングで本体にマージされます。

但しスケジューラーの場合、実績入力は計画に対して行なうもので、生産管理システムでいう計画外製造実績入力は基本行ないません。

つまり現場担当者はPPICの担当者が作成した計画リストから該当計画作業（製造指図）を探し出して開始日時、終了日時、実績数量等の入力を行ないますが、システム上からリアルタイムでこれを行なう作業負荷は高いです。

よってリアルタイムに実績収集したいのなら現場端末からバーコード付きの現品票をスキャンさせると効率的ですが、システム導入前に「本当にリアルタイムが必要なの？」という問題意識があってしかるべきだと思います。

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

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

クライアントPCからのデータアクセス

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

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

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

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

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

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

データサーバーによる本体と差分の管理機能

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

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

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

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

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

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

ログファイルはインストールフォルダのasnlslog.csvにサイト情報、ユーザー情報、時間、処理内容等を記録していきます。またインストールフォルダの中の\licensefileフォルダにライセンスファイルを置くことで、サーバープログラム起動時にライセンス情報を確認します。