10. リモートバージョンコントロールの内部動作

EFS や ange-ftp と異なり、TRAMP は、リモートマシン上のシェルを実行 します。したがって、TRAMP を使いアクセスしたファイルのバージョン 管理をおこなう事ができます。

バージョン管理をおこなうバイナリが、リモートマシンにインストールされて いなければなりません。そして、tramp-remote-path で指定された ディレクトリに置かれて、アクセス可能でなければなりません。

バージョン管理システムの透過的な統合は、TRAMP のもっとも価値のある 機能のひとつです。しかし、まだ完全にはほど遠い状態です。システムの透過 性を向上させるための作業が続けられています。

10.1 ファイルがバージョン管理されているかどうかの判断

VC パッケージは、ディスク上のマスターファイルの存在をもとに、指定された ファイルがバージョン管理システムの管理下にあるかどうかを判断します。 これらのファイルのテストは、標準的な TRAMP の仕組みを使いリモート マシン上で実行されます。

10.2 リモートマシン上のバージョン管理コマンドの実行

バージョン管理システムのコマンドの実行を横取りすることのできる VC 用の hook は存在しません。call-process の仕組みを使い、 関数呼び出しが発生します。関数は shell-command より、若干 効率的ですが、リモートでコマンドを実行するための hook は用意されていません。

とりあえず動作させるために、関数 vc-do-command と vc-simple-command に、TRAMP を経由しアクセスされたファイルへの オペレーションのためのリクエストを横取することが通知されます。

リモートファイルの場合、ローカルマシンと同じ機能を提供するために、 shell-command インターフェースが、いくつかのラッパーコードと 共に使用されます。

10.3 作業ファイルの変更の発見

今のところ、リモートマシン上のファイルの mtime を取得する移植性の高い 方法は存在しません。vc-workfile-unchanged-p 関数に、リモート ファイルのために TRAMP の関数の呼び出しが通知されます。

tramp-vc-workfile-unchanged-p 関数は、作業ファイルとバージョン 管理マスタファイルの変更点を調べるために VC の diff 機能を使用します。

これを実現するためには、リモートでのシェルコマンドが実行可能でなれば なりません。この処理は、ローカルファイルで使われる mtime の取得より 重い処理です。残念ながら、移植性の高い解決方法が見つかるまでは、リモート バージョン管理のコストはこのままでしょう。

10.4 作業ファイルのリポジトリからの取得

デフォルトでは、VC はリモートファイルをチェックし、リポジトリからチェック アウトされたファイルがある場合は、チェックアウトをおこないません。この問題 を解決するために、関数 vc-checkout は TRAMP ファイルを区別し、 バージョン管理をおこなうことを可能にします。

10.5 その他バージョン管理システムに関係する事

こまかな実装の詳細、その他。

10.5.1 VC がワークファイルのオーナーを調べる方法

Emacs は、任意のユーザー ID の値とログイン名をマッピングするのと同様に、 現在のユーザーのログイン名をかえす関数 user-full-name を用意して います。VC は、いくつかの状況で、ワークファイルのオーナーの uid からログ イン名へのマップ機能を使用します。

これは、リモートシステムが異なるログインセットを持つ場合には、あきらか に正しく動作しません。したがって、uid に対応するログイン名の決定をリモート マシンにおこなわせる必要があります。

残念ながら、NIS、NIS+そして NetInfo のような、 分散管理システム を使う場合、シンプルで、信頼性があり、移植性の高い マッピングの方法は存在しません。

ありがたい事に、uid からログイン名へのマッピングに依存する VC のコードは、 関数 vc-file-owner ひとつだけです。この関数は、ファイルのオーナー のログイン名を文字列として返します。

ログイン名を決定するために、この関数に、リモートマシン上の ls の出力を使用することが通知されます。uid からログイン名のマッピングを、 私よりそれらについて良く知っているはずのリモートシステムに委譲します。

10.5.2 VC が RCS のバージョンを調べる方法

VC は、どのリリースのバージョン管理システムのバイナリを使っているかを 知る必要があります。これは、VC がサポートしているすべての機能を、古い バージョンのrcs(1)、cvs(1)、sccs(1)が提供 しているわけでは無いからです。

VC のデフォルトの実装では、最初に必要になった時に、この値を決定します。 これは、毎回、必要になった時に、プロセスを実行し、その出力をパースする オーバーヘッドをさけるためです。

いかし、リモートのバージョン管理システムの事が関係してくると、人生は それほど簡単ではありません。リモートマシンはそれぞれ、異なるバージョン のバージョン管理ツールをもっています。これが困難な間は、存在しない機能 が、リモートで使用されないことを保証する必要があります。

この問題を解決するために、現在の TRAMP は、バージョン管理ツールの バージョン番号を TRAMP バッファ毎にローカルな変数にし、新しい ファイルを開くたびにVC にこの値を決定させるという力ずくのアプローチ を採用しています。

これはあきらかに性能に影響します。ありがたいことに、VC によっておこなわれる ほとんどの処理は、実際にはリモートのバージョンを知ることを必要としません。 したがって、それほど問題になりません。

最終的には、これらの変数は TRAMP によってシステム毎に調べられ、 その結果は性能を改善するためにキャッシュされるようになるでしょう。