日記(2007年)

• svnbook日本語訳のPDF版を作成してみました

チビ達が寝た後読み始め、最初から第3章まで読破。 かなりおもしろかった。

最初は、全ファイルロックすることを前提で(2.3.2 ロック・修正・ロック解除の解法)、どのようにすれば運用できるか？ということの解決策を見出す為に読み始めた。 しかし、ここまで読んで既に、全ファイルロックの必要は無いのでは、と思い始めた。

目からウロコ、だったのは、「commit はファイル単位ではない。よって、一度のcommitの範囲が明確になる」 という点であった。 以下、各項目を読みながら思ったことを記述する。

1.8 クイックスタート

プロジェクトは「/branches /tags /trunk という名前の三つの最上位ディレクトリを含む必要がある」

説明は第4章にあるようだが、これだけで、やろうとしていることの想像はつく。要は/trunk にその名の通り幹のファイルを入れ、/branches でブランチ、/tags でタグを管理するのだろう(そのまんまだ)。 CVSのように個々のファイルにタグを付けてタグ、ブランチを管理するのではなく、ディレクトリで管理する方が、わかり易く処理も速いだろう。

2.3.3 コピー・修正・マージの解法

3.6.4 衝突の解消(他の人の変更点のマージ)

Conflictがある限りCommitはできず、それを作業者が手作業で解消した後にCommitする。その作業をやり易くするのがSubversionの考え方だ。 svn update を実行したとき、Conflictがあれば、そのファイルにConflictしている内容を記述した上で、下記のファイルをワークに自動的に生成する。

• filename.mine 作業した内容
• filename.rOLDREV 編集の直前にしたチェックアウト時点での内容
• filename.rNEWREV リポジトリの最新

そして、svn resolved すると上記ファイルは消える。

仮に、「ロック・修正(コミット)・ロック解除」でのやり方は、下記のようなものである。 ロックされていたら全く作業しないか、又は全く作業しないのは現実的では無いので、hoge.c をローカルで作業する。 Aさん(他人)がhoge.cをロックしていたら、Aさんがcommitされた時点で、

• 自分の作業ファイルを一旦hoge.c.bakにコピーし、
• 最新の hoge.c をcheck out (ロック)し、
• hoge.c.bak の内容を hoge.c に反映させる。

という作業を行うことになる。 ロックされていたら全く作業しないので無い限り、上記のような作業が発生することを考えると、ロックが無くても上記と同じ作業を行うことはできるということがわかった。 また、上記のように hoge.c.mine hoge.c.rOLDREV hoge.c.rNEWREV が自動生成されることで作業はとてもしやすいだろう。

5.5.1 リポジトリレイアウトの選択

「Subversion はリポジトリグローバルなリビジョン番号を使っていることに注意してください。」 つまり、1つのリポジトリに、複数のプロジェクトを置く場合、あるプロジェクトのリビジョン番号が上がると、他のプロジェクトのリビジョン番号も上がることになる。