---

30.1.3.1 マージでの基本的なバージョンコントロール ¶

マージベースの現代的なバージョンコントロールシステム(GitやHgのようなVCS; バージョンコントロールにおけるマージベースとロックベースを参照)では、バージョンコントロールされたファイルをvisitしているバッファー、あるいはVC DirectoryバッファーやDiredバッファーから呼び出されるとC-x v vは以下のことを行います:

• VCファイルセットに1つ以上のファイルがあり、そのファイルがバージョンコントロール状態と矛盾する場合、エラーをシグナルします(ただしファイルセットには新しく追加されたファイルと、変更されたファイルを含むことができることに注意; バージョンコントロールへのファイルの登録を参照)。ファイルセット中のファイルが欠落している(依然としてバージョンコントロールに追跡されているにも関わらずファイルシステムから削除された)場合や、バージョンコントロールから無視されている場合にもエラーをシグナルします。
• VCファイルセットのすべてのファイルが登録済みで、最終リビジョンに照らして未変更の場合には何もしません。
• VCファイルセットにバージョンコントロールシステムに登録されたファイルがない場合には、VCファイルセット内に新たに追加されたファイルを登録します(バージョンコントロールの配下に置く)。バージョンコントロールへのファイルの登録を参照してください。Emacsが登録すべきシステムを見つけられない場合にはレポジトリタイプの入力を求めて新しいレポジトリを作成、VCファイルセットをそれに登録します。明示的にシステムを指定することもできます。C-x v vの高度な制御を参照してください。ファイルの登録はコミットではないことに注意してください。コミットするためにはもう一度C-x v vを呼び出さなければなりません(以下参照)。
• VCファイルセットのすべてのファイルがそれぞれ新たに追加されたり変更されている場合には、変更されたファイルをコミットします。これを行うには、Emacsが*vc-log*バッファーをポップアップするので、その変更にたいするログエントリーをタイプしてから、C-c C-cでコミットします。Log Entryバッファーの機能を参照してください。

  現代的な分散型バージョンコントロールシステム(Git、Mercurial等)での変更のコミットはローカルに行われます、アップストリームのレポジトリ(通常はリモートホスト上にある)に自動的に伝播されることはありません。このような場合には、あなたが最後に更新してからレポジトリが変更されていると、コミットが失敗するかもしれません。その場合にはまずアップストリームから更新を取得して、もう一度試行しなければなりません。これを行うにはC-x v + (ブランチへ/からの変更のpull/push)、あるいはC-x v m (ブランチのマージ)を使用してください。

  集中型バージョンコントロールシステムではアップストリームの変更によってコミットが失敗すると、もう一度C-x v vとタイプすることによってアップストリームのレポジトリの変更をマージします。

• 最後に集中型のバージョンコントロールシステムでは、アップストリームのレポジトリに照らしてVCファイルセットのファイルが古ければ、そのリポジトリからのファイルセットの更新を提案します。

これらのルールは、変更はレポジトリから自動的にマージされない点をのぞき、RCSを非ロックモードで使用している場合も適用されます。あなたがファイルの編集を始めた後に、他のユーザーが同じファイルをコミットした場合、何の情報も与えられません。あなたのリビジョンをコミットしたとき、他のユーザーの変更は失われます(しかし、それはレポジトリには残るので、決定的に失われるわけではありません)。したがって、変更をコミットする前に、カレントリビジョンが変更されていないことを調べなければなりません。それに加えて、このモードでもRCSでロックすることが可能です。変更されていないファイルでのC-x v vは、RCSの通常のロックモードのようにそのファイルをロックします。(ロックでの基本的なバージョンコントロールを参照してください)。

DiffモードのバッファーからC-x v vを呼び出すと、このコマンドはそのバッファーに1つ以上のファイルにたいするpatchセットがあるとみなします。そして変更をそれぞれのファイルに適用して、適切なコミットログメッセージをタイプできるように*vc-log*バッファーをポップアップした後にそれらの変更をコミットします。