The core mission of a version control system is to enable collaborative editing and sharing of data. But different systems use different strategies to achieve this. It's important to understand these different strategies for a couple of reasons. First, it will help you compare and contrast existing version control systems, in case you encounter other systems similar to Subversion. Beyond that, it will also help you make more effective use of Subversion, since Subversion itself supports a couple of different ways of working.
あらゆるバージョン管理システムはどれも基本的な一つの問題を解かなくてはなりません: どうやってユーザに情報を共有させつつ、お互いの変更点が重ならないようにするか、です。 リポジトリ上の別の人の変更を間違って上書きしてしまうことは簡単に 起こりえます。
に示したこんな状況を考えてみてください: 二人の同僚、Harry と Sally がいます。 二人は同時に同じリポジトリ内のファイルを編集することにしました。 もし Harry が先に彼の変更をリポジトリに書き込めば、多分、(その少し あとで) Sally は間違って彼女の新しいバージョンでそれを上書きしてしまう でしょう。Harry のバージョンは永久に失われることはありません(と、いうのは バージョン管理システムはすべての変更を記録しているため)が、 Harry がやった修正は、どれも Sally の新しいバージョンには 現れることがありません。編集時には 彼女は Harry の変更を見ることはできないからです。Harry の作業は、 実質的には失われてしまい、—あるいは少なくとも最新のバージョンからは 失われてしまい、— しかもおそらくそれは二人が意図したことではないで しょう。これこそわれわれが避けなくてはならない状況です。
多くのバージョン管理システムでは、 ロック・修正・ロック解除のモデルを使ってこの問題 を扱います。そのようなシステムでは リポジトリ中のファイルを変更できるのは一度に一人だけです。 最初 Harry はファイルに変更を加える前に、「ロック」しなくては なりません。ファイルのロックは、図書館から本を借りるのにいろんな意味で よく似ています。もし Harry がファイルをロックすると、Sally は同じ ファイルに変更することができなくなります。ロックしようとすれば、 リポジトリはその要求を拒否します。彼女ができるのはそのファイルを 読むことと、Harryが仕事を終えてロック解除してくれるのを待つことだけ です。Harry がロックを解除したあと、彼の番は終わり、今度はSallyが ロックして編集することができる番になります。図 1.3. 「ロック・修正・ロック解除の解法」はこの単純な解法の例です。
ロック・修正・ロック解除のモデルの問題は、ファイル管理が少し厳しすぎる ことで、しばしば、ユーザとって作業の障害になります:
ロックすることは管理上の問題を起こすかも知れません。 ときどきHarryはファイルをロックしたあとでそのことを忘れてしまいます。 いっぽう Sally はずっと自分の番を待っているので、その間何もすることが できません。そしてHarryはそのままバカンスに行ってしまい、Sallyとしては 管理者に対してHarryのロックを解除してもらうように頼まなくてはならなく なります。この状況は不要な遅れと、時間の無駄を起こします。
ロックは不要な直列化を起こすかも知れません。 Harryはそのテキストファイルの先頭の部分を修正して、Sally は同じファイルの 最後の部分を修正したいだけだとしたら? 二人の修正はまったく重なって いません。適当な形でマージされることさえ保証できれば、二人は同じファイル を同時に編集することができ、それが大きな問題にはならないでしょう。
ロックは誤った安心感を与える可能性があります。 Harry はファイル A をロックして編集し、Sally はファイル B をロックして編集するとします。A と B はお互いに依存しあっている場合、変更すると意味的に矛盾が発生します。突然 A と B がもう一緒には動作しなくなります。ロックするシステムはこの問題に対しては無力です。— ある意味、誤った安心感を与えていると言えるでしょう。Harry も Sally も、ファイルをロックすることでそれぞれ安全な状態に入り、自分の作業は他人から分離されていると錯覚することは、簡単に起こりえます。これにより、早期に非互換の変更について議論することを、妨げてしまいます。ロックはしばしば真のコミュニケーションの代わりに使われます。
Subversion, CVS, and many other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work simultaneously and independently, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.
例をあげます。 Harry とSally が同じプロジェクトに対するそれぞれの作業コピーをリポジトリ の内容をコピーして作ったとします。 彼らは平行して作業し、変更をまずは自分の作業コピーの同じファイルAに対して 行います。Sally は自分の変更を先にリポジトリに保存します。 Harry が変更をあとで保存したいと思ったとき、リポジトリは、彼に対して Aは既に最新ではないことを伝えます。 言い換えると、リポジトリにあるファイルAは彼がそれをコピーした後で 別の人によって修正されていることを伝えます。そこで Harry は、Subversion のクライアントプログラムに、自分の作業コピーAに対して、リポジトリにある 新しい変更点をマージするように要求します。 Sally の変更が彼のもので上書きされることはありえません。ひとたび彼が 両方の変更を統合してしまえば、自分の作業コピーをリポジトリに書き戻す ことができます。図 1.4. 「コピー・修正・マージの解法」と 図 1.5. 「コピー・修正・マージの解法(続き)」 はこの処理を示しています。
しかし、Sallyの変更点がHarryのと重なって いたら? そのときはどうなるのでしょう? この状況は 競合 と呼ばれ、普通はあまり大きな問題にはなりません。 Harry が Subversion クライアントプログラムにリポジトリの最新の変更を 自分の作業コピーにマージするように要求したとき、彼の A ファイルの作業コピーは、競合状態としてマークされます。彼は両方の変更の競合した部分を見ることができ、どちらを選ぶかを選択します。ソフトウェア自体が 自動的に競合を解決することはできないのに注意してください。人間だけが理解し、正しく選択する力を持っています。Harry がいったん重なっている部分の修正を手で解消したら — おそらく Sally と競合について話し合った あと — マージされたファイルをリポジトリに安全に書き戻すことができます。
コピー・変更・マージモデルは少々混沌としているように見えますが、実際にはとてもスムーズに事が進みます。ユーザは他の人を待つこともなく、平行して作業を進められます。同じファイルに対して作業を行った場合でも、ほとんどの変更は重ならないことが判ると思います。そして、競合を解消するのにかかる時間は、ロックシステムで失われる時間よりも、通常ずっと少ないのです。
In the end, it all comes down to one critical factor: user communication. When users communicate poorly, both syntactic and semantic conflicts increase. No system can force users to communicate perfectly, and no system can detect semantic conflicts. So there's no point in being lulled into a false sense of security that a locking system will somehow prevent conflicts; in practice, locking seems to inhibit productivity more than anything else.