本記事の概要
ファイル管理システムはプロジェクトファイル本体をチェックイン／チェックアウト機能で排他制御し、実績データをダウンロード／アップロードで差分管理し、次回のチェックインのタイミングでマージさせますが、排他制御をかけるわけではないので、端末ごとに実績入力ラインを分ける必要があります。本体がチェックアウトされている間も実績データはアップロード可能であり、その本体との差分は次回チェックイン時に本体にマージされます。
バージョン管理システム（VCS）はWordPress公式プラグイン管理で使われるSubversionのようにリポジトリ（Repository 倉庫）をリモートリポジトリで集中管理するものもあれば、GithubやGitbucketのようにコミットはローカルリポジトリに対して行い、リモートリポジトリでマージを行なう分散管理型のものもあります。
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など）から行なえるので、個人の業務ファイルの履歴管理等でも使えます。
