によるとは

によるとは？

[ 22] Subversion によるバージョン管理
[引用サイト]　 http://subversion.bluegate.org/doc/book.html

なく、著者がユーザに聞いて欲しいことが書いて
ウェアテクノロジを通じた生産性の向上の方法について知りたいと考えて
です。技術サポートに電話をして「どうやったら生産性が最大になる
本当はもっとずっと具体的な質問がしたいのです、たとえば「どうやったら
カレンダーシステムを変更して一日前でなく、二日前に通知するように
やってくる問いを追いかけ、それに対する答えを見守り、それらすべてを
集めて経験の浅いユーザの集約的な経験を反映するように検索可能な形に
まとめる必要があります。それは忍耐が必要で、自然主義者のように物事
を黙って観察する態度が必要になります。ここには権威に基づいた仮定や
この本について私が気に入っているところは、そんな過程を通じて絶えず
本が育っていくところであり、それはすべてのページに現れています。
この本はユーザに対する著者の対峙そのものの結果なのです。それは
ものなのだろうか? ブランチやタグは他のバージョン管理システムと
同じように機能するのだろうか? 誰が特定の変更を加えたということを
する際のすべての基本を扱っていました。マニュアルは完成したような
の本を出版しようと決めたとき一番手っ取り早い方法は明らかでした:
新しい本の三人の共著者は普通ではない幸運に恵まれていました。公式には
彼らの仕事は本をトップダウンに書き下すために目次を作ることからはじめ、
初期ユーザの手にあり、それらのユーザは無数のフィードバックをもたらし
注意深く実際の状況下でユーザが実際に陥る本当の問題を記録してきました。
彼らが書き上げたこの本は、そんな作業を反映しています。しっかりとした
経験を基礎とし、希望的観測に流されず、この本はユーザマニュアルと
の一片の率直な記述になっています。概略について書かれ、不可欠な同伴
そしてもちろんコマンドリファレンスと、障害時の対応法があります。
それは具体的な問題の解法を探しに後で戻ってきてはじめて意味が理解
できるでしょう: そこで語られている詳細は不測の事態に陥った時にしか
関係してきませんし、利用例は本当のユースケースを洗練したものですし
ほとんどすべての部分がユーザのニーズとユーザの視点への配慮であふれて
答えられるとは約束できる人はいません。質問の期待に、ときどき
コミュニティーの知識の中の落とし穴にはまりこんでしまい、手ぶらで
出てくるようなことも、しばしばおこるでしょう。そんな時の一番よい
送って自分の問題を示すことです。著者らはまだそこにいますし、依然と
してリストを監視していますし、本の扉に書かれた三人以外にもたくさんの
人が誤りの訂正や最初の資料について貢献してくれています。コミュニティー
の観点から言うと、あなたの問題の解決は単にもっとずっと大きなプロジェクト
助けることができるということだけではなく逆に皆を助けるということができる
他のすべての活発なフリーソフトウェアプロジェクトでも同じです。
フリーソフトですし、その制約のないワークフローモデル
は、オープンソースの世界での共同作業のやり方に非常によく合っています。
活発で精力的な開発コミュニティーを持ち、既に今後計画されているさまざまな機能や
改良点があるため、この本にあるコマンドや特殊な注意事項のいくつかは変更される
オペレーティングシステム上で動きますが、一番力を入れているユーザインターフェースは
コマンドラインベースのものです。それでこの本で議論したり利用するのもコマンド
コマンドラインインターフェースに比較的慣れていることを前提にしています。
ほとんどの読者はおそらくプログラマか管理者で、ソースコードの
一番普通の使い方なので、この本の例もそういう状況を前提にしています。
単なるデータにすぎません。この本は読者がいままでバージョン管理システムを一度も使ったことは
あります。この本の読み方この本は非常にさまざまな背景を持った人々にとって有用であることを
積んだシステム管理者までのすべての人たちです。どのような知識を既に持っているか
に応じて、特定の章が何らかの意味で重要になるでしょう。以下はさまざまな読者層
にして最初のリポジトリを作り、ネットワーク越しに利用できるようになるかが
ユーザであれ管理者であれ、最終的にはあなたのプロジェクトは大きくなって
などなどです。このふたつの章は最初はピンとこないかも知れません
に関する補足情報です。この本全体を一度読み終えたあとで戻ってくる
のはきっとこの章でしょう。この本での約束ごと
ここではこの本で利用されるさまざまな規約について触れます。
印刷上の規約固定幅コマンド、コマンド出力、スイッチに使いますイタリックな固定幅プログラムやテキスト中で置き換え可能なアイテムに対して使いますイタリックファイルやディレクトリの名前に使いますアイコン注意このアイコンは周りにあるテキストに関連した注意を
ティップこのアイコンは周りにあるテキストに関連したヘルプ
警告このアイコンは回りにあるテキストに関連した警告を
普通のやり方でコンパイルできるとは思いますが、問題点を簡単に示すためのものであり、
良いプログラミングスタイルの例として載せたものではありません。この本の構成以下の章とその内容をここで一覧にしておきます:
構成要素、そしてインストール方法についての章です。またクイック
そしてあるブランチから別ブランチにどうやって簡単に乗り換えるかなども
作業コピー中に外部ツリーを含める方法、そして最後にベンダーブランチ
の管理領域についてプログラマーの視点から説明します。
のそれぞれのサブコマンドについてすべてのケースでの豊富な例をまじえながら詳細に
悪い習慣からどうやって抜け出すかについてのさまざまなアドバイスをします。
パッチの形で送ってもらうほうがずっと助かりますが。
バージョン管理は情報に対する変更を管理するための技法です。
それは小さな変更をソフトウェアにしたあと、次の日にはその変更を取り消すという
ような作業をするプログラマにとっては、長い間非常に重要なことでした。
しかしバージョン管理ソフトウェアの有用性はソフトウェア開発の世界をはる
かに越えた汎用性があります。頻繁に変更されるような情報を管理しなくては
ならないようなコンピュータを使っている人々がいる場所では常にバージョン
何をするものであり、そしてそのためにはどうしたらよいか、についての導入
時間とともに変化するファイルやディレクトリを管理します。
ファイルの階層構造全体は、リポジトリと呼ばれる
中心的な場所に置かれます。リポジトリは通常のファイルサーバとよく似ていますが
メンバーがファイルやディレクトリにしたすべての変更を記録しています。
このため、メンバーは古いバージョンのデータを戻したり、変更履歴を確認したり
コンピュータで作業する人々によって利用することができます。ある範囲で
それぞれの場所からの同じデータの集まりをさまざまな人が修正し管理する
仕組みは共同作業を支援することができます。すべての変更を一つの流れに
そって行うわけではないので作業効率をより高めることができます。
さらに作業はバージョン化されているので、作業品質が流れを中断
データに対して間違った変更をしてしまった場合には単にそれを取り消せばよい
でもあります。そういうシステムは、ソースコードのツリーを管理するために
ことができたり、ソフトウェアを構成するのに必要なツールが付属していたり
タイプのファイルの集合も管理できる一般的なシステムです。あなたにとって
食料品の買い物リストから、デジタルビデオの編集、そしてもっと他のもの
共同作業用のソフトウェアを提供しています。それはバージョン管理システムをその
いましたが、それは単に、少なくともフリーライセンスの下ではそれより良いも
のが何もなかったというのが理由の大部分でした。
プロジェクトに参加する気はないかどうかたずねました。ちょうど同じころ
持っていたことがわかり、最終的に自分たちがその企画に対して何らか貢献
最初の設計チームはいくつかのシンプルな目標を決めました。それはバージョン
は大部分のオープンソースプロジェクトのように実力主義を促進するような緩やかで
理解する必要はありません。そしてバージョン管理についてまったく知らない
についての親切な手引きを用意してあります。
バージョン化されているファイルを置き換えることはできません。
コピー、名称変更をすることができます。そして新規追加されるすべての
ファイルは、そこから新しく始まるきれいな履歴を持つことになります。
変更点の集まりは、それ全体がリポジトリに完全に反映されるか、
まったく反映されないかのどちらかです。これにより開発者は
論理的にひとまとまりの変更を作りコミットすることができ、
一部だけがリポジトリに反映されてしまうような問題を回避する
キー/値の組を生成し保存することができます。属性もファイルの内容と
ネットワークプログラムを簡単に実装できるようになっています。
非常に有利になりサーバが提供している既存の機能をすぐに利用
簡単に読むことのできないデータ)に対しても同じ方法で働きます。
どちらのタイプのデータもリポジトリ中に同じ形式で圧縮されて格納され、
差分はネットワーク上どちらの方向にも転送されます。
ブランチとタグを作成するコストはプロジェクトのサイズに比例するわけでは
単にプロジェクトをコピーすることでブランチとタグを作ります。そのため
です。もう一方はクライアントプログラムで、バージョン化されたデータの
通信路があります。そのいくつかはコンピュータネットワークをまたいで
リポジトリにアクセスするためのネットワークサーバ越しに通信します。
他のものはネットワークを利用せず直接リポジトリにアクセスします。
には、ボランティアによって作られたダウンロード可能なパッケージが
固有のパッケージ配布システムを使うこともできます。
ウェブサイトから最新のソースコードリリースを取得してください。解凍した
ファイル中の説明に従って作ってください。ソースパッケージには
リモートリポジトリにアクセスするためのコマンドラインクライアントを
すべてのパッケージが手元にあることを確認してください。既にある
減らすために非常に多くのページがこの後に用意して
作業コピーの(アイテムが存在するリビジョンに関係した)状態についての報告をするプログラムです。
リポジトリをネットワーク上の別のユーザが利用できるようにするものです。
ネットワーク越しにリポジトリを使えるようにする別の方法です。
ことにします。あなたが経験によって学ぶやり方を好むようなタイプの人であ
リポジトリに格納します。最初に新しいリポジトリを作りましょう:
この新しいディレクトリには(他のファイルに混じって)データベースファイルの
集まりを含んでいます。内部を詳細に知る必要がないのであれば
このバージョン化されたファイルを見る必要はないでしょう。
リポジトリ生成と保守についてのより詳しい情報は
リポジトリは単なる仮想的にバージョン化されたファイルシステム
であり、どんなデータも含むことのできる大きなツリー構造です。
管理者によってはひとつのリポジトリにひとつのプロジェクトだけを
入れることを好みますが、他の管理者はディレクトリを分割した形で
複数のプロジェクトを格納することを好みます。両者のメリット、
デメリットについてはリポジトリレイアウトの選択の項
で議論します。どちらの方法でもリポジトリは単にファイルとディレクトリ
であると解釈するかどうかは人間にまかされています。それでこの本をつうじて
プロジェクトを参照するときには、リポジトリに存在する、いま言ったような形
のいくつかのディレクトリ(あるいはディレクトリの集まり)についてだけ話を
何かのプロジェクト(ファイルとディレクトリの集まり)があるものと
という単一のディレクトリに編成されているものとしましょう(
名前の三つの最上位ディレクトリを含む必要があります。
必要なものではありません。後で利用する時におそらくもっとも便利になる
これでリポジトリにツリーのデータが入りました。この時点で
を作ります。ここが実際の作業を行う場所になります:これでリポジトリにツリーのデータが入りました。
すでに注意したように、リポジトリ中のファイルやディレクトリを詳しく
調べる必要はありません; すべてはデータベース中に格納されているもの
だからです。しかしリポジトリの仮想的なファイルシステムを考えると、
ディレクトリ中にリポジトリのプライベートなコピーを手にしたことに
なります。作業コピー中のファイルを編集し、その変更点をリポジトリに
書き戻すためにコミットすることができます。作業コピーに行ってファイル内容を修正します。
第2章基本概念目次リポジトリバージョン管理モデルファイル共有の問題ロック・修正・ロック解除の解法コピー・修正・マージの解法実行中のSubversion作業コピーリビジョン作業コピーはどのようにリポジトリを追いかけるか混合リビジョン状態の作業コピー更新とコミットは別の処理です混合リビジョンは正常な状態です混合リビジョンは役にたつものです混合リビジョンには制約がありますまとめ
バージョン管理システムの利用が初めての人は、必ずこの章を読んでください。
コンピュータプログラマだけを助けるものではないのです。
です。リポジトリは情報をファイルシステムツリー
任意の数のクライアントがリポジトリにアクセスし
このようなファイルの読み書きをします。データを書き込むことでクライアントは
他の人たちがその情報を使えるようにします。データを読み出すことでクライアントは
定義にすぎないように思います。そして実際、リポジトリはファイルサーバの
クライアントがリポジトリからデータを読み出すときには、普通はファイルシステム
ツリーの最後のバージョンだけが見えます。が、ファイルシステムの
といった履歴に関する質問をすることができます。
この手の質問はすべてのバージョン管理システム
のキモになるような質問です。つまりバージョン管理システムとは時間と共に
修正されるデータを記録したり、修正内容を追跡したりするようにデザイン
あらゆるバージョン管理システムはどれも基本的な一つの問題を解かなくてはなりません:
どうやってユーザに情報を共有させつつ、お互いの変更点が重ならないようにするか、です。
リポジトリ上の別の人の変更を間違って上書きしてしまうことは簡単に
二人は同時に同じリポジトリ内のファイルを編集することにしました。
バージョン管理システムはすべての変更を記録しているため)が、
ロック・修正・ロック解除のモデルを使ってこの問題
リポジトリ中のファイルを変更できるのは一度に一人だけです。
なりません。ファイルのロックは、図書館から本を借りるのにいろんな意味で
ファイルに変更することができなくなります。ロックしようとすれば、
リポジトリはその要求を拒否します。彼女ができるのはそのファイルを
ロック・修正・ロック解除のモデルの問題は、ファイル管理が少し厳しすぎる
ロックすることは管理上の問題を起こすかも知れません。
ロックは不要な直列化を起こすかも知れません。
最後の部分を修正したいだけだとしたら? 二人の修正はまったく重なって
いません。適当な形でマージされることさえ保証できれば、二人は同じファイル
を同時に編集することができ、それが大きな問題にはならないでしょう。
ロックは間違った意味の安心感を与えてしまう場合
依存しあっていて、それぞれに対する独立した変更は両立しないとしましょう。
ことでそれぞれ安全な状態に入り、自分の作業は他人から分離されていると
錯覚することは簡単に起こりえます。このことが、最初に述べたような
実は両立しない変更についての議論を妨げてしまうかも知れません。
アイディアとしてコピー・修正・マージモデルを
使います。このモデルではユーザごとのクライアントプログラムはプロジェクト
リポジトリにアクセスして自分だけの作業コピーを
コピーしてきたものです。それからユーザは
ひとりひとりが平行して作業をし、自分の作業コピーを修正します。
最後に自分のコピーは最終的な新しいバージョンにマージされます。
このバージョン管理システムは大部分のマージを手伝いますが
最終的には正しいマージかどうかについては人が責任を持ちます。
ユーザは平行して作業し、変更を同じファイル、ただしそれぞれの作業コピー
彼らは平行して作業し、変更をまずは自分の作業コピーの同じファイルAに対して
言い換えると、リポジトリにあるファイルAは彼がそれをコピーした後で
新しい変更点をマージするように要求します。
両方の変更を統合してしまえば、自分の作業コピーをリポジトリに書き戻す
自分の作業コピーにマージするように要求したとき、彼のAファイルの作業
コピーは、衝突の状態としてマークされます。彼は両方の変更の衝突した
部分を見ることができ、どちらを選ぶかを選択します。ソフトウェア自体が
自動的に衝突を解決することはできないのに注意してください; 人間だけが
コピー・修正・マージのモデルは少々混沌としているように
ユーザは平行して作業することができ、相手の修正を待つことはありません。
同じファイルに対して変更するときでも、ほとんどの変更は、まったく重ならない
システムで失われる時間よりもずっと短いのです。
コミュニケーションです。ユーザがお互いにあまり意見のやり取りをしなければ、
両方の構文上の、また意味の上の衝突は増えます。どんなシステムも
ユーザに完全な意思の疎通を強制することはできないので、意味上の衝突を
検出することはできません。そういうわけで、ロックするシステムが衝突を
回避することができるという間違った保証に安心する理由はありません。
実際には、ロックは生産性を落とす以外のなにものでもないように見えます。
ロック・修正・ロック解除のモデルは一般的には複数で協力して作業する場合には
有害だと考えられていますが、場合によってはロックが有効なこともあります。
コピー・修正・マージモデルはファイルが文脈を考慮した上でマージ可能である
行単位のテキストファイルである場合を想定しています(プログラムのソース
音声などの場合、衝突した部分の変更点をマージすることは不可能なのが
厳密に自分の順番を確保したいということです。順序性を保った形でのアクセス
がなければ、最終的には捨ててしまうことになるある人の修正によって時間が
両者とも場合によってはファイルにロックする必要があることを認め
プログラムが作業コピーを作ったり使ったりする様子を見てみます。
ディレクトリツリーで、その中には複数のファイルがあります。あなたは
望むファイルを編集することができ、ソースコードファイルなら、それを
普通にコンパイルすることができます。作業コピーは自分だけの作業領域
そうしてくれと言うまで、自分の変更を他の人に見せたりすることも
ありません。同じプロジェクト用に一人で複数の作業コピーを持つことさえできます。
作業コピーのファイルに変更を加え、それがうまく動作することを
書き込むことで)用意します。もし他の人が自分自身の変更を公開したとき
という名前の、管理ディレクトリとして知られる
サブディレクトリがあります。管理ディレクトリのそれぞれのファイルは
他の人の作業によって最新でなくなっているか理解するのを助けるものです。
リポジトリのファイルシステムツリー中のサブディレクトリになっています。
この構成によって、ユーザの作業コピーは普通、リポジトリの特定の
あるとします。それぞれのプロジェクトはそれぞれの最上位サブディレクトリ
作業コピーを持ってくるため、リポジトリ中のどれかのサブツリーを
するような響きがありますがそうではありません; それは単に自分のための
感じで作業コピーを手に入れることができます:
ファイルを追加したことを示しています。これでリポジトリにある
持ってくることができました。最初に言ったように、この取得時に
ワークプロトコルを通じてかも知れません。しかしどのような場合でも、リポ
そうしてくれと言われるまでその変更を公にはしません。
自分の変更を公開する操作のことを変更点のコミット
の作業コピーを作るのにチェックアウトすれば、最新バージョン中に
あなたの変更点を見ることになるでしょう。
自分の作業コピーを更新するように依頼しなくては
これはあなたの変更を彼女の作業コピーにマージしますし、彼女がチェック
アウトしたあとで他の人がコミットしたすべての部分についてもマージします。
リポジトリの情報を使って、どのファイルを更新しなくてはならないか
として任意の数のファイル、ディレクトリに対する変更点を公開する
ディレクトリをコピーしたあと、それらの変更点の全体を完全なひと
かたまりのものとしてコミットすることができます。
リポジトリでは、それぞれのコミットは、一つの分割できないひと
かたまりのトランザクションとして扱います。すべてのコミットに
リポジトリがコミットを受け付けるときは常に
ツリーの新しい状態を作ります。それぞれのリビジョンには
一意な自然数が割り当てられます。前のバージョンよりも
後のバージョンのほうが数が大きくなります。
リポジトリ新規作成時の最初のバージョンはゼロで、ルートディレクトリ
状況を想像してください。それぞれのリビジョン番号には対応した
ファイルシステム木があり、それぞれの木はコミット
個々のファイルに付けられるものではありません。それぞれのリビジョン番号は
木全体を指定し、あるコミットによる変更後のリポジトリの特定の状態を示す
後のリポジトリファイルシステムの状態をあらわしていると考えることです。
作業コピーは常にリポジトリのどれか一つのリビジョン対応しているとは
限らないことに注意してください。複数の異なるリビジョンのファイル
リポジトリから作業コピーをチェックアウトしたとします:
その変更をコミットしたとします。他にコミットした人がいない場合、
今回のコミットはリポジトリのバージョンを5にあげ、作業コピーの内容は
コマンドであなたの作業コピーを更新すると、次のようになるでしょう:
それが最新であることを表現します。それで自分の作業コピーに
きれいなアップデートをかけたときには、一般に作業コピーは
リポジトリのある特定のバージョンと完全に一致します。
作業コピーはどのようにリポジトリを追いかけるか
あなたの作業ファイルは、どのリビジョンに基づいているか
リポジトリとの対話によって作業コピーが最後に更新された時刻
それぞれが、以下の四つの状態のどれにあるかを見分けることができます:
作業コピーのファイルは変更されていないし、その作業リビジョン
以降に起きたリポジトリに対するコミットでもそのファイルに対する変更が
作業コピー中のファイルは変更されましたが、そのベースリビジョン以降の
リポジトリへのコミットで、そのファイルに対する変更が何もなかった
場合。作業コピーにはまだリポジトリにコミットしていない変更がある
ファイルは作業コピー中では変更されていませんが、リポジトリには
変更がありました。このファイルは、公開リビジョンによって最新とするために
あなたの作業コピーに最新の修正点をマージします。
エラーになります。そのファイルはまず更新しなくてはなりません。
を作業コピーの変更にマージしようとします。これが自動的にできないような
これにはいろいろな情報の変化を追う必要があるように思いますが、
どのファイルの状態も表示できます。このコマンドについてのより詳しい情報は
この特別な例として、作業コピーに、いろいろな異なる作業リビジョン番号を
もったファイルとディレクトリを共存させることが
できます。前の例での混合リビジョンに戸惑っている人のために、
なぜこのような機能が必要で、どのように利用したらよいかを以下に示します。
送信する用意ができているということが、他の人たちの変更点を受け取る用意が
できていることを意味していることはないという、当たり前の理由によります。
は自分自身の作業コピー中にリポジトリの内容をうまく反映してくれるはずで、
この規則はまた副次的に、作業コピーには混合リビジョンの状態を記録する
ための特殊な仕組みが必要になり、またその状態に対して寛容でなければならない
ことを意味しています。これはディレクトリ自身もバージョン管理できる
ができたとします。このコミットが成功した直後では、多くの不慣れなユーザは
起こったかも知れないのです。クライアント側ではリポジトリに起きたこの変更については
が独立した処理であるという基本的な原則を侵すことになります。
常に、あなたの作業コピーはあるいくつかのリビジョンの
混合状態となります。コミット対象となったファイルだけは、それ以外のファイル
よりも新しい作業リビジョンになります。何度かのコミットの後で(
混合状態になります。あなたがリポジトリを利用している唯一のユーザであったと
してもやはりこの現象に出会うでしょう。作業リビジョンの混合状況を見る
不慣れなユーザは自分の作業コピーが混合リビジョンになっていることには
まったく気づかないことがよくあります。多くのクライアントコマンドは
処理対象となるアイテムの作業コピー上でのリビジョンが問題になるので
ファイルあるいはディレクトリの変更履歴を表示するために利用されます
を作業コピー上野オブジェクトに対して実行するとき、そのオブジェクト
の完全な履歴を見れるものだと考えるでしょう。しかしそのオブジェクトの
作業コピー上のりビジョンが非常に古いものであった場合(これは
プロジェクトが非常に複雑になった場合、作業コピー中の一部のファイル
たぶん、あるサブディレクトリにあるサブモジュールの以前のバージョンを
テストしたいか、特定のファイルに存在するバグが最初に紛れ込んだ
リビジョンを知りたいとかいった場合でしょう。これはバージョン管理
つまり、作業コピーの任意の部分を履歴の中のより新しい状態や古い状態に
作業コピー中を混合リビジョン状態に置くことはできますが、
まず、完全に最新状態ではないファイルやディレクトリの削除を
コミットすることができません。より新しいバージョンのアイテムが
リポジトリに存在する場合、この試みは拒否されます。まだあなたが
見ていない変更点を間違って消してしまうことを防ぐためです。
次に、完全に最新状態ではないディレクトリに対するメタデータの変更
エントリと属性の組を定義し、最新のディレクトリへの属性の
変更点のコミットは、やはりまだ見ていない変更点を間違って消して
中心となるリポジトリ、クライアント作業コピー、リポジトリリビジョンツリーの
良い考え方が身に着いたはずです。この知識をもとに、次の章に進むことが
すべてをやることができるようになっているでしょう。
ソースコードの最初のチェックアウトから始まって、修正し、その修正内容を
調べます。他の人の修正をどうやって自分の作業コピーにマージし、それが
どのようなものかを調べ、起きるかも知れない衝突をどのように扱えば
サブコマンドの振る舞いを見ることができます。
実行するコマンドかも知れませんが、それほどしばしば利用するものでは
話を進める前に、リポジトリ中の特定のリビジョンを特定する方法について少し
見たように、リビジョンは、リポジトリのある特定の時点における
コミットを繰り返してリポジトリが大きくなるにつれ、スナップショットを特定する
二つのリビジョンをコロンで区切って範囲指定することもできます
コミットのたびにリビジョン番号は一つずつ大きくなります。
コピーをこの管理領域中に保存しています。このコピーは修正されることは
といいます)に存在しているファイルで、作業コピーを更新したときのファイルその
リポジトリに存在している元のファイルの厳密なコピーです。
コマンド実行時のリビジョンキーワードの例です。
コマンドの意味はわからなくても大丈夫です。章を進めるごとに
# 最後のリポジトリへのコミットで付けたログメッセージを表示
これらのキーワードを使って特定のリビジョン番号や作業コピーの正確な
リビジョン番号やリビジョンキーワードを指定できるところではどこでも、
の中に日付を入れて指定することもできます。
日付とリビジョン番号の両方を使ってリポジトリ中の変更範囲にアクセスする
空白を含むような日付は常に引用符でくくるのを忘れないでください。
一番近いリビジョンを見つけようとします:
リビジョンとして一つの日付を選択し、時刻までは指定しなかった
を見つけようとすることに注意してください。
既に指摘したように、日付とリビジョン番号を混在させることもできます:
してください。リビジョンのタイムスタンプはリビジョン属性として保存
を完全に偽造する形で変更可能ですし、削除してしまうことすら可能です。
あなたのマシンにはリポジトリの作業コピーができます。
できる限り制約を置かないように動作します。ファイルの内容と
属性値はバイナリデータとして保存されたり転送され、
ファイルにはゴミが残ってしまうでしょう。
こう聞くと何かたくさんのことを覚えておく必要があるかの
ようですが、実際にはこのような制約が問題となることはほとんどありません。
リポジトリ中のディレクトリ配置について、もっとも便利な決まりを見つけて
います。そのような規約は、上で説明したような構文的に厳密な要求ではありませんが
通常のよくおこなう処理を楽にしてくれるものです。
そのような規約のひとつです: これについては関連情報とともに
サブディレクトリも簡単にチェックアウトできます:
に対して変更する準備ができています。作業コピーはあなたのシステムに
ある他のファイルやディレクトリのようなものです。編集したり変更を
加えたり移動することもできますし、作業コピー全体を削除してから、その
注意作業コピーは「システム中のほかのファイルやディレクトリ
の集まり」となんら変わることはありませんが、作業コピー中のファイル
なくてはなりません。もし作業コピー中のファイル、ディレクトリをコピーまたは
移動したい場合には、オペレーティングシステムで用意されているコピーや
を使ってください。この章の後のほうでこれについてもっと詳しく
新しいファイルやディレクトリを作ったり、既に存在するものを
普通のディレクトリ一覧表示コマンドはこのディレクトリを表示しませんが、
にもかかわらずこれは非常に重要なディレクトリです。
どんなことをするときでも、管理領域を消したり変更したりしないでください!
この章では一番よく起こることを説明します。
チームを作って作業してるプロジェクトでは、自分の作業コピーを
更新してプロジェクトの他のメンバーが自分の
更新処理後に加えた変更点をすべて受け取りたくなるでしょう。
リポジトリの最新バージョンにあわせてください。
サーバが変更点を作業コピーに送るとき、文字コードがそれぞれのファイル
の横に表示されて、あなたの作業コピーを最新にするために、どのような
新しいファイルまたはディレクトリが追加されました。両方は同じ名前ですが、
リポジトリはそれらを別の履歴を持った別のものであるとみなします。
リポジトリから受け取りましたが、そのファイルのローカルコピーにも
修正が加えられていました。しかし両方の修正は重なっていないか、あるいは
はリポジトリの変更を、問題を起こすことなしにマージ
以下のような、比較的特殊な変更をすることもできます。新しい機能
管理下にあるファイルを単に編集するだけなら、コミットするまでに
そのようなコマンドを使う必要はありません:
これは一番単純なタイプの変更です。ファイルを変更することについて
依頼することができます。このような変更は作業コピー上では直ちに
起こりますが、次にあなたがコミットするまでリポジトリ上では
グラフィックプログラム、その他の通常利用しているツールなら
通常ファイル、ディレクトリ、シンボリックリンクのどれかである
通常ファイル、ディレクトリ、シンボリックリンクのどれかである
はそれを削除予告の状態に設定します。変更をコミットすると
作業コピーなしでリポジトリを変更すること
以前この章で、変更をリポジトリに反映させるためにはどんな変更も
コミットする必要があるといいました。これは完全に正しいとはいえません
コマンドは、作業コピーを、リポジトリにコミットする前に変更点を
上で述べたアクションはどれも直接のコミットを引き起こすことになります。
変更が完了したら、リポジトリにコミットする必要がありますが、普通
そうする前に、正確には自分が何を変更したのかを見ておくのは良い考え
です。コミットの前に変更点を確認することで、より正確なログメッセージ
を付けることができます。また、不十分な修正をしただけであることを
発見するかも知れませんし、コミットする前にその変更を破棄したりする
機会にもなります。さらに、公開する前に変更点を再検討したり詳しく調査
見ることができます。最初の二つのコマンドで、作業コピー中のどのファイル
変更されたかをすばやく知ることができますし、リポジトリと通信すること
作業コピーにどのような変更を行ったかを確認するために、多分、
アクセスしませんし、他の人の行った変更が取り込まれる可能性もありません。
作業コピーに反映すること、です。ローカルコピーに対して行った変更を
を実行すると、自分がツリーにしたすべての修正が検出できます。
ファイルまたはディレクトリ名称がそのあとに続いています。
通常ファイル、ディレクトリ、シンボリックリンクのいずれかである
は衝突の状態にあります。つまり、自分の作業コピーにあるローカルな変更が
更新時にサーバから受け取った変更部分と重なっています。リポジトリに
自分の変更点をコミットする前にこの衝突を解決しなくてはなりません。
通常ファイル、ディレクトリ、シンボリックリンクのいずれかである
リポジトリからの削除予告をされています。
通常ファイル、ディレクトリ、シンボリックリンクのいずれかである
設定することで疑問符の表示を抑制できます。
通常ファイル、ディレクトリ、シンボリックリンクのいずれかである
バージョン管理下にありますが、それは失われているか、何か不完全な
チェックアウトか、更新が中断された場合、不完全な状態になることが
ファイルまたはディレクトリをもう一度取り出すことができます。
通常ファイル、ディレクトリ、シンボリックリンクのいずれかである
あるタイプのオブジェクトとして存在しますが、作業コピーには別の
タイプのオブジェクトとして存在しています。
使わずに、作業コピー中の対応するファイルを削除し、同じ名前の
無視します。無視されるファイルについてのより詳しい情報は
オプションを渡したときにだけ表示されることに注意してください。
二番目のコラムはファイルまたはディレクトリの属性を示しています
属性は修正されたことを示しています。そうでなければ空白が
多分ログメッセージを変更している最中かも知れません。
表示され、あとの場合はファイルまたはディレクトリは
追加または修正され、それが履歴に追加予告されていることを意味します。
そのアイテムは履歴付きの追加予告されていることを意味します。
それはファイルか、コピーされたディレクトリのルートであるかです。
そのアイテムのどれかの親がコピーされ、コミットを待っています。
に追加予告されたサブツリーの一部であり、
その意味はこのファイルはコピーによって自動的に存在するということ
なります。これはファイルかディレクトリは作業コピーの残り
六番目のコラムはロックに関する情報を示しています。
とりますが、その場合作業コピー中のすべてのアイテム
に対して、たとえ変更がなくてもステータスを表示するという意味になります:
の出力です。再処理コラムは同じですが、二番目はアイテムの作業リビジョン
になります。三番目と四番目はそれぞれアイテムが最後に変更されたリビジョン
いずれもリポジトリと通信をしません。それは単に作業コピー中の
スイッチがありますが、これはリポジトリと通信して、古くなった
なしに実行することで、自分がどんな変更をしたかを
中のファイルを比較した結果を出力します。
追加予告ファイルはすべて追加されたテキストとして表示され
削除予告されているファイルはすべて削除されたファイルとして表示
たとえば、パッチファイルを別の開発者に送り、コミット前に再検討や
に対する修正が間違っていることがわかったとしましょう: 多分
エディタで間違ったファイルに保存してしまったりしたのでしょう。
最終的に新しいファイルを追加することをやめることができます:
を元に戻すにあたってリポジトリと通信する必要がないのです。あるいは間違ってバージョン管理からファイルを消して
ビーチでハックするときのようにネットワークに接続されていない場所
でも修正作業を簡単に続けることができます。
領域に修正元のリビジョンファイルのプライベートキャッシュを
せずにファイルに関する報告や修正の取り消しをやる
また、ローカル修正をサーバにコミットする際に、修正元バージョン
だけを送れるようにします。このキャッシュを
接続環境にしたとしても、ファイル全体を転送するよりも修正点だけを
送るほうがずっと早いでしょう。ちっょと考えるとそんな重要なこと
コミットしようとして、ファイル全体をサーバに転送しなくては
ことはありません。この二つはリポジトリからの変更を
ローカルでは何の変更もありませんでしたが、リポジトリからの
リポジトリからの変更部分とまったく重ならなかったことを意味
あらわしています。これはサーバからの変更場所があなた自身の
ものと重なっていることを意味していて、あなたは手で
衝突が起こると、普通はその衝突を知らせて解決することができるように
そのファイルがマージ可能なタイプのときには
(行番号に基づいた文脈マージ可能なファイルかどうかは
これは作業コピーを更新する前に作業コピー中にあったファイル
がこのファイルがマージ可能なものではないとみなした場合には
の内容です。つまり、そのファイルは最後にした編集の直前にした
もし衝突があった場合は、三つのうちのどれかを
手で衝突をマージするのは最初とても嫌なものですが、
少し練習すればバイクから降りるのと同じくらい簡単に
例をあげます。コミュニケーション不足により、あなたとあなたの同僚
が作業コピーを更新しようとすると、衝突を受け取ります。それで
大なり記号の文字列を衝突マーカと呼びますが、これは実際の
衝突を起こしたデータの一部ではありません。一般的には次のコミットの
前に取り除く必要があります。最初の二つのマーカの間のテキストは衝突領域に
二番目と三番目の衝突マーカの間のテキストは、
受け取ったときにびっくりしますし、それは彼女が望んでいる
ひとたびコミットする変更内容について合意がとれたら、
ファイルを編集し衝突マーカを削除します。
自分の変更をコミットする用意ができました:
作業コピーにある三つの一時ファイルを見てどうするかを考えることができます
す。この三つのファイルを確認するためにサードパーティー製の対話的な
作業ファイルの上にファイルをコピーすること
一時ファイルのどれかを単に作業コピー上に上書きすることができます:
衝突が起こり、調査の結果、自分の変更を捨てて編集をやり直す場合は
実行する必要はないことに注意してください。
これで自分の変更をコミットする用意ができました。
どのような場合でも十分注意して、ファイル中の衝突を
すべてマージしました。これで自分の変更をリポジトリにコミット
すべてをリポジトリに送ります。変更をコミットするときには
与えてやる必要があります。ログメッセージは自分が作った
新しいリビジョンに付けられます。ログメッセージが簡単な
オプションを使ってコマンドライン上で指定することができます:
そのファイルの内容を使うように指示できます:
ティップもしコミットメッセージをエディタを起動して書いて
いて、そのコミットを中止したいと思った場合には、単に保存せずに
そのエディタを抜けてください。既にコミットメッセージを保存して
しまった場合であれば、テキストを削除してもう一度保存してください。
リポジトリは、変更点の内容に意味があるかどうかはまったく
他の人が修正していないことだけを確認します。もし他の人がそのような
したファイルのどれかが最新ではないというメッセージを出して失敗します:
その結果のマージや衝突を解消し、もう一度コミットしてください。
機能がありますが、この章でいままで説明してきたコマンドだけを使っても、
以前指摘したように、リポジトリはタイムマシンのようなところが
ファイルやディレクトリ、それに付随したメタデータの以前のバージョン
コマンドを使って、過去の任意の日付やリビジョン番号時のリポジトリ
の状態をチェックアウト(あるいは既にある作業コピーの復元)すること
単に過去がどうだったかをちょっと覗いてみたい
リポジトリからの履歴データをあつかうためのコマンドがいくつか
ログメッセージとそれぞれのリビジョンでどのパスが変更されたかを表示します。
時間とともにあるファイルがどのように変更されてきたかを
これは特定のリビジョン番号時点でのファイルを抽出し
任意の指定したリビジョンのファイルやディレクトリを一覧
ファイルやディレクトリの履歴に関する情報を見たいときは
誰が変更したかの記録を表示し、どのリビジョンでそれが変更され
コミットに付随したログメッセージを表示します。
時間と逆の順序で表示されることに注意して
ください。別の順序であるリビジョン範囲を見たい場合や、一つの
一つのファイルやディレクトリのログ履歴を見ることもできます。
もしファイルやディレクトリについてもっと詳細な
移動やコピーもできるので、ファイルシステム中のパスの
変更したファイルの名前だけを表示します。
一見エラーのように見えますが、リビジョンがリポジトリ全体に対する
デフォルトの対象として現在の作業ディレクトリを使います。結果として
自分の作業コピーのサブディレクトリで実行し、そのディレクトリにもその
子供のディレクトリ中でも変更がなかったリビジョンに対してのログを見ようと
リポジトリにコミットする前に作業コピーにされたローカル
ローカルの変更内容の確認作業コピーとリポジトリの比較リポジトリとリポジトリの比較ローカルの変更内容の確認
指定すると、作業コピーはリポジトリの特定のリビジョンと比較
してリビジョン番号を二つ、コロンで区切って指定すると
作業コピーとリポジトリのファイルを比較するためにだけ
を用意しなくてもリポジトリ中のアイテムの間の差を調べることができます。
これは、ローカルマシンに作業コピーがないときに、ファイルの変更点を
もし、以前のバージョンのファイルを見たいが、二つのファイル間の違い
もしかすると、どうして古いリビジョンに戻すためのファイルの更新に
意味を持たないようなファイルなのかも知れません)
プログラムによって二つのリビジョンのファイル間の差分を見たいかも知れません。
この場合、古いバージョンのコピーを取得する必要があり、その内容をファイル
しばしば、他のリビジョンとの間の差分をとるよりも、その古いバージョン
のファイル全体を見るほうが簡単なことがあります。
実際にファイルをダウンロードすることなしに、リポジトリ
にどんなディレクトリがあるかを表示します:
それぞれの項目の意味は、左から順に、ファイルまたはディレクトリが最後に
いままで述べてきたすべてのコマンドに加えて
この章でいままで述べてきたほど利用されるわけではありませんが、
以下のコマンドがときどき必要になります。
に書きます。次に実際に変更を適用するためにログファイルの中の
プログラムの構成という意味では、これはジャーナル化ファイルシステムと
以前に開始された操作を完結することができ、作業コピーを正常で
されていると言われたときには、このコマンドを実行してください。
をリポジトリにコピーし、必要に応じて直ちにディレクトリを作るための簡単
インポートが終わった後で、もとのツリーが作業コピーに変換さ
説明しました。触れなかったもののうちで重要なのはブランチと
前のリビジョンを指定してチェックアウトすれば(あるいは作業コピーを
第4章ブランチとマージ目次ブランチとは?ブランチの利用ブランチの作成自分用のブランチでの作業ブランチの背後にある鍵となる考え方ブランチをまたいで変更をコピーすること特定の変更点のコピーマージの基本的な考え方マージの一番うまいやり方手でマージする方法マージ内容の確認マージの衝突系統(Ancestry)を考慮することと無視すること典型的な利用方法ブランチ全体を別の場所にマージすること変更の取り消し削除されたアイテムの復活ブランチの作り方リリースブランチ(特定機能の)開発用ブランチ作業コピーの切り替えタグ簡単なタグの作成複雑なタグの作成ブランチの管理リポジトリのレイアウトデータの寿命まとめ
ブランチ、タグ、マージはほとんどすべてのバージョン管理システムで
共通の概念です。もしあまりなじみがないのであれば、この章は良い
とっかかりになるでしょう。既に詳しいのであれば、これらの概念
データをマージするときには、この機能はときどき必要となる機能です。
あなたの仕事が、何かのハンドブックを扱う企業の一部署で、ドキュメントの
管理をすることだとします。ある日別の部署から同じハンドブックが必要
答えはあたりまえです: ドキュメントのコピーを作って二つのコピーを
別々に管理することにします。それぞれの部署が小さな変更を依頼して
両方のコピーに同じ修正を加えたいこともよくあります。たとえば
最初のコピーにスペルミスがあったとします。もう一方のコピーにも
おそらく同じ間違いがあるでしょう。両方のドキュメントはほとんど同じ
手助けするコマンドがあります。データをコピーしてブランチを作ったり、
どのように二つのコピーが関係しているかを記憶しておくことができます。
片方のブランチに対する修正をもう一方にも追加する作業を助けることも
できます。最後に、作業コピーの一部だけ別のブランチにすることもできる
これまでのところで、それぞれのコミットがどうやってリポジトリに完全に新しい
まだ知らないのであれば、戻ってリビジョンに関するリビジョンの項を
二つのプロジェクトのあるリポジトリを共有していたことを思い出して
プロジェクトの作業コピーを持っているとします。特に両者はそれぞれ
あなたはプロジェクトの大胆な再編成を任されたとします。
それには長い時間が必要で、プロジェクトの全ファイルに影響
ということにあります。彼女はまだあちこちにある小さなバグを
潰している最中だからです。彼女はプロジェクトの最終バージョンが
一つのやり方として、閉じこもってしまう方法があります:あなたと
作業コピー中の全ファイルに対する大手術を始めるのですが、
しかしこれにはいろいろな問題があります。まず安全ではありません。
リポジトリに対してこまめに自分の作業を保存するのを好みます。
自分の変更を手であちこちにコピーしなくてはならないか、
一つのマシン上に作業全体をフルコピーするかになります。
同じようにして他の誰との間でも自分の進行中の変更部分を共有する
はあなたの作業の進行状況を他の人からも参照できるようにすることです。
もしあなたの中間的なコミットを誰も見ることができないとすると
あなたは他の人からフィードバックしてもらうことができなくなって
最終的に自分の変更作業が完了したとき、その変更を
他のメンバー)はリポジトリに対してたくさんの別の変更を加えており、
もっとましなやり方はリポジトリに自分用のブランチ、あるいは
自分用の作業の別ラインを作ることです。これは他の人に干渉
せずに、自分の中途半端な作業をときどき保存できるように
しますが、それでも同僚との間で、一部の情報については共有する
ことができます。どうやったらこんなことができるかは後で説明
コマンドでリポジトリ中のプロジェクトをコピーするだけです。
ディレクトリのコピーがほしいでしょう。新しいコピーはどこに置けば
説明して、概念をはっきりさせます。最初にプロジェクトのルートディレクトリ
確認できますが、これで新しいディレクトリはリポジトリへの追加として
作業コピーデータの全体を再送信するのではなく、
さて、ブランチを作るもっと簡単な方法は、先に説明すべきでした
この二つの方法には何の違いもありません。
大きなコピーをチェックアウトしなくていいからです。
をコピーするとき、リポジトリが不要に大きくなるかと心配する
ツリーを指し示すような新しいディレクトリを作ります。
つまりコピーされたディレクトリ中の一つのファイルの変更を
ファイルは、依然として最初のディレクトリのもともとのファイル
もちろん、このようなデータのコピーと共有の内部的な仕組みは
ユーザからは見えず、単にツリーのコピーが見えるだけです。ここ
での要点はコピー処理は時間的に空間的にも軽いということです。
これでプロジェクトにブランチを作ることができたので
それを使った新しい作業コピーをチェックアウトできます:
この作業コピーについては何も特別なことはありません。単に
別のディレクトリにあるリポジトリのコピーだというだけです。
一週間が経過する間に、以下のコミットが起こったとしましょう:
時間を逆向きにたどり、これにはコピーされた地点も含まれることに注意
してください。それはブランチの生成を履歴上の一つのできごととして
で同じコマンドを実行した結果を見てみましょう:
この二つのコミットはリポジトリの別の場所にある別のファイルに
で起きたブランチコピーの前は両者は同じファイルを使っていました。
ブランチはリポジトリ中の普通のファイルシステム
あるわけではありません。これらのディレクトリは単にある特別な
履歴情報も保持しているというだけのことです。
したからです。そのディレクトリを別の意味合いにとらえたり
とっては、コピーによって作成された普通のディレクトリの
たくさんの貢献者がいるようなプロジェクトでは、ほとんどの人たちは
ような長い期間をかけての変更を加える必要がある場合は常に、標準的な手続き
としてはまずプライベートなブランチを作り、すべての作業が完了するまで変更
そのようなやり方の利点としては、二人の作業はお互いに干渉しないところです。
欠点は二人の作業内容はすぐにひどく違っていって
完了するときに起こることを思い出してください。恐ろしくたくさんの衝突
でしょう。どのような変更が共有する価値があるのかはあなたが決める
そしてブランチ上での作業が完全に終ったら、ブランチ上にした変更点の
を見れば、何かのスペルミスを直したことがわかるかも知れません。
この場合間違いなく、同じファイルのあなたのコピーもやはり同じスペルミスが
あるはずです。このファイルに対する今後のあなたの修正はスペルミスのある
場所に影響を与えるかも知れず、自分のブランチをいつかマージするときに
は衝突が起こってしまいます。そうなるくらいなら、あまりひどいことになる
両方ともリポジトリ中の二つのオブジェクトを比較して、その差を
画面に表示するかわりに、それはローカルな
修正分として直接あなたの作業コピーに適用
正しく動作することを確認するのはあなたの仕事です。
結局マージが悪いアイディアだったと思ったときには、あきらめて
をかけるのが普通です。これで、変更は自分のリポジトリブランチに
マージされました。バージョン管理の言い方では、このようなブランチ間の
ローカルな修正をコミットするときには、あるブランチから別のブランチ
に対して特定の変更を移したことを示すようなログメッセージになって
限定されています。それは単にファイル内容をわずかに
変更することができるだけです。複数のファイルやディレクトリの
パッチ形式の出力をするだけで簡単には表現できないことが
働くことでツリー構造と属性の変更点を表現することができます。
とてもよく似たコンセプトを持っていますが、いろいろな場合で
パスを引数とします。つまりツリーの変更を適用する場所の指定が必要
になります。この指定がなければ、よく利用される以下の操作のどちらか
現在の作業ディレクトリ中に、ディレクトリの変更点をマージ
現在の作業ディレクトリ中にある同じ名前のファイルに対して、
ある特定のファイルに起きた修正をマージしようとしている。
ディレクトリをマージしようとしている場合で、目的のパスを指定しなかった
みなし、現在のディレクトリ中のファイルに対して適用しようとします。
同じ名前のファイル)が作業コピーディレクトリに存在している場合、
ローカルファイルに対して変更を適用しようとします。
そのことを明示的に指定する必要があります。たとえば作業コピーの親ディレクトリ
にいて、変更を受け取るための対象ディレクトリを指定する必要がある場合なら:
あげます。マージが本当のところどのように機能するかについて何か混乱
した気になるのは何もあなただけではありません。多くのユーザは(特に
バージョン管理システムになじみのない人にとっては) まず最初にコマンド
の構文に戸惑い、さらにどのようにして、またいつその機能をつかえば良い
かということにも戸惑います。しかし怖がることは何もありません。このコマンドは
がどのように動作するかを正確に知るためのとても簡単な方法があります。
データ同士が、何か神秘的な方法で混ぜ合わされてしまったりするような表現
差分がターゲットの作業コピーに対して、ローカルな修正点の形で反映されま
したのとなんら変わるところはありません。結果の修正内容が満足のいくもの
最初の構文は三つのすべての引数を明示的に指定するもので、ツリーについては
比較する場合の略記法です。最後の構文は作業コピーを省略した場合の例です;
デフォルトではカレントディレクトリが指定される決まりです。
マージの一番うまいやり方手でマージする方法
変更のマージは非常に単純なことに思えますが実際には厄介な
変更点を繰り返しマージすると、間違って同じ変更を
二度やってしまうかも知れないということです。
理想的には、バージョン管理システムはブランチに対して変更点の重複
した適用を回避すべきです。ブランチが既に受け取った変更点を自動的に
記憶し、その一覧を表示できるようにすべきです。そしてバージョン管理システム
は自動マージを支援するために可能な限りこの情報を利用すべきです。
を実行したものによるのか、あるいは単に手でファイルを修正した
機能がいつか実装されるまではマージの情報を自分で記録しておく必要が
あるということです。一番良い場所はコミットログメッセージ中でしょう。
以前の例で説明したように、あなたのブランチにマージした特定のリビジョン
番号(あるいはリビジョン番号の範囲)をログメッセージ中で示しておくこと
ブランチがどの変更点を既に含んでいるかを知ることができます。これで
取り込んだ変更点を再び取り込むことがないように注意することが
次の節ではこの技法の例を実際にお見せします。
マージは作業コピーを変更するだけなので、それほど危険な操作では
しかし作業コピーには既にローカルな修正が加えられていることもあります。
マージによって適用された修正は既に加えていた修正と混じってしまう
この二つの修正の組を分離することは不可能です。
このような場合には、実際にマージする前に、マージしたとしたらどうなるか
を実行する方法があります。それは既にマージの最初の例で見たものです。
修正を適用しません。実際のマージで表示されるであろう
な内容が表示されてしまうような場合に、潜在的なマージの概要を確認するための
を持っているというときに期待するものは異なっています。ここでは
チェンジセットは一意の名前がついた変更点の集まりであるとしておきましょう。
この変更はファイル内容の編集、ツリー構造の変形、メタデータの修正などが
含まれています。もっと普通の言い方をすると、チェンジセットとは参照できる
すればコミットされたパッチを正確に求めることができます。この理由により、
チェンジセットとみなすこともできます。バグを管理するバグ追跡システム
を使っているなら、バグを修正した特定のパッチに言及するのにリビジョン
ブランチに特定のチェンジセットをマージしたい場合にはマージの引数で
まず、作業コピーにはローカルな修正が加えられていないとします。
サーバから送られてきた変更点は作業コピーに対して常に「きれいに
いるリビジョンとの間の差分です。前者は作業コピーと全く同じものなので
この差分が作業コピーをきれいに後者に変換することは保証されています。
結果はもっと混沌としたものになる可能性もあります: ユーザは全く
任意の二つのツリーの比較をするようサーバに
これは人間の側の操作ミスが起こる潜在的な可能性が大きいことを
意味します。場合によってはユーザは間違った二つのツリーを比較し、
きれいに適用できないような差分を作ってしまうかも知れません。
」について文句を言ってくることがあるのと同じように
この例では比較対象となる二つのブランチのスナップショットの両方に
ファイルの内容を変更しようとしますが、作業コピー中には対応するファイル
が存在しなかったような場合だと考えられます。いずれにせよ
比較してしまったことを意味することがほとんどです。ユーザ側のエラー
点を再帰的に元に戻し、バージョン化されていないファイルやディレクトリ
してください。今回の場合作業コピーに対してローカルな修正がされていない
作業コピーに適用することができるので、ローカルな修正がなかったと
しても、その差分が作業コピーに対してきれいに適用できないような変更を
小さな違いとしては衝突がおきたときにできるテキストファイルの名前です。
ファイルが比較した二つのツリーのどちら側に由来するものかを示しています。
は系統を無視しますが、後者は系統を非常に慎重に考慮します。例えば
るとそれらが無関係であることを検知し古いファイルをいったん削除し、それ
から新しいファイルを追加しようとするでしょう; 出力は追加のあとに削除した
ほとんどのマージはお互いに系統上関係したツリーを比較する
たとえばあるソフトウェアプロジェクトの、異なる
あなたが出くわしそうな一番よくあるパターンについて説明します。
起こったとましす。そしてあなたはプライベートなブランチ上での作業を
人がその部分を使えるようにするために、あなたのブランチ上の変更点の
作業コピーに適用するものであったことを思い出してください。変更点
最後のトランクとブランチのツリーの比較は単にあなたが自分の
ツリーに対して行った変更点のみを示すものではない
それは、あなたのブランチに対する追加点だけを表示するのではなく、
あなたのブランチ上に起きた変更のみをあらわすには、あなたのブランチの
トランクの作業コピーに適用したいと考えていることを意味します。
ティップブランチが作成されたリビジョンを見つけるうまい方法は
し、それはブランチが作成されたコピーよりも前にさかのぼります。このた
め通常トランクの履歴も表示されてしまいます。
るいは名称変更の個所を見つけると直ちにログの出力を中止します。それで現在の例で言うと、
期待したとおり、このコマンドによって表示される最後のリビ
ここでもトランクにマージされた変更範囲についてコミットログメッセージは
非常に具体的に触れていることに注意してください。このことを常に憶えて
おいてください。後になって必要になる非常に重要な情報だからです。
たとえば、独自の機能拡張やバグフィックスなどのために、もう一週間自分の
ブランチ上で作業を続けることにしたとしましょう。リポジトリの
トランクに対するマージの用意ができています。しかしマージの一番うまいやり方の項で議論したように既に以前マージした
変更を再びマージしたくはありません; 最後にマージしてからブランチ上に
実行し最後にブランチからマージしたときのログメッセージを見ます:
これでトランクはブランチに起きた変更の第二波全体を含むことになりました。
ブランチ上で引き続き作業し、以降のマージについて上記の手続きを繰り返す
は完全に間違いであったことを発見したとしましょう。それはコミットすべき
コミットすることができます。やらなくてはならないことは反対向きの
リポジトリリビジョンについてのもう一つの考え方は、それを
特定の変更のあつまりと考えることです(いくつかのバージョン管理
セットを適用するか、もしくはある範囲のチェンジセット全部を作業コピーに
の操作にすぎないので、作業コピーが望む状態になったかどうかは
最終的なバージョンを送ることができるのだ、ということを押さえておいて
ください。コミット後はこの特別なチェンジセットはもはや
リポジトリの履歴に依然として残っています。ほとんどの状況では
これで十分です。とにかくほとんどの人たちはプロジェクトの
ことだけに興味があるからです。しかし、コミットに関するすべての
失われないように設計されているからです。履歴からのリビジョンの
バージョン管理システムの偉大なところは情報が決して失われないという
ところです。ファイルやディレクトリを削除した場合でもそれは
から消えただけであり、以前のリビジョン中には依然として存在し続けます。
最初のステップはあなたが復活させようとしているものは正確には何であるかをはっきりさせることです。
うまいたとえがあります: リポジトリ中のそれぞれのオブジェクトは
一種の二次元座標系の中に存在していると考えることができます。第一の軸
は特定のリビジョンツリーで第二の軸はそのツリー中のパスです。すると
ファイルあるいはディレクトリのそれぞれのバージョンは特定の座標の組で
ので復活させたいと思う正確な座標ペアを見つける
リビジョン中でのすべての変更アイテムのリストを表示します; 必要なことは
ファイルやディレクトリをどのリビジョンで削除したかを調べることです。
これはビジュアルにやることもできますし、ログ出力を解析する別のツールを
エディタでのインクリメンタル検索機能を使う形かも知れません)。
で削除されたことを突き止めました。それでこのファイルが存在していた
最後のバージョンはそのリビジョンの直前であることになります。結論:
これで復元したいものが何であるか突き止めました。後は二つの方法が
をもう一度追加する効果があります。ファイルは追加予告され、コミット後には
することもできますが、この技法はファイルが多くなるとうまくスケールしません。
ステータス表示中のプラス記号はそのアイテムは単に追加予告されただけではなく
以前のすべての履歴をたどることができます。言いかえるとこの新しい
削除されたもとのファイルの直接の子孫になっています。
私たちの例はファイルの復活でしたが、同じ技法が削除されたディレクトリ
の復活についても利用できることに注意してください。
バージョン管理システムはソフトウェア開発で一番よく使われるので、ここで
何かの開発チームによって利用される典型的なブランチ化/マージのパターン
ればこの節は読み飛ばしてもかまいません。ソフトウェア開発にバージョン
管理システムを使うのが初めてなのであれば、よく読んでください。
ここでのパターンは経験を積んだ多くの開発者によって最良の方法だと考えられて
どのようなバージョン管理システムにでも応用できる考え方です。また同時に
準的なやり方を表現するかを理解する手がかりになるでしょう。リリースブランチ
あります。まず開発者は新しい機能を追加し続けなくてはならない一方で
品質保証チームはそのソフトウェアの安定版だと考えられるバージョンを
テストするのに時間をついやさなくてはなりません。テスト途中だからといっ
て新しい機能追加を中断することはできません。次に開発チームはほとんど
の場合、すでにリリースされた古いバージョンのソフトウェアを保守しなくては
バージョンにも同じバグが潜んでいる可能性は高く、利用者は次のリリースを
待たずにこのバグを修正して欲しいと望んでいることでしょう。
バージョン管理システムの出番です。典型的なやり方は以下のようなものです:
開発者は新規開発部分をトランクにコミットします。
あるチームが、そのソフトウェアがリリースできる状態になったと考えた
あるチームがリリースブランチの内容を徹底的なテストを開始する一方で
バグが見つかれば、必要に応じてその修正がお互いの間を行き来します。
しかしこの作業もやがては終わります。このブランチはリリース直前の
ショットになります。このタグの内容はパッケージ化され、利用者に対して
このような作業の流れを繰り返すことでソフトウェアは安定していきます:
リリースブランチと最終的にリリースされたバージョンを示すタグの集まり
例として中心的な役割を果たしてきたようなタイプのブランチで、その
ためのものです。リリース用ブランチ(これはずっと保守しつづけなければ
ならないかも知れません)とは違って、開発用ブランチは作成されたあと
ある程度の期間利用され、変更部分がトランクに反映された後で完全に
プロジェクトの考え方によって、開発用ブランチをいつ作るのが適切である
かにはかなりの幅があります。プロジェクトによっては開発用ブランチを
ブランチ化やマージについて理解する必要がありません。欠点はこの方法
だとトランクのソースコードが不安定になったりまったく利用できなく
なったりしやすいことです。逆に別のプロジェクトではブランチを極端な
コミットすることは認められていません。まったくささいな変更に対しても
トランクを常に非常に安定して利用できる状態に置くことができますが
それには無視できない処理効率の低下が伴います。
ほとんどのプロジェクトではこの中間のやり方をとります。普通は
一度フィックスしたバグが元に戻っていないことを保証するためのテスト
もクリアした状態にあることを要求します。ある変更をするのに
プログラムを不安定にするようなコミットを何度も必要とする場合に
だけ開発ブランチが作られます。基本的な方針としては次のようなことを
考えてみることです: もし開発者が孤立した状態で何日も作業した後で
不安定にならないようにするためにそうするのでしょうが)、その変更
内容が正しいかどうかを検討するには大きすぎませんか? もし答えが
しょう。開発者はブランチに対して変更点を少しずつコミットするので
他の人たちはそれぞれの部分について簡単に内容を検証することができ
最後に、開発用ブランチでの作業が進むにつれて、どうやってそれを
考えてみます。すでに注意したようにブランチ上で数週間あるいは数ヶ月
ものあいだ作業しつづけるのには大きなリスクが伴います; トランクへの
変更はその間次々と発生し、ついには二つの開発ラインはあまりにもかけ離れて
しまい、ブランチの変更内容をトランクにマージによって戻すのは全く
非現実的な話になってしまうかも知れないのです。
この状況を避けるためにはトランクの内容を定期的にブランチにマージする
先週トランク上におきた変更をブランチにマージすること。これは注意して
のを避ける必要があります(これについては
を書く時には注意して、どの範囲のリビジョンが既にマージされているか
を正確に控えておきましょう(これはブランチ全体を別の場所にマージすることの項
あるところまで作業が進んだら、開発用ブランチの内容をトランクに
まず、最新のトランクの変更部分をブランチに取り込む最後のマージ
処理を実行することで始めます。この処理の後では、ブランチ上の最後のリビ
ジョンとトランク上の最後のリビジョンは、ブランチでの変更部分を
のぞけば、完全に同じ状態になります。このような特定の状況下では
ブランチとトランクの内容を比較することによってマージすることが
加えた修正点を含む差分を作ることができます; 両方の開発ラインとも
トランクに起きた修正についてはすでに取り込んでいるからです。
このような作業パターンは、自分のブランチに対して
とは、一度に一つの変更しか保存できないような単なるブランチにすぎ
別のブランチに変換します。このコマンドはブランチで作業するのに
常に必要というわけではありませんが、ユーザに対して便利なショートカット
リポジトリディレクトリの作業コピーをチェックアウトしました。そうする
ブランチの場所のコピーに変更することができます:
を新しくチェックアウトした場合とまったく同じものになります。そして
普通このコマンドを使うほうがより効率的です。というのは、たいてい
ブランチはほんの少し内容が違うだけです。サーバはそのブランチディレクトリ
を反映させるために作業コピーにしなくてはならない最小限の変更だけを
言い換えると、ユーザが特定のサブディレクトリ上でだけブランチの作業が起きる
できますが、切り替えた部分だけは変更されることなく残ります(もしブランチ
に対して誰かが変更点をコミットしさえしなければ)。この機能は
「混合作業コピー」という概念にまったく新しい次元を付け加える
もし作業コピーが異なるリポジトリ位置からのスイッチされたサブツリー
それぞれのサブツリーのパッチを適切に受け取るでしょう。コミットすると
ローカル修正は一つの不可分の変更をリポジトリに適用するでしょう。
リポジトリ位置の混合を作業コピーに反映させることはできますが、
このようなリポジトリ位置はすべて同じリポジトリ
コマンドのスーパーセットになっています。
二つのツリーを比較するように要求します。リポジトリはその比較を実行
の変種なので、同じ動作を共有します。作業コピー中のどのようなローカルの
変更もリポジトリから新しいデータが届くときに保存されます。これで
あらゆる利口な小技がきくようになります。
変更を加えたとします。それから突然、本当はブランチにやる変更だったことに
それをブランチに対してテストし、コミットすることができます。
ではこのアイディアは既にさまざまな場所にあるように見えます。それぞれ
ファイルシステムのスナップショットです。
しかし、人はしばしばタグに対して人間になじみのある名前を付けたいと
のもっと小さなサブディレクトリのスナップショットがほしいこともあります。
であることを思い出すのは簡単ではありません。
ショットを作りたいときには、そのコピーをとればいいのでした:
もちろん、どのリビジョンをコピーするかについてもっと正確でありたいと
思うかも知れません。他の人があなたが見ていないときにプロジェクトに
対して変更点をコミットしていたかも知れませんから。もしあなたが
でもちょっと待ってください: このタグ作成の手続きはブランチを作る
コピーで作られた普通のディレクトリです。ちょうどブランチのように
人間がそうやって扱うことに決めたから、ただ
それだけです。そのディレクトリに誰もコミットしない限り、それは
永遠にスナップショットとして残ります。もし誰かがそれにコミット
もしリポジトリを管理しているなら、タグを管理するには二通りの
すべてのユーザにそのディレクトリをコピーするときにはどうやって扱うか
制御スクリプトのどれかを使って、タグ領域には新しいコピーを
ガチガチ方式は、普通は不要です。もしユーザが間違ってタグディレクトリ
に自分の変更をコミットしてしまったら、前の章で説明した方法で
ときどき、一つのリビジョンの一つのディレクトリよりも
もっと大きいとします。たくさんのサブディレクトリともっとたくさん
のファイルがあるとします。仕事の過程で、特定の機能とバグ修正を含んだ
作業コピーが必要になったと判断します。特定のリビジョンの
特定のブランチにファイルとディレクトリをスイッチすることによっても
リポジトリ位置のつぎはぎになります。しかしテスト後、自分がまさに必要と
している組み合わせであることがわかりました。
場所にコピーします。この場合、やりたいことは特定の作業コピー状態
これでリポジトリに新しいディレクトリができました。
別のユーザはこの機能の面白い使い方を見つけました。
ときどき、自分の作業コピーにローカルな修正をした
ブランチがあるが、それを他のメンバーに見せたいというような
を使って変更点のみを受け取ることができます。
いただけたかと思います。ディレクトリのコピーという同じ基本的な
仕組みの上にブランチもタグも実装しており、ブランチもタグも普通の
仕組みにびっくりします。それは柔軟すぎるくらい
です。この節では時間経過と共にどのようにデータを配置し管理するのが
リポジトリの編成にはある程度、標準化された、おすすめの方法が
を入れます。リポジトリがただ一つのプロジェクトを含む場合には
しばしば、この三つのディレクトリをリポジトリ最上位に作ります:
リポジトリが複数プロジェクトを含む場合は、プロジェクトごとに
どのように変化させてもかまいません。どれを選んでもそれは
永久に固定されたものではありません。いつでもリポジトリを
再編成することができます。ブランチとタグは普通のディレクトリ
好きなように移動、名称変更ができます。あるレイアウトから別の
レイアウトへの切り替えは単にサーバ側での何回かの移動の話になります。
もしリポジトリ中の編成に何か気に入らないところがあるなら、ディレクトリ
しかし、ディレクトリの移動は簡単ではありますが、ユーザのこともよく
考える必要があります。この変更は既にある各自の作業コピーの場所
を再配置します。もしユーザが特定のリポジトリのディレクトリの作業
は最新リビジョンのパスを削除してしまうかも知れません。ユーザが
すでに存在しないパスを示しているとされ、新しい場所に移動する
管理されたアイテムと同様、ブランチとタグは有限の寿命しか持たない
の個人的なブランチ上ですべての作業が完了したとします。すべての
その個人的なブランチのディレクトリがまったく不要になります:
これでブランチはなくなってしまいました。もちろん本当に削除された
を使えば依然として古いブランチを見ることができます。
削除したディレクトリを閲覧するだけでは不十分な場合は、いつでも
私たちの例では個人的なブランチは比較的短い生存時間を持ちます。バグを
直したり新しい機能を追加するのに利用したからです。作業が終われば、
ブランチの寿命もそこで終わりです。しかし、開発内容によっては
非常に長い時間にわたって二つの「主要な」ブランチが並行して生きつづけることも
公にリリースするときがやってきて、そのソフトのバグをとるのには
何ヶ月かかかるとします。リリースバージョンに新しい機能を追加させたくは
ありませんが、すべてのメンバーに開発を中止するように言いたくもありま
せん。そこでかわりに、あなたはそれほど大きな修正は発生しない
にコミットするようなポリシーで進めることができます。
ついては安定版ブランチ上に持っていくことができます。安定版ブランチ
が出荷されたあとでも、そのブランチを長い時間かけて保守し続ける
ことによってこれらの概念を実装していることを説明しました。
をコピーしたり、間違った変更を戻したりする方法をお見せしました。
作ってみせました。そして、どのようにしてリポジトリ内のブランチの
編成と寿命を管理するかについて話しました。
ブランチやタグを作る処理はとても軽いのです。好きなだけ使ってください!
同じリポジトリ内でのみコピーすることができます。
実装する計画があります。これは情報の完全な消去を実行するコマンド
されたデータを格納する中心的な場所です。こんなわけで、リポジトリは
管理する人間にとってはたまらない魅力のある場所になるかも知れません。
リポジトリは一般的にはそれほど複雑な管理が必要なものではありません
ためにはどうすれば良いかを理解することは重要です。
よくある質問と間違いをとりあげ、リポジトリ中でどのようにデータを
配置するのか良いかについてアドバイスします。
リポジトリの基礎リポジトリ管理についての広範囲な話題に飛び込む前に、リポジト
リとはいったい何であるかをもう少し突っ込んで定義しておきましょう。それ
ことが期待されます。以下の節は非常に高レベルの基本的な概念のいくつか
について説明します。トランザクションとリビジョンの理解
管理されたファイルやディレクトリがどのように見えるか、という
このクライアントの操作によって作られるスナップショットを
それぞれのリビジョンはトランザクションツリーとして生まれます。
のコミット処理の最初にリポジトリに起きる附加的な変更)を反映
このツリーを格納するようにリポジトリに命令します。
コミットが成功すれば、トランザクションは新しいリビジョンツリーが
コミットが何かの理由で失敗すれば、トランザクションは消されて、クライアント
更新処理も同様に動作します。クライアントは作業コピー
の状態を反映した一時的なトランザクションツリーを作ります。リポジトリは
そのトランザクションツリーを要求されたリビジョンのツリー(普通は
リビジョンツリーの形に変形するにはどのような変更が必要であるかに
ついての情報を戻します。更新が完了した後、その一時的なトランザクションは
トランザクションツリーの利用がリポジトリのバージョン管理された
ファイルシステムに普遍的な変更を起こす唯一の方法です。しかし、
トランザクションの生存時間が完全に任意であることを理解するのは
重要です。更新の場合トランザクションはすぐに消滅する一時的なツリー
です。コミットの場合は、トランザクションは普遍的なリビジョンに
エラーやバグがあると、トランザクションはリポジトリの周辺に
取り残されてしまうかも知れません(しかしこれは領域を食うだけで、
アプリケーションはトランザクションの生存期間をもっと柔軟に
管理することができるようになるかも知れません。
クライアントがリポジトリに対する修正内容の記述を終えたあとでも、
リビジョンになる候補のトランザクションが
静止した状態にとどまるようなシステムを考えることもできます。
これはそれぞれの新しいコミットを別の人、たとえば管理者やエンジニアの
を本当のリビジョンにしたり、取り下げたりすることができるようになるでしょう。
付随した属性を持つことができます。そのような属性は
一般的なキー・値のマッピングで、関連したツリーについての
情報を格納するのに一般的に利用されます。属性の名前と値はリポジトリの
ファイルシステム中に、残りのツリーデータと一緒に格納されます。
リビジョンとトランザクションの属性はファイルやディレクトリ
にそれほど強く結びついていないツリーの情報を記憶して
情報です。たとえば新しいコミットトランザクションが
コミットが完了し、トランザクションが普遍的なリビジョンとなる
同様にリビジョンツリー自身は不変ですが、ツリーに付けられた
間違った情報だったり、ログメッセージにスペルミスがあったり
属性の値を正しいログメッセージで置き換えてやるだけです。
れについては後で少し触れます。どちらか一方がもう一方よりも「公式
のもの」であるということはありませんし、リポジトリへのアクセスは
これらの実装の詳細とは分離されています。プログラムはどうやって保存して
を通じて、抽象化されたリビジョンとトランザクションツリーが見えるだけで
その理由にはそのオープンソースライセンス、トランザクションのサポート、
複数のプロセスはそれぞれ他のデータを間違って破壊することを心配する必要はありません。
トランザクションシステムによって提供されている分離機能はどんな操作においても
を決めることができるのです。もしその決定が他のプロセスがやったことと衝突
した場合、操作全体は、それがまったく実行されなかったかのようにロールバック
ような状態での)データベースに対してその処理を再実行することができます。
能力です。リポジトリのバックアップ方法についてはリポジトリのバックアップの項で議論しますが、オフラインに
せずにリポジトリの完全なコピーをとることができる利点は明白でしょう。
する操作内容をいったんディスク上のログファイルに書き込み、それからその
修正を実際に行うものです。これは何かまずいことが起きた場合にデータベースシステム
状態に復元されるまでトランザクションを再実行することを保証するものです。
形式はプラットフォーム独立ですが、環境中にはそうではない部分もあります。
仕様の一部に合致するようなネットワーク共有上での正しい動作を保証していますが、
現在実際に利用されているネットワーク共有方式で、そのすべての仕様を満たすよう
ので典型的なリレーショナルデータベースよりも割り込みに関して敏感です。
バプロセスがあります。何かの理由でデータベースにアクセスするプログラム
に異常があった場合でもデータベースデーモンは接続が中断したことを検知し
て問題のある中間的な状態をきれいにします。またデータベースデーモンはテー
ブルにアクセスする唯一のプロセスなのでアプリケーションはパーミッション
はデータベーステーブルに直接アクセスしますが、これはプログラムで異常が
あると、データベースが中間的な矛盾のある状態、アクセスできない状態のま
ま残ってしまうことを意味します。このようなことがおこると、管理者は
なるのはプログラムの異常のほかにも、データベースファイルに対して与えら
れたオーナーやパーミッションに関係することもあります。このように、
の異なるユーザがアクセスするのは避けたほうがよいでしょう。複数ユーザか
リビジョンツリーを単一のファイルに保存し、すべてのリポジトリリビジョン
は単一のサブディレクトリの下の複数ファイルになります。トランザクション
は分離されたサブディレクトリに作られます。トランザクションが完了すると
単一のトランザクションファイルが作られ、それがリビジョンディレクトリに
ンファイルは永続的なものであり、それ以上変更されないのでリポジトリは
とができます。リビジョンファイルの形式は、そのリビジョンのディレクトリ構造、ファ
イル内容、そして他のリビジョンツリーのファイルに対する差分を表現したも
依存しません。ジャーナリングのしくみや共有メモリーを使っていないので、
リポジトリはネットワークファイルシステムごしに安全にアクセスすることが
でき、リードオンリーな環境を作ることもできます。またデータベース保存形式特
有のオーバーヘッドがないので、リポジトリの大きさは比較的小さくなります。
バージョンと、今回の最新バージョンのファイルの差分を書き込みます。
リビジョンに保管されている完全な内容にアクセスするよりも少し遅くなる
起こりますが、これは極端な場合には応答を待つ
クライアントプログラムをタイムアウトさせてしまうかも知れません。
データベースを使ったプロセスがパーミッションの問題や突然異常終了したよ
うな場合だと、データベースは管理者が復帰処理をしない限り利用できない状態に
たく影響を受けません。せいぜいトランザクションデータが見えない場所に取
ドとスケール性についてここで述べた多くの内容は: 妥当な推測に基づくもの
題の影響を受けにくくするはずです。実際にどうかは、いずれ時が答えてくれ
にそれをやるサブコマンドがあります。新しいリポジトリを作るには
新しいリポジトリが作成されます。この新しいリポジトリはリビジョン0
システムディレクトリに中身が空の状態で存在しているだけです。
ネットワークファイルシステムでこの性質を持っているものはほとんどありません。
すぐに正体不明のエラーが起きるかも知れませんし、自分のデータベースがわずかに
壊れてしまったことに気づくのに何ヶ月もかかるかも知れません。もしリポジトリに対して複数のコンピュータがアクセスする必要がある
スを設定し、サーバがアクセスできるようなローカルファイルシステム上にリ
ポジトリを格納し、リポジトリがネットワークからも利用できるようにしてく
この二つはリポジトリを調べたり状態を変更するため、リポジトリがある
マシン上で利用され、ネットワーク越しに実行することはできません。
には実際には何ができたかをちょっと見てみましょう。
ファイル以外は、リポジトリディレクトリは
モジュール化に非常に配慮されています。階層化した編成は混沌とした
状態よりも望ましいものです。新しいリポジトリディレクトリについて
一つの整数値が書いてあるファイルで、この整数はリポジトリレイアウトの
フックスクリプトテンプレート全体が格納されたディレクトリです
リポジトリにアクセスしている人を記録するのに使われます。
変更にも十分対応できますし、サードパーティーのツール(たとえば
いない属性の修正といったリポジトリに対するイベントをきっかけに実行される
何を対象にして操作をしたのか、そのイベントを起こした人のユーザ名
などの情報を扱うことができます。フックの出力や戻り値によって
フックプログラムは処理を続けたり終了したり、いくつかの方法で中断したりします。
さまざまなリポジトリフックのテンプレートがあります。
テンプレートスクリプトの内容を見ればどんなトリガーを実行し、
どんなデータがそのスクリプトに渡されるかがわかります。
またこれらたくさんのテンプレートはスクリプトを書こうとする人の例
動作するフックをインストールするには、何かの実行ファイルかスクリプト
置いてやる必要があるという意味です(シェルスクリプトでもいいし、
もちろんテンプレートファイルはそういう情報を与えるためだけに
とった新しいファイルにコピーして、内容をカスタマイズし、スクリプトに
状態で実行します。このため多くの管理者は手でフックスクリプトを実行
いことに困惑します。環境変数を明示的に設定するか、実行するプログラム
を絶対パスで参照していることを確認してください。
これは、コミットトランザクションが作られる前に実行されます。
典型的にはユーザがコミット権限があるかどうかを決定するのに
使われます。リポジトリはこのプログラムに二つの引数を渡します:
リポジトリへのパスと、コミットしようとしているユーザ名です。
もしプログラムがゼロ以外の値を返した場合、コミットは
ランザクションが作られる前に中止します。フックが標準エラー出力にデータ
あなたのサイトでは、すべてのコミットはバグトラッカーの管理番号
を含むようなブランチに対してしなくてはならないとか、
ログメッセージが空であってはいけないというようなポリシーが
によってコミットを許可しないようにするために使われます。
リポジトリはこのプログラムに二つの引数を渡します:
リポジトリのパスと、コミットされるはずのトランザクションの名前
を書き込むと、それは適切なデータ形式でクライアントに戻されます。
を使うもので、個別のディレクトリに対する読みこみ書き込みのアクセス制御
これはトランザクションがコミットされ、新しいリビジョンが
作られた後に実行されます。ほとんどの人はこのフックを
リポジトリのコミットやバックアップに関する連絡メールを
送るのに使います。リポジトリはこのプログラムに二つの引数を
渡します:リポジトリのパスと、今回作られた新しいリビジョン番号
それは、今回のコミットに付けられた説明をメールするために使う
ことができます。このメールの内容は変更されたパスの一覧、コミットに
のバックエンドとしてサポートする予定です)リポジトリのアーカイブ化
や緊急リカバリのためのコミットごとのスナップショットを作るのに
を使って、必要に応じてリポジトリ管理者がこのような変更記録を残すことが
出来ます。バージョン化されていない属性データを失うことに対するあらかじめ
実装されているのではない限りリビジョン属性をリモートに変更することは
このフックはリポジトリにそのような変更が発生する直前に実行されます。
リポジトリはこのフックに四つの引数を与えます:
された直後に実行されます。典型的には、変更された属性の新しい値を
メールするのに使います。リポジトリは四つの引数をこのフックに渡します:
ディレクトリにあります)これは、リビジョン属性の変更についての詳細を
このフックは誰かがファイルをロックしようとしたときには常に実行されます。
これはロックを防ぐのにも利用するこどかできますし、誰が特定のパスに対して
ロックできるかという複雑なポリシーを正確に設定するのにも使えます。
フックが既にロックがかかっていることに気づいた場合にはユーザはそのロック
ロック処理は異常終了し、標準エラー出力へのメッセージはすべてクライアント
このロックはパスがロックされた後に実行されます。ロックされたパスはフックの
好きな方法で出来事を記録したりすることが自由にできます。ロックはすでに
実行されてしまっているのでフックの出力は無視されます。
このフックは誰かがファイルのロックを取り除こうとした時には常に
実行されます。これを使ってどのユーザがどの特定のパスに対して
ロック解除できるかを決めるポリシーを作るために利用できます。
ロック解除に関するポシリーを決めることは非常に重要です。
ことはフックによって決定され、強制することができます。リポジトリ
終了値を返した場合、ロック解除の処理は異常終了し標準エラーへの
このフックはパスがロック解除された後で実行されます。ロックが解除
されたパスはフックの標準入力に渡され、その他にも二つの引数がフック
ことができます。ロックの解除は既に起こってしまっているのでフックの
フックスクリプトによってトランザクションを修正しようとしないで
のような属性を自動的に設定してしまうことです。いっけん良いアイディア
に見えますが、問題を起こします。一番の問題はクライアントはフックスクリ
プトでされた変更について知ることができないので、クライアントに対して
最新ではなくなったことを伝える方法がないことです。この矛盾した状況
が予測できないような動作の原因になることがあります。
正しい要件を満たさない場合にはコミットを拒否するのがずっと良い
の所有者としてフックを実行しようとします。ほとんどの場合
言い換えるとフックを実行する際に、このようなファイル権限に
とか、ジャーナルログファイルの一つの大きさについて、固有のデフォルト
ときどき特定のリポジトリが特徴的なデータやアクセスパターンを
持っているために別のオプション設定値を持つのが望ましいことがあります。
何をするかについて読んでおくことができます。もちろんどのような
解釈したりすることはありませんし、その中にオプション値を設定
予測できないような影響を与える設定変更は避けてください。
もあります。大部分はデータベースバックエンドのもつシステムから引き継い
だ複雑さによります。作業をうまくこなすには、とにかくツールについて深く理解する
プ、クリーンアップのような作業でどうやって使いこなせばよいかを説明しま
リポジトリ中のいろいろなリビジョンやトランザクションを調査
するのに使われます。このプログラムのどの部分もリポジトリを
リポジトリフックによって使われます。リポジトリ管理者は診断のために
リビジョンかトランザクションツリーのどちらかに対して働き、
ツリー自身の情報か、以前のリポジトリのリビジョンとの違いを
リビジョンまたはトランザクションについて調査するかを指定する
ことができます。リビジョン番号は自然数として表示されますが、
トランザクション名称は英数字の文字列だということに注意してください。
ファイルシステムはコミットされていないトランザクションのみを表示
できることを憶えておいてください(新しいリビジョンを作れなかった
トランザクション)。ほとんどのリポジトリにはそのようなトランザクション
リビジョンをリポジトリの調査対象とします。それで、以下の二つの
マシンにも理解できるように設計されています。
この出力は人間が読むことができます。日付のタイムスタンプ
ログメッセージは複数行にわたることができ、長さの制限がないので、
表示します。これで、このコマンドのスクリプトやほかのラッパープログラムは
賢い判断ができるようになります。たとえば、メッセージにどれだけの
メモリを割り当てれば良いか、とか、イベント中で少なくとも何バイト
スキップしてもデータストリームの終わりにならないか、などを知ることが
トランザクションツリーの実際の内容を見ることです。
表示します(そのようなパスは一般的に言ってユーザよりも開発者に有用なもの
使ってそれらのファイルやディレクトリについてのより詳細な情報を
いままで説明した情報の一部を表示したり、指定したリビジョンや
トランザクションのどのパスが修正されたかを報告したり、ファイルや
ディレクトリに対するテキストや属性の相違点を表示したり、などなど
ツリーの一覧表示をします。オプションでそれぞれのパスに
このプログラムはリポジトリに対してさまざまな保守操作をします。
他のサブコマンドのほとんどをこの章の後のほうで説明します。いまは
利用可能なサブコマンドの全体を軽く見ておきます。
リビジョンで変更されたパス上で祖先の差分を計算します。リビジョンが指定
でき、他のプロセスがリポジトリを利用しているかどうかにかかわらず、安心して
リポジトリのコピーをとることができます。
もののパスを一覧表示します。そのようなログファイルはリポジトリレイアウトから
安全に削除することができますが、リポジトリの壊滅からの復旧には必要となる事態にそなえて
現時点でリポジトリに存在しているコミットされていない
必要に応じてリポジトリの回復ステップを実行します。普通は
リポジトリとの間の通信をきれいに終了できなかったプロセスによって
しますが、簡単には手で修正することができないようにするためです。
実際にはそれほど難しいことでもないのですが。そしてデータがリポジトリに
しかし、時にはどうしてもリポジトリの履歴を操作したいことがあります。
リポジトリに間違って追加してしまったすべてのファイル(あるいはどんな
理由であれとにかくそこにあるべきではないファイル)を削除したいと思う
かも知れません。あるいは一つのリポジトリを共有する複数のプロジェクト
があって、それぞれを固有のリポジトリに分割することに決めたのかも
知れません。このような作業のためには、管理者はリポジトリ中のデータ
されたデータに加えた変更点に対する可読な形の表現形式です。ダンプ
あることの大きな利点は、注意して扱えばそれを調べたり修正したりできること
ダンプファイルに保存されているような場合には特定の場所を見つけて修正
管理者が自由にしたい場合に最もよく利用されるツールというわけでは
実行することによってそのダンプデータをすばやく簡単に修正することが
できるのです。保存したいと思うパスのリストか、保存したくないパスの
リストを単に与えてこのフィルタにリポジトリのダンプデータをパイプで
バージョン化されたパスのみを含むような修正済みダンプデータになります。
興味深いサブコマンドは二つだけです。これらのサブコマンドを使って、
このプログラムが実際にどのように動作するか例を見てみましょう。
別の場所でリポジトリ中でどのようにレイアウトを選ぶかを決める手順について
リポジトリ、あるいはそれらをまとめたものを使って、リポジトリ中で構成を
よくレイアウトを再編成していくつかの修正をしたいということもあります。
一番多いのは一つのリポジトリを共有していた複数のプロジェクトを
私たちの架空のリポジトリは三つのプロジェクトを含んでいます:
それらは以下のようなレイアウトになっています:
これら三つのプロジェクトごとの固有のリポジトリを手に入れるには、
次に結果のダンプファイルをフィルタに通しますが、各実行時で
ただ一つの最上位ディレクトリを含むように指定することで、
三つの新しいダンプファイルを生成することができます:
この時点で、判断しなくてはなりません。上でできた三つのダンプファイルは
正しいリポジトリですが、元のリポジトリ中にあった通りのパス構成で保存されて
という名前の最上位ディレクトリ名称を持っていることを意味します。
削除したいでしょう。それは何か以下のような感じになっています:
もし最上位ディレクトリを削除するためにダンプファイルを手で編集しようと
考えているなら、利用するエディタが改行文字を自動的にマシン固有の形式に
この変換が起きるとダンプファイルの内容はメタデータと一致しなくなり、使
この修正後に残ったファイルを使って新しい三つのリポジトリを作成する
ことができ、それぞれのダンプファイルを正しいリポジトリにロード
できます。パスの変更のみを含んでいるようなリビジョンを除外
以下のコマンドラインオプションを用意しています:
利用することによって)、残っているリビジョンのリビジョン番号を変更して
空のリビジョンが削除されない場合に、それら空のリビジョンに関する
ということを示す自動生成されたログメッセージのみを含むことになります。
くれますが、残念なことにいろいろな問題もあります。まずこのユーティリティー
はパスの構文に極端に敏感です。ダンプファイル中のパスが先頭にスラッシュ
パスの先頭にスラッシュを含める必要があります(そして、逆にスラッシュが
おそらく、すべてをスラッシュ付きにするか、その逆にするような正規化を
リポジトリ中のコピー操作をサポートしていて、ここでは新しいパスは
既に存在するパスからコピーすることによって作成されます。リポジトリの
が含めるような場所にコピーしたかも知れません。ダンプデータに自己一貫性を
する必要がありますが、それはダンプデータストリームから排除された
存在しないようなソースからのコピーの追加としては表示されません。
されたかを示すだけなので、コピー元の内容は利用不可能です。もし
リポジトリ中でこのようなコピーがある可能性がある場合にはもう一度
サブディレクトリにあるいくつかのデータベーステーブルに保存されています。
ユーティリティーの普通の状況での利用の仕方を反映したコマンドです。
のキーと値を表現するカスタム形式ファイルの読み書きを実行します。
状態についての有用な情報を表示します。これにはサブシステムの
ロックやデータ保存についての詳細統計情報が含まれます。
には以下のような作業を助けるための機能があります。それは
コミットし、リビジョンを表示したとき、新しいリビジョンに関連した
ログメッセージは、そのリビジョン自体のバージョン化されない属性として
格納されます。言い換えると、リポジトリはその属性の最後の値だけを
ときどきユーザはログメッセージに間違いを見つけます(スペルミスや
コミット完了後このログメッセージの変更を受け付けるとすると
バージョン化されない属性は、管理者のみが変更することが
もしログメッセージを管理者が変更する必要がある場合、
としてバージョン化されていない属性を修正する場合と同じ制約を
フックはやはり実行され、この仕組みで変更される修正点は反映されて
しかしフックを回避すると、属性変更、バージョン化されていない属性変更
トランザクションはきれいに消去されます。つまりトランザクション
しかし、しばしばトランザクションの掃除が起こらずに失敗することが
操作がユーザによって乱暴に終了されたか、ネットワークの異常などが
処理の途中で起こった場合です。理由にかかわらず、死んだままの
トランザクションが残ることはありえます。ディスクをわずかに食うことを
のぞけば、このようなトランザクションは全く無害です。それでも
潔癖な管理者はこのようなトランザクションを削除したいと思うかも
を使って、その時点での未完了のトランザクションの名前の一覧表示
に渡すことができ、そのトランザクションはきれいに削除
このような二つのサブコマンドを使う場合、リポジトリを一時的に
クライアントからアクセスできなくする必要があります。
これで誰もあなたがクリーンアップを始める前に正しいトランザクション
を開始できなくなります。以下は、リポジトリ内の未解決のトランザクション
のそれぞれについての情報をすばやく生成するためのちょっとした
出力のいろいろな断片をつないだようなものになります。
長く放置されているトランザクションは普通は何かに失敗したか、コミットを
中断されたかのどちらかです。トランザクションの日付スタンプは
操作がいまだに有効である可能性など、いったいどの程度あるのでしょうか?
簡単に言って、トランザクションのクリーンアップの決定は、無分別に
どうしたら良いかを決める上で役に立ちます。最後に、管理者はしばしば
死にかかったトランザクションの状態を確認することができます。
ここ数年で記憶装置のコストは非常に低くなってきた一方で、ディスクの利用方法
依然として考慮すべきことです。動作中のリポジトリによって消費される追加の
領域はオフラインでバックアップすることが必要な領域でもあり、バックアップ
トリを使う場合には、データ保管の仕組みは複雑なデータベースシステムである
ので、データのどの部分をオンラインのままに残し、どの部分にバックアップが
必要で、どの部分を安全に削除できるか、ということについて理解しておくことには
調整が必要な特殊な追加データはありません。
ログファイルの領域でした。これらのファイルはデータベースのある状態から
ファイルはある特定の時刻にその状態を反映される一方でログファイルはその前後
の状態のすべての本稿を含んでいます。そのようなわけでログファイルは非常に
特に外部操作することなしに未使用のログファイルを削除する能力を持つ
されています。この機能を有効にしたくない場合には単に
このような自動ログファイル削除の仕組みを利用しなければ、
リポジトリを利用するにつれてログファイルは蓄積されていきます。
ログファイル以外に何も残っていないような状況でデータベース全体を再構成する
ことができるようになっていなくてはならず、そのようなログファイルは
データベースの壊滅的な破壊からの復旧で利用できなければならないからです。
その後ディスクから削除することで領域を広げようとするでしょう。利用していない
差分の集まりをひとつのデータの塊として表現するものです。二つのデータ
が非常に似ていればこの差分化は差分化されたデータの記憶領域を節約します
あるデータのままですよ」という表現に必要なだけの領域で済みます。
具体的に言うと、ファイルの新しいバージョンがリポジトリにコミットされる
この新しいバージョンに対する差分として表現します。その結果、大きくなり
保存するよりはずっと小さなサイズで格納することができます。
小さくしたからといって必ずしもデータベースファイル自身のサイズを減らす
領域の内部的な記録を保存しておりデータベースファイルのサイズを拡張する
前にそのような領域をまず利用します。そのため差分化は直接に空間の節約につな
がりはしなくても今後のデータベースサイズが拡大するスピードを有効に押える
リポジトリは正しく閉じられなかった場合には中間的な状態に固まってしまう
ことがあります。こうなった場合管理者はデータベースを以前の一貫した状態
を利用しています。このしくみはデータベースの特定のが同時に複数のデータベー
スアクセスによって修正されないことを保証するためのもので、それぞれのプ
ロセスから見たときには、読み込み時にはデータは正しい状態にあるように見
えます。データベース中のどこかを変更する必要ある場合にはまず対象となる
データがロックされていないかどうかを確認します。もしロックされていなけ
ればそのプロセスはデータをロックし、必要な修正を加え、そのデータに対す
るロックを外します。他のプロセスはデータベースの内部に引き続きアクセス
できるようになる前にロックファイルが削除されるまで待たされます。
かけたロックを削除する機会をなくしてしまうことがあります。その結果
こうなったときには、リポジトリへのどのようなアクセスも永久に待たされる
が解除されるのを待ちますが、それは決してやってこないからです)
まず、そういうことがリポジトリに起こっても、悲鳴をあげないで
とチェックポイント、それに事前ジャーナル書き込みの仕組みをうまく
利用していて、本当に破滅的な出来事以外は
データベース環境を永久に葬り去ることはできないことを保証します。
十分神経質なリポジトリ管理者は何んらかの方法でリポジトリデータの
オフラインバックアップをとっているかも知れませんが、バックアップテープを
リストアしてくれとシステム管理者を呼ぶのはまだです。
リポジトリにアクセスしている(あるいはしようとしている)プロセスが
一つもないことを確認してください。ネットワークアクセス可能な
これは重要ですが、実行時と同様、復旧時に間違ったユーザで作業する
ことによってもリポジトリファイルのパーミッションが変更されて
したのにアクセス不能のままになってしまう可能性があります。
この方法はほとんどのリポジトリロックを解消します。このコマンドは
を所有し、管理しているユーザで実行することに注意してください。
復旧作業は、傷を負ったいろいろなデータベースファイル
所有しているファイルを作成することで、これはリポジトリへの
接続状況が復旧した後でも通常のユーザはこれに対してアクセスする
もしいま述べた作業が、何かの理由でうまくリポジトリを正常に
一つの、持ち運びに便利な単純なファイル形式にまとめたいことがあります。
バックエンドデータベースのスキーマ変更によっては
リポジトリの前のバージョンとの互換性がなくなってしまいます。
ンド間を切り替えて使う場合です。このために推奨されている作業ステップは比較
を使ってリポジトリをダンプファイルにダンプしてください。
古いリポジトリをどけて、新しい空のリポジトリをそこに作りますが、
使って、ダンプファイルを、それぞれ作ったばかりのリポジトリに
古いリポジトリから新しいものに必要なカスタマイズ部分を
ファイルと、フックのスクリプトが含まれます。新しいリリースの
や設定オプションに変更がないかどうかを見てください。
合(例えば別のコンピュータに移したり、別のスキーマを経由して
アクセスしたりするような場合)、おそらくユーザには既存の作業
ように言わなくてはならないかも知れません。
ダンプ形式になっているものです。ダンプ形式は標準出力に表示され、
進行状況などのメッセージは標準エラー出力に表示されます。これで
出力をファイルにリダイレクトすることができ、その一方でステータス
の出力については端末ウィンドウ上で見ることができます。たとえば:
処理の最後で、指定した範囲のリポジトリリビジョンのデータすべて
方法でリポジトリからリビジョンツリーを読み出すことに
して解析し、ダンプされたリビジョンを目的のリポジトリに再現します。
それはまた経過情報などを返しますが、こちらは標準出力に
おきるそれぞれのコミットの前後で実行するフックスクリプトを使うことも
ように指示できます。これで例えば、通常のコミット時と同様の妥当性チェック
のようなステップをロードされるリビジョンごとに保障するような使い方が
とロード処理に使うので、気の利いた人は、以下のようなやり方を試す
自体よりもずっと大きくなるでしょう。理由はすべてのファイルのすべての
バージョンは、ダンプファイル中では完全なテキストとして表現される
からです。これはダンプデータをパイプ経由で他のプロセス(圧縮プログラム
もっとも早く単純な方法です。しかし長期保存用にダンプファイルを作成する
したほうが良いでしょう。このオプションを使うと引き続くリビジョン間の
うどリポジトリ中に保存されたリビジョンファイルと同じような形になります。
このオプションを使うと処理は遅くなりますが結果のダンプファイルは
元のリポジトリにかなり近いサイズにまでなります。
このオプションを省略すれば、すべての存在するリポジトリ
後で実行されるローダが前のリビジョンを元にしてそのリビジョンを再
作成するのに必要な十分な情報があります。
言い換えると、ダンプファイル中でどのようなリビジョンが指定されても
リビジョン中で変更のあったアイテムのみがダンプに現れるということ
最初のダンプリビジョンを表現することはありません。この理由の一つは
はダンプデータがロードされるリポジトリの状態について何も知らない
いるのを保証するため、最初のダンプリビジョンはデフォルトでは
すべてのディレクトリ、ファイル、リポジトリにあるそのリビジョンの属性
しかし、このデフォルトの振る舞いを変えることもできます。リポジトリを
直前リビジョンとの差分をとろうとします。残りのすべてのダンプ
されるリビジョンにも同じ方法で扱います。
それからダンプ範囲にある残りのリビジョンが出力するのと同じように
この利点は大きな一つのダンプファイルのかわりに、ロードに成功するような
小さないくつものダンプファイルを作ることができることです。
これらのダンプファイルは以下のようなコマンドの流れで
かっこいい方法は、既に存在しているダンプファイルに
新しいダンプリビジョン範囲を追加することです。たとえば
フックをトリガーするような一つのリビジョンのリポジトリ
ダンプを追加するものです。あるいは最後にスクリプトを実行した時点より
後にリポジトリに追加されたすべてのリビジョンに対してのダンプファイルを追加する
ようなスクリプトを実行するかも知れません。このように利用することで
価値のある手段となりますが、これによって、リポジトリの変更を
時間をかけてバックアップして、システムクラッシュや、他の壊滅的な出来事に
ダンプ形式はまたさまざまな異なるリポジトリの
内容を単一のリポジトリにマージするために利用することもできます。
ロードプロセス用の新たな仮想ルートディレクトリを指定することが
のダンプファイルがある場合、最初にそれらすべてを保持するような
新しいリポジトリを作ることができることを意味します:
それから三つの以前のリポジトリのそれぞれの内容を含んだ
新しいディレクトリをリポジトリ中に作ります:
最後に個々のダンプファイルを新しいリポジトリのそれぞれの
データを変換する方法です。これができる理由はダンプファイル形式は
それぞれの変更は新しいリビジョンとして扱われます。
現代的なコンピュータが生まれてから技術的には非常に発展してきたものの、
運命は最も優れた管理者にさえ降りかかるのです。それで、とても重要な
バックアップをとってから起きたリポジトリの変更部分だけをバックアップ
リポジトリのフルバックアップは文字通りリポジトリディレクトリ全体の
さて、一時的にリポジトリに対するすべてのアクセスを禁止しなければ、
単純な再帰的なディレクトリコピーの実行は、不完全なバックアップを作って
しまう危険を持っています。というのは誰かが並行してデータベースに書き込んで
は、動作中のリポジトリをハックアップするのに必要なステップを実行します
差分バックアップがあるとしても、規則的にこのプログラムを実行したく
プログラムスケジューラに追加しようと考えるかも知れません
作られるたひにリポジトリの新しいバックアップができる方式です。
単に、以下を動作中のリポジトリディレクトリにある
リポジトリが何かひどいことになったときには、置き換えて使うことが
両方のバックアップ方法にはそれぞれ利点があります。一番簡単なのは
フルバックアップで、それは常に現行リポジトリの完全なコピーです。
繰り返しになりますが、何かまずいことが動作中のリポジトリに起きた
時には、単純な再帰的なディレクトリコピーでこのバックアップを
復元することができます。残念なことに、もしリポジトリの複数のバックアップ
を管理している場合、このようなフルコピーは、実行中のリポジトリと
リポジトリダンプ形式を使った差分バックアップはデータベーススキーマ
役に立ちます。リポジトリの完全なダンプとロードは一般的に
リポジトリを新しいスキーマにアップグレードすることが必要です。
それは、それぞれのコミットがダンプファイル、またはリポジトリの
どちらのバックアップの場合も、リポジトリ管理者は
どのようにしてバージョン化されない属性への変更がバックアップに影響を
与えるかに注意する必要があります。このような変更は新しいリビジョンを
そして、時間の順序に沿わないでリビジョン属性を変更することができる
ので、最後のいくつかのリビジョンの差分バックアップはそれ以前の
バックアップの一部として行われたリビジョン属性の修正は取り入れる
一般的に言って、本当に人間離れした潔癖さを持った人だけが完全なリポジトリ
のバックアップを必要とするのでしょう。つまり、コミットが起こるたびに
バックアップをとるわけです。しかし、そのリポジトリが相対的に細かい
いるのであれば、データベースのホットバックアップはリポジトリ管理者が
システム全体の日次バックアップの一環として導入したいと考えるものかも知れません。
データとしての十分な冗長性を持っています。少なくとも最近のいくつかのコミット
必要なだけ保護するのに越したことはありません。
しばしば、リポジトリのバックアップに対する最良の方法は、分散
させることです。フルバックアップと差分バックアップに、コミット
が作られるたびにバックアップします。そして、すべてのコミットと
属性変更の通知メールをアーカイブしてとっておきます。同様の方法を
の鉄拳からハードウェアを守ることはできないことに注意してください。
バックアップは確かにそのような試練の時からあなたを救うはずです。
既にデータの集まりを持っていて、それをバージョン管理したい
しかしそうする前に、リポジトリについて長期的な視点で注意深く
考えるべきです。この節では、リポジトリのレイアウトをどのように
計画するか、そしてそのレイアウトの中にどのようにデータを配置する
ディレクトリをあちこちに移動することができますが、そうすることは、
データが特定の場所にあることを期待している、ときどきリポジトリにアクセス
する人たちの作業を中断させてしまうかも知れません。先のこともちょっとは
考えてください。バージョン管理下にデータを置く前に、前もって計画を
あります。あなたが、リポジトリ管理者としていくつかのプロジェクトのバージョン
管理システムのサポート責任者になったとしましょう。最初の判断は
複数プロジェクトに対して一つのリポジトリを使うか、プロジェクトごとに
複数プロジェクトのために一つのリポジトリを使うことにはいくつか
利点があまりす。一番はっきりしているのは、重複した保守作業が不要だと
また、プロジェクト間のデータ移動は簡単ですし、履歴バージョン情報を
一つのリポジトリを使うデメリットは、異なるプロジェクトは異なる
コミットメーリングリストを持っていたり、異なる認証、許可などが
ことに注意してください。人によっては、変更が自分のプロジェクトに
何もないのに、他のプロジェクトが活発に新しいリビジョンを追加する
ことによって、最新リビジョン番号がカウントアップされていくのが
どの程度深く関係しているかによってプロジェクトをグループ化する
ことができます。それぞれのリポジトリにいくつかのプロジェクトを持たせる
ことで、少ない数のリポジトリを管理することもできます。この方法では
データを共有したいプロジェクトは簡単にそうすることができますし、
新しいリビジョンがリポジトリに追加されると、開発者は
そのような新しいリビジョンは、自分のプロジェクトか、少なくともそれに
関係しているプロジェクトの誰かがやったものだということがわかります。
リポジトリに関係してどのようにプロジェクトを編成するかを決めたあとは
多分、リポジトリ自身のディレクトリ構成を考えたいと思うでしょう。
これは主な開発ラインから分岐したさまざまな名前の付いたブランチを作る
かも知れませんが、決して修正はされないようなブランチを入れるための
それぞれのプロジェクトルートがリポジトリ中のどこにあるかは問題には
なりません。もしリポジトリに唯一のプロジェクトがある場合は
それぞれのプロジェクトルートを置くための論理的な場所はプロジェクト
ごとのリポジトリのルートになります。もし複数のプロジェクトが
ある場合は、リポジトリ内部のグループ中にそれを配置したいかも知れません、
おそらく同じサブディレクトリ中の似たような目標や共有するコードと
一緒にプロジェクトを置くか、あるいは名前の辞書順にグループ化するか、
良いと思われる方法でリポジトリをレイアウトしてください。
必要に応じたふさわしい方法を選んでください。
レイアウトの作成と、初期データのインポート
リポジトリ中でのプロジェクトのレイアウトが決まったら、
そのレイアウトの形にリポジトリを構成して、プロジェクトの初期データを
ロードしたいと思うでしょう。これにはいろいろな方法があります。
一つ一つリポジトリレイアウトに従ってディレクトリを
最初にディスクの一時的な場所にレイアウトを作っておいて、その全体を
一回のコミットでリポジトリにインポートすることができます:
骨組みとなるレイアウトができて、もし既にインポートしたい
データが存在しているならそれをリポジトリにインポートすることができます。
作業コピーをいったんチェックアウトして、作業コピー中でデータを移動したり
話を始めると、もう既にリポジトリ管理については議論しません。
についての基本的な理解ができたはずです。この作業を助けるさまざまなツール
どうやってそれを避けるかを議論しました。
利用できる形にするかを考えるだけです。次の章ではネットワーク利用について
みんなのデータがある作業コピーの背後で起きている神秘の領域に
とにかくフックインターフェースを迂回するような方法で呼び出されるのでした。
同じマシン上で実行されている複数のクライアントから同時にアクセスすること
全世界にあるコンピュータ上のクライアントからアクセスされる一台のサーバ上
この章ではリモートクライアントを使ってホストマシンの外部にさらされる
利用方法について説明します。この章を読んだ後であればどのタイプのネットワーク
設定が自分のニーズとって正しいものであるかを決め、どうやれば自分のホスト
コンピュータ上でその設定が有効になるかについて理解できるはずです。
に対してどのようなタイプのサーバプロセスからもアクセスできるようにプログラムを
それに関連したネットワークプロトコルで通信することのできるプラグインを書くこと
実装が可能なはずです。ただしこれを書いている現時点では実際には二つの
非常に小さい、スタンドアロンのサーバプログラムでクライアントとの間で独自の
として勧めたりすることはありません。またどのようなネットワーク実装についても
副次的な価値しかないものとして扱うこともありません; それぞれのサーバは
それぞれの方法でリポジトリにアクセスし、お互いの邪魔をすることがないように
管理者は、自分とそのユーザにとって最良の動作をする構成を自由に選ぶ
クライアントがどのようにしてサーバと通信するかの一般的な議論です。
この節を読み終えた後では、クライアントの応答についての設定によって
サーバがどんな風に違った形で振る舞うかについて詳しく理解していることでしょう。
しかしリポジトリからの情報が必要な場合にはネットワーク要求を発行し、
これに対してサーバが適切に応答します。ネットワークプロトコルの詳細は
サーバプロセスがクライアント要求を受け取ると、普通はクライアントの認証を
要求します。クライアントに対して認証確認を実行し、クライアントは
認証証明を提示することでこれに答えます。いったん
認証が成功すればサーバはクライアントがそもそも要求していた情報を返します。
これはある種の操作をより洗練されたものにします。たとえばもしサーバが
世界中の誰でもそのリポジトリを読めるように設定すれば、クライアントが
クライアントネットワーク要求が新しいデータをリポジトリに書き込む場合
作成されます。もしクライアント要求が認証されれば認証されたユーザ名は
これはユーザにとっては大きな苦痛となることがあります。常にパスワード
あります: ディスク上での認証証明をキャッシュするための組み込みシステム
があります。デフォルトではコマンドラインクライアントがサーバに対する
認証に成功したときは常にユーザの実行時環境領域にその証明を保存します
により詳しい説明があります)。成功した証明はディスクにキャッシュされ
クライアントが認証確認を受けたとき、まずディスクキャッシュにある証明を探し
ます; 存在しないかキャッシュされた証明が認証に失敗した場合はクライアントは
ユーザに入力を求めるプロンプトを出します。
セキュリティー狂なら思うかも知れません、「パスワードをディスクにキャッシュ
ので(所有者である)ユーザだけがそのデータを読むことができ、誰でもというわけでは
ありません。オペレーティングシステムのファイル所有権限はパスワードによって保護
によって管理されユーザ固有のログイン認証に結びついているのでそのユーザだけが
パスワードが変更された場合、キャッシュされているすべてのパスワードは復号化不能
すべての利便性を犠牲にしてまでセキュリティーを確保したいという、本当にスジガネ入り
のセキュリティー狂には、すべての認証キャッシュを完全に無効にすることも可能です。
あるいは、証明のキャッシュをずっと無効にし続けたい場合は実行時
設定すればディスク上に証明書をキャッシュしなくなります。
ときどき特定の証明をディスクキャッシュから削除したくなることがあります。
キーはファイルが関係している特定のサーバの認証範囲を記録しています:
必要です。たくさんのクライアントサブコマンドはこれらのオプションを
受け付けます; しかしこのようなオプションはサーバに自動的に証明を
送るのではないことに注意してください。既に
説明したようにサーバは必要に応じてクライアントに証明の提示を「要求」
もしユーザ名とパスワードがオプションとして渡された場合でも、それは
サーバが要求したときにのみ提示されるのです。
受けたいか、あるスクリプトがキャッシュされている証明なしに
どうかを確認します。指定していないか、オプションによる認証が失敗した
ユーザが既に適切な証明をキャッシュしているかどうかを調べます。
もしそうでないかキャッシュされた証明が認証に失敗した場合はさらに、
ユーザに対して証明の入力をうながします。
クライアントが上記のどれかの方法で認証に成功した場合はディスク上にその
どうやってサーバに認証するか、またリポジトリに適切なアクセス制御を設定
するにはどうしたら良いかについて説明します。
あります。オプションなしで起動した場合は何もせずヘルプメッセージを
パーミッションをもったユーザであることを確認してください。
起動するためのサードパーティーのツールがあります。このようなツールの
を通じて)、通信データは自動的にクライアントの背後にいる何らかのトンネル
このようなトンネルエージェントによって起動された場合は認証ユーザは
リポジトリデータベースファイルに完全な読み書きアクセスを持つことに注意
であることを思い出してください; リポジトリにアクセスするプロセスは
すべてリポジトリ全体に対して適切な読み書きのパーミッションを持って
いる必要があります。このことに注意していないと、いろいろな問題に
使っている場合はそうです。複数リポジトリアクセス方法のサポートの項をよく読んで
ないということを忘れないでください。あなたが公開しようとするリポジトリ
排他的な所有と権利を与え、そのユーザでのみサーバプロセスを起動します。
システム上のすべてのリポジトリが利用可能になります。クライアントは
オプションを渡すこともできますが、これはそのパス以下のリポジトリだけを公開
リモートファイルシステム空間のルートとしてプログラムが扱う場所
を効果的に変更することができます。この場合クライアントはそのルート
までの部分を除いたパスを指定することになり、もっと短い(そしてより情報制限された)
クライアントは特定のリポジトリを選択します。
ファイルを処理しその中に定義されている認証と認可の方式に強制的に
クライアントは要求を匿名で行うことができ、どのような認証確認も
クライアントは常に認証許可を求められるか、
認証確認の方法だけを知っています。本質的にサーバはクライアント
緒にしたデータについてのフィンガープリントを作成し、これを応答メッセー
ジとして送信します。サーバは同じ計算を保存してあるパスワードについて
おこない結果が同じであることを確認します。いかなる場合でも
ネットワーク上に実際のパスワードが流れることはありません。
もちろんクライアントはトンネルエージェント、たとえば
認証することもできます。この場合サーバは単に実行している
ユーザを確認し、それを認証されたユーザ名であるとして
ファイルは認証と認可の方式を制御する中心的な仕組みです。このファイルは他の
ユーザ名とパスワードを含むファイルの定義で始まり、認証範囲を設定
を含む個別のファイルを指す変数で、やはり同じ形式が利用されます。
正しく保つのは容易なことです。一方、同じユーザファイルを共有するような
二つ以上のリポジトリがほしいこともあります; そのような場合は
ファイルは多分もっと公開された場所に移動すべきでしょう。ユーザファイルを共有
するリポジトリは同じ認証範囲を持つよう設定されていなくてはならず、それは
ユーザ全員が本質的にただ一つの認証範囲を定義するためです。
ファイルがある場所であればどこでもファイルの読み書きパーミッション
どのユーザが実行しているかわかるのであれば、必要に応じて
ユーザファイルに対する読み出しアクセス制限をかけてください。アクセス制御の設定
この例としての設定は、実際にはこれらの変数のデフォルト値なので定義
しなくても問題ありません。もしさらに保守的に設定したいのなら、
匿名のアクセスを完全に遮断することもできます:
を理解することに注意してください。ユーザは完全な読み書きアクセス、
です。リポジトリ中の特定のパスに対する詳細なアクセス制御は
存在しません。多くのプロジェクトとサイトではこのレベルのアクセス制御
は十分すぎるものです。しかしもしディレクトリごとのアクセス制御が必要
それは本当のシステム上のアカウントを作る必要がないからです。一方
知れません。そのような場合、プロジェクトユーザのすべてはシステムアカウント
いるのでクライアントがコミットしようとすると、その認証済みのユーザ名は新しい
デーモンに接続するわけではないということです。
このアクセス方法はデーモンは不要で、存在しているかどうかを知る必要も
プロセスにだけ依存していて、ネットワーク接続が閉じるとそのプロセスも終了します。
ください。これは自動的なパスワードのキャッシュが起きないことを
がユーザはパスワードキャッシュの仕組みによって通常そのことに気づくことは
トンネル上で実行する場合、認可は基本的にはリポジトリデータベースファイルに
対するオペレーティングシステムのパーミッションによって一義的には制御
リポジトリにアクセスした場合と同じことになります。
複数のシステムユーザがリポジトリに対して直接アクセスしようとしている場合
モードに関する動作設定をすることができます。(実行時設定領域の項
この新しいトンネル定義を利用することができます:
しかし、以下のようにもっと賢いトンネルスキーマを定義することもできます:
この例はいろいろなことの参考になります。まずそれはどのようにして
特定のオプション付きで起動するかを示しています(この場合それは
を接続したいと考えているならこれは便利です。
してトンネルプログラムの名前を上書きする環境変数を定義してやれば
エージェントを上書きする便利な方法です。
しかしもし異なるサーバ上でいくつもの異なる上書きが必要で、それぞれが
示すような仕組みを利用することができます。
方法を示して、複数のユーザが単一システムアカウントをどのように共有すれば
がインストールされていて、ユーザがその公開鍵でログインできることを
確認してください。パスワード認証は動作しなくなりますが、それは以下の
実行されるサーバ側コマンドを指定することができるので、特定の
するかも示しています。これはデーモンプロセスとして
テムの特定の部分にアクセス制限する場合や、単に
複数のユーザが単一アカウントを共有するようにもできます。それにはまずユー
ザごとに独立したシステムアカウントを作るかわりに、メンバーごとに公開鍵
ように設定しています。どちらもそれぞれにカスタマイズされたコマンドが実行されます;
が名前つき引数が認証されたユーザであることを認めるように指示しています。
システムアカウントから発行したように見えるようになります。
最後の注意です: 共有アカウントにある公開鍵を経由してユーザにアクセス権を
一般的なポートフォワードを実行することもできます。ユーザにできるかぎり
すぐ後にそれぞれの制限オプションを指定する必要があります:
パーティー性製品によってサポートされており、それを利用すればネットワーク
管理者は新たなカスタムポートを開く必要がありません。
機能を持っていますが、セットアップは少し難しくなります。柔軟性には
いくつかの例はそのようなディレクティブの利用方法になっていますが、
から自由に参照可能です。たとえば設定ディレクティブの一般的な
よって生成されるアクセスログとエラーログのディスク上での場所を指定する
情報取得のために常に閲覧することができ、ほかの方法でははっきりしない
問題の原因を明らかにするかも知れません。
実行しており、かなりの経験を持っているかも知れません。このドキュメント
提供モジュールです。すべての部品を手に入れてしまえばリポジトリのネットワーク
ソースコードからコンパイルするか、自分のシステム用の既にコンパイル
済みのバイナリパッケージをインストールすることによって取得できます。
構文を持ち、名前の付いたモジュールをディスク上の共有ライブラリの場所に対応付けます:
共有オブジェクトとしてコンパイルされた場合、それに対しても同様の
行の前に設定することに注意してください:
にさまざまなほかの設定ディレクティブを書きます。
するのとは違って新しいネットワーク公開用リポジトリを作るたびに
での信頼性チェックの一環として、コピー元はコピー先と同じマシン上に存在
していなくてはなりません。この要求を満足させるためにはサーバのホスト名
この時点で、パーミッションがどうなるかというについて十分考慮する
読み書きのパーミッションを設定する必要があります。(詳しくは
既に存在しているウェブページやスクリプトの設定に問題を起こさない
あなたに対して提供しているほかのサービスと協調するようなパーミッション
このための唯一の正しい解法といったものはありませんし、個々の
管理者は正しいやり方をするための異なる理由を持っているはずです。
リポジトリの設定時に一番よく見落とされることであるのに注意してください。
それは単純にユーザ名とパスワードを使って、ある人間が自分がその当人である
を用意して、受け入れることのできるユーザ名とパスワードの一覧を管理
まず彼らをパスワードファイルに追加する必要があります。
任意の名前で認証ドメインを与えるためのものです。ほとんどのブラウザは
ユーザに名前とパスワードを問い合わせるときにこの名前をポップアップダイアログ
ブロックは以下のような感じになっていることでしょう:
種類のクライアント要求が認証で必要とされるのかを言うための
ディレクティブです。これをやるのに最も簡単な方法はすべてのリクエストを保護
すべてのリクエストは認証されたユーザであることを伝えます:
を流れるため、セキュリティー上は非常に弱いものです。もしパスワードの
リポジトリを自社ファイアウォールの外にさらす必要のあるビジネス
は認可されていない他人が自分たちのネットワークデータを「盗聴」
しているかも知れないということを意識すべきです。
ではなく、確認要求を受けた場合には自分の証明書を提示する能力も持って
すれば、その後のすべての通信はセッションキーによって暗号化されます。
どのようにしてクライアントとサーバ証明書を生成するか、またその証明書を
どのように管理するかについて説明します。
クライアントは二つの異なるタイプの情報を受け取ることができます:サーバ証明書クライアント証明書の提示要求
クライアントがサーバ証明書を受け取った場合、それが信頼できるものであるか
どうかの検証が必要になります: サーバは本当に名乗っているそのサーバなの
とにかく信用するかどうかをユーザに聞いてきます:
このダイアログはなじみ深いものだと思います; 本質的にはウェブブラウザで
する、というオプションを選ぶと、サーバはあなたのユーザ名とパスワードを
領域にそのサーバ証明書をキャッシュします。(クライアント証明のキャッシュの項
やり取りについては自動的にこの証明書を信用します。
されたプライベート証明書を送り返します。クライアント証明書は通常
暗号化された形式でディスク中に保管され、ローカルパスワードによって
証明書のパスと、それを保護しているパスワードについて聞かれます:
ほとんどのウェブブラウザは既にその形式の証明書をインポートしたり
エクスポートしたりすることができます。他の方法としては既存の証明書
この確認要求を自動化することを認めています。そのような情報は
自動的にクライアント証明書の確認要求に応答することができるようになります。
アクセス制御の一番簡単な方法は特定のユーザをリポジトリに対して読み出し
ディレクティブを追加することによってすべてのリポジトリ操作にアクセス制限を
にありますが、世界中の誰でも読み出しアクセスすることが可能です(
それはチェックアウトしたり、ウェブブラウザでリポジトリを閲覧する
与えます。たとえば、現在サポートされている読み出しのみの操作を
セクションを見てください。ディレクトリごとのアクセス制御
を使うと、より詳細なパーミッションの設定が可能です。このモジュールは
で定義されたアクセス方式に基づき必要に応じてアクセスを拒否します。
多くのバイナリ配布でもやはり自動的にインストールします。正しくインストール
ディレクティブのすぐ後に来ていることを確認してください:
設定する必要があります。このディレクティブはリポジトリにある
パスのパーミッションが書かれたファイルを指定します。(すぐあとで
設定することができます。まず基本的な設定パターンの一つを選びます。
最も単純なブロックはすべての人に対して自由にアクセスすることを
この対極にある設定方法として、すべての人にたいして認証要求するための
ブロックを設定することもできます。すべてのクライアントは自身を特定
ディレクティブによって無条件に認証を要求し、またその方法を定義します。
三番目の非常に一般的な方法は認証つきアクセスと匿名アクセスの組合せ
によるものです。たとえば多くの管理者はあるリポジトリのディレクトリを
誰でも読めるようにしたいが、もっと重要な場所については認証された
このような設定ではすべてのユーザはまずは匿名でリポジトリにアクセスし
ます。ある時点で本当のユーザ名を要求しなくてはならないアクセスが
しまえばその中にアクセスファイルを作り、認証の規則を定義すること
実行時設定ファイルで利用されるのと同じです。
一番単純な形では、それぞれのセクションはリポジトリ
とのその中にあるパスの名前を決め、認証用のユーザ名はセクションごと
の中にくるオプション名になります。それぞれのオプションの値は
になります。ユーザがまったく含まれていなければ、アクセスは全面的
ディレクティブを使っている場合はセクション中でリポジトリ名を指定するのが
結局そこには唯一のリポジトリしか無いのですから。
ディレクトリに対して完全な読み書きアクセスが可能ですが、
アクセスのみです。それ以外のユーザにはこのディレクトリのアクセスは
もちろんパーミッションは親ディレクトリから子ディレクトリに継承
アクセス方式を指定することができるという意味です:
では書き込みができますが、ディレクトリのほかの部分では依然として読み出し
ユーザ名変数を設定しなければ、他の人を継承の規則に従って許可する
対して完全な読み書きアクセスが可能ですが、その中のサブディレクトリ
デフォルトでは、誰であれリポジトリに対するすべてのアクセスは禁止
ですべてのユーザに対して少なくとも読み出しパーミッションを与えたい
これはよくある設定です; セクション名の中にリポジトリ名が存在しないことに
すべてのユーザによってどこからでも読み込めるようにします。
すべてのユーザがリポジトリに読み込みアクセスできるようになってしまえば
特定のリポジトリの特定のサブディレクトリに特定のユーザが読み書き可能と
それは匿名ユーザにマッチするような唯一のパターン
グループを使ってユーザと同じようにアクセス制御することができ、この場合
グループは他のグループを含むように定義することもできます:
がついたデータが間違って外部に漏れないようにいろいろな工夫がしてありま
のようなコマンドからの戻り値となるすべてのパス名とファイルの内容を綿密に
チェックする必要があることを意味します。このようなコマンドが認可のポリシーに
よって読み込むべきではないファイルパス名に出会うと、通常は完全にそれを
ようなファイルの以前の名前に読み込み制約がある場合には、単に異常終了して
このようなすべてのパス名に対するチェックは場合によっては非常に効率の悪
ジョンの一覧を取得する場合、サーバはすべてのリビジョンのすべての変更さ
れたパスを見てそれらが読み込み許可されているかどうかを調べます。許可さ
れていないパスが見つかるとリビジョンの変更のあったパスの一覧からは除外
せんが、たくさんのファイルのあるリビジョンでは多くの時間を消費します。
しかしこれはセキュリティーを保つための代償です:
的にどんな認可モジュールがインストールされているかは知らないので、単に
一方、これに関する逃げ道もやはりあって、セキュリティーよりも効率を重視
するようにも設定できます。ディレクトリごとの認可の仕組みをまったく利用
のモジュールを使わないのなら)、このパス名に対するチェックを完全に無効に
バージョン化されたファイルやディレクトリの最新リビジョンがウェブブラウザ
の一覧またはファイルの内容を表示します。
に気づくでしょう。このディレクトリ一覧をカスタマイズするために、
シートを使ってディレクトリ一覧をウェブサイトのほかの部分で利用されている
色スキーマや画像に一致させることができます。あるいは、もし望むなら
なければなりません!古いリビジョンを表示することはできますか?
ファイルとディレクトリの最新バージョンを意味するからです。
には透過的に見えるというものです。古いバージョンのファイルを見つける
ウェブブラウザで簡単にできるようなことではありません。
それで、最初の問に答えとしては、ファイルやディレクトリの古いバージョン
引数を渡すことです。しかしウェブブラウザで古いリビジョンを参照
するには、サードパーティー製のソフトウェアが必要になります。良い例は
書かれましたが最新の開発バージョンでは(この文書を書いている時点では)
アルゴリズムを使ってファイルより小さなデータの塊に「縮める」
ように正しくプログラムを設定することだけです。
圧縮の仕組みは、実際のサイズを減らすためのネットワーク転送データの圧縮と
解凍処理でクライアントとサーバに少し負荷をかけます。ネットワークの帯域
が細い場合この圧縮はサーバとクライアント間の転送スピードを非常に大きく
することができます。極端な場合このデータ転送量の現象は、操作がタイムアウト
に関係したその他の機能で、たとえば特定のポートを指定する機能(
アクセスする仮想ドメイン名の機能や、プロキシ経由でリポジトリにアクセス
を経由してリポジトリにアクセスすることもできます。ほとんどのモダンな
いろいろな異なる方法でどのようにしてリポジトリにアクセスするかを見て
きました。しかし、複数の方法で同時にあるリポジトリにアクセスすることは
ある時刻において、以下のようなプロセスがあなたのリポジトリに対して
読み出しアクセス、あるいは書き込みアクセス要求を出しているかも知れません
指定することで直接リポジトリにアクセスする通常のユーザによって:
プロセスに接続する通常のシステムユーザによって:
プロセスが、特定の固定されたユーザとして実行されることによって:
管理者が直面する一番よくある問題はリポジトリの所有権とパーミッションです。
を使っているとして、一番素直な解決方法は、すべての潜在的なリポジトリユーザ
グループによって完全に所有されている形にしてしまうことです。しかし
それだけでは十分ではありません。プロセスはデータベースファイルに、排他的な
それでリポジトリユーザの共通グループ設定の後の次のステップはすべてのリポジトリ
クライアントプログラムを実行すれば良いでしょう。同様のラッパースクリプトを
ログファイルを作り動作を記録します。リポジトリ自体は
このようにして新規に作られたファイルが同じグループによって
所有される必要はありません。これが理由でユーザにとっては
また別のパーミッションの問題がおこります。うまい回避策としては
すべての新たに作成されるログファイルは親ディレクトリと
いったんこの問題を乗り越えてしまえば、あなたのリポジトリは
すべての必要なプロセスからアクセスすることができるようになって
いるはずです。少し面倒で複雑ですが、複数のユーザが書き込みアクセス
を共有することで起こる問題は、しばしばきれいに解くことができない
ありがたいことに、ほとんどのリポジトリ管理者はそのような複雑な
同じマシン上にあるリポジトリにアクセスしたいと思うユーザは
リポジトリのために管理することは頭痛の種を増やすだけのことです。
自分のニーズに本当に合ったサーバ構成を選択し、そこにしがみついて
アカウントのある複数のユーザを設定するのはとても技巧的な話しになるかも
作業に混乱した時にそなえてこの節で議論した内容をもう１度まとめて
リポジトリ全体をそのグループの所有とし、グループパーミッションに
この問題は実際によくある質問で、サーバの設定に間違いがあると起こります。
ここでもよくある間違いは認証確認を決して要求しないようにサーバを
をクライアントに渡しているのにそれが利用されないという状況に驚くでしょう。
つまり新しいリビジョンは依然として匿名でコミットされているように見える
やはり脆弱ですが、そのような攻撃は、暗号化されていないパスワードを
盗聴するタイプのものに比べてはるかに困難です。
セキュリティーにもっと神経質な人はクライアント証明書用パスワード
もうあなたは、ほとんどのバージョン管理操作を実行するために
を実行してしまうような反射神経さえ身についているかも知れません。
追加のクライアント側、サーバ側のツールのいくつかの詳細にも触れます。
バージョン管理の能力についてなじんでいるべきです。もしまだそれについて
よって制御することができます。そのようなオプションの多くはユーザがすべての
を指定するためにユーザにコマンドライン引数を思い出させるように強いるよりも
それが第二層になります)これらのファイルは好きなテキストエディタを
によって読み出される命令を含んでいて、ユーザが好むさまざまなオプションの
ユーザプロファイルディレクトリ(これは通常は隠れたディレクトリになりますが)
理解することができます。これはシステム管理者にあるマシン上での
すべてのユーザに対するデフォルトを設定する力を与えます。システム全体
プログラムに与えるコマンドライン引数は振る舞いを決める最後の場所に
システム全体の設定領域を作ろうとはしません。
がサポートするそれぞれのオプションのデフォルト値が入っており、
ほとんどがコメントアウトされていて、さらに、どのようにキーに対する
説明付きでグループ化されています。何かの振る舞いを変えるためには
関連する設定ファイルをテキストエディタで開き、必要なオプション値で
もし設定をデフォルトに戻したい場合は、いつでも単にその設定ディレクトリを
新しい設定用ディレクトリがデフォルト値を含む形で生成されます。
キャッシュ情報の要素を含むサブディレクトリの集まりを保持します。
このディレクトリはユーザ自身だけがその内容を読むことができるような形に
レジストリベースの設定オプションは、ファイルベースの残りの部分を
このようなオプションは、設定ファイル中で見つかった値によって上書き
を、レジストリから完全にキーを消さずにコメントアウトすることができます。
レジストリに書き込むことは決してありませんし、そこに
デフォルトの設定値を作ろうともしません。必要なキーは
シェルからそのファイルをダブルクリックすると、そのデータが
中には、よく利用される設定オプションの大部分とそのデフォルト値が
あることに注意してください。さらにすべてのオプションは、コメントアウト
されていることにも注意してください。オプション名の先頭のハッシュ文字
ネットワーク層に関係したものを含んでいます。二つのセクション名がその
テーブルです。このセクションのキーは、ファイル中にある別のセクションの名前
されるマシンのホスト名称と比較されます。
セクションにあるグループ名に合うサーバ名称とマッチするものを探します。
そのセクションから実際のネットワーク設定オプションを読み出します。
のどのグロブにも当てはまらなかったすべてのサーバに対する
設定があります。このセクションで使えるオプションは、ファイルの別の
はそこを通じて通信しなくてはなりません。デフォルトは空で、それは
これはサーバ応答を待つ時間の最大値を秒単位で指定します。
ネットワーク接続に関係した問題を抱えている場合、この
オプションの値を増やしてみてください。デフォルト値は
(ただし、圧縮はネットワーク層のコンパイル時に有効になっていなくては
無効になりますが、これはネットワーク転送のデバッグ時などに使います。
デバック出力を生成するかを指定するものです。デフォルトは
証明書を含むファイルパスのリストをセミコロンで区切ったものになります。
普通は証明書のあるパスを入力するようにユーザにうながします。そのパスを
を自動的に探すことができるようになります。証明書をディスク上に保存する
自分のパスワードを保存するのが嫌でなけれぱ)、この変数に証�