S-JIS[2008-12-28/2011-12-19] 変更履歴
Subversion(SVN)の考え方(CVSとの違い)のメモです。
色んな人がCVSとの比較を行っているけれど、自分で考え方を整理する為に改めてメモ。
項目 | 考察 | ||
---|---|---|---|
CVS | SVN | ||
バージョンの単位 | ファイル単位でバージョンが上がっていく。 | リポジトリー(コミット)単位でバージョン(リビジョン番号)が上がっていく。 1ファイルでもコミットされれば、全体のバージョンが上がる。 1つのリポジトリー内で複数のプロジェクトを運用しようとしても、全プロジェクトを通して共通のバージョン番号になる。 |
|
バージョン番号 | 1.1や1.0.0.1という感じ。(複数の数値の組) | 1とか2とか。(1つの整数) | |
管理種類 | 基本 | 基本的にテキストファイルを扱う。 | 基本的にバイナリーファイルとして扱う。 |
テキスト ファイル |
リポジトリーから取得する際に、クライアントの環境に合わせて自動的に改行コードが変換される。 kオプションを指定することでキーワード置換を行う。 |
テキストファイルでもバイナリーファイルと同じく(基本的に)変換を行わず、そのまま保持される。 改行コードは、変換する設定を行わないと変換されない。 キーワード置換もデフォルトでは行われない。 →バイナリファイルと変換 |
|
バイナリ ファイル |
バイナリーファイルも管理できるが、差分をとれず、常に全内容を保持。 | バイナリーファイルも差分管理される。 | |
ファイル | ファイルの移動はバージョン管理の対象外(追加+削除の扱い)。[2009-01-06] | ファイルの移動・改名もバージョン管理の対象。[2009-01-06] (内実は追加+削除の扱い) |
|
ディレクトリー | ディレクトリーの追加・削除・移動はバージョン管理の対象外。 | ディレクトリーもバージョン管理の対象。 | |
その他 | 属性(プロパティー)の変更も管理対象。 | ||
コミット方式 | 複数のファイルをコミットする場合、コミット対象ファイルを順次コミットしていく。 途中でコミットに失敗した場合、あるファイルはコミットされ、残りはコミットされていないという状態になる。 |
コミットは一元的(アトミック)に行われる。 (この為、リポジトリーはDBを使って実装されている) |
|
リポジトリーの構造 | リポジトリーの下にプロジェクト(モジュール)一覧が並ぶ。 モジュールの下にディレクトリー・ファイルが存在する。 |
リポジトリーの下は大きな1つのツリー構造をしており、その中に区別は無い。 (SVNにとってはモジュールといった概念が無い) 管理者・プログラマーが各ディレクトリーを目的別に扱う。 |
|
モジュール単位でチェックアウトする。 | ツリー内のどの部分のディレクトリーでも自由にチェックアウトできる。 | ||
リポジトリーの実体は、モジュール毎のディレクトリーとなっている。 外部からそれを消せば、不要なモジュールを削除することが出来る。 |
リポジトリーの実体にはDBを使用している為、外部からの修正は困難。 | ||
作業ディレクトリーの構造 | 各ワークディレクトリーの下に「CVS」というディレクトリーがある。[2009-01-06] | 各ワークディレクトリーの下に「.svn」というディレクトリーがある。[2009-01-06] SVN1.7以降はルートのみに変わったらしい。[2011-12-19] |
|
ブランチ | ある時点からブランチを起こす。 ファイル群に対し、ブランチという特殊なタグを付けるイメージ。 |
ある時点のファイル群をブランチという名前でコピーしておくイメージ。 つまり、ディレクトリーをまるごと全部コピーしたように見える。 (リポジトリー内の仕組みとしては、実際に全コピーを作っているわけではない) |
|
トランク(幹)とブランチ(枝)を別々に変更していくことが出来る。 | トランク(主系)とブランチを別々に変更していくことが出来る。 | ||
作成はcvs rtag -b マージはcvs update -j |
作成はsvn copy マージはsvn merge |
||
タグ | ある時点のファイル群に対し、タグ名を付けることが出来る。 cvs tag、cvs rtag |
ある時点のファイル群をタグ名のディレクトリーに全コピーしておくイメージ。 (リポジトリー内の仕組みとしては、実際に全コピーを作っているわけではない) svn copy しかし作り方はブランチと変わらないので、タグとして作っても変更できてしまうのでは…? |
|
タグ一覧を取得する方法は無い。 (昔から存在しているファイルに付けられたタグを見ることで代用) |
svnlook treeで、タグを管理しているディレクトリー内を見ればよい。 | ||
無視するファイル | .cvsignoreファイル内にCVS管理しないファイル・ディレクトリー名を記述する。 | 属性svn:ignore にSVN管理しないファイル・ディレクトリー名を設定する。 |
|
変更の確認 | cvs update (自分の作業ディレクトリー上の変更有無が見られるが、リポジトリーから最新版も取り込まれる) |
svn status (確認はupdateでなくstatusで行うべきだと、やたら強調されている^^;) |
|
プロパティー(属性) | なし。 | ファイル・ディレクトリー・リビジョンに対して、プロパティー(属性)として値を持たせることが出来る。 svn prop系、svnlook prop系 ファイル・ディレクトリーの属性もバージョン管理されるので、変更したらコミットが必要。 リビジョンの属性はリポジトリー内の値が直接変更される。(バージョン管理はされず、最新状態しか持たない) →Subversionの属性 |
|
ログメッセージ | コミットする際に付けるメッセージ。 (後から修正(訂正)する方法は提供されていない) |
コミットする際に付けるメッセージ。 リポジトリーを直接変更する(コミット以外の)コマンドでもメッセージを付ける。 メッセージは属性 svn:log として保持されている為、後から修正(訂正)することが出来る! |
リポジトリーはsvnadmin createコマンドで作成する。
このとき、DBとしてBerkeley DBとFSFS(フラットファイル)のどちらかを選ぶことが出来る。
昔はBerkeley DBがデフォルトだった(Berkeley DBしか無かった)が、今はFSFSがデフォルト。
既存のリポジトリーがどちらのDBを使っているかは、「C:/svn/db/fs-type」というファイルの中を見れば分かる。
SVNのリポジトリーは(CVSと違ってモジュール単位でのインポートではなく)、大きなひとつのディレクトリーツリー内に適宜ディレクトリーを追加していくような形で扱う。
また、ブランチやタグも(CVSのようなモジュール内にタグ名(ラベル)を付ける方式ではなく)、ツリー内にブランチ用・タグ用のディレクトリーを作るようなイメージになる。
したがって、ブランチやタグを扱う場合は、そのディレクトリーを作る必要がある。
複数のプロジェクト(CVSで言うところのモジュール)をも扱いたいのであれば、以下の二通りのディレクトリー構成が考えられる。
(SVNとしては左側がお勧めらしい?)
|
|
ところで、リビジョン番号はリポジトリー内で共通となる。プロジェクト毎に別々に採番されるわけではない。
(そもそもSVNにとってはどれも単なるディレクトリーであり、プロジェクトだのトランクだのという区別はしてくれない)
したがって、バージョン1の時にProject1のファイルをコミットしてバージョン2になったとして、次にProject2のファイルをコミットすると、バージョン3になる。
プロジェクト間でリビジョン番号が共有されるのが嫌なのであれば、リポジトリー自体をプロジェクト単位で作るしか無さそう。
→svnserveはひとつで、複数のリポジトリーを作る構成