Subversion はツリーの構造を追いかけるのであって、それはファイルの内容 だけにはとどまりません。これはCVSを置き換えるために Subversionが書かれた 大きな理由の一つです。
CVSユーザとしてのあなたに、これが何を意味するかをここで挙げておきます:
svn add と svn delete コマンドは ファイルだけではなく、ディレクトリに対しても動作します。 svn copy とsvn moveもそうです。 しかし、これらのコマンドは、リポジトリに対して直接の変更を加える ことはありません。そのかわりに、作業アイテムは単に、追加または削除 の「予告」 を受けるだけです。svn commit が実行されるまで、リポジトリはいっさい変更されません。
ディレクトリはもう、ただの入れ物ではありません。それはファイルと
同じように、リビジョン番号を持っています。(あるいはもっと適切には
「リビジョン 5 の中にある、ディレクトリfoo/
」という言い方が正しいのですが)。
最後の点についてもっと説明します。ディレクトリのバージョン管理は 難しい問題です。それは、混合リビジョンの作業コピーを認めたいので、 このモデルを乱用することに対する制限が必要になります。
理論的な見地からすると、
「
ディレクトリ fooの
リビジョン 5
」
というのは、ディレクトリエントリと属性の、ある特定のあつまりを
意味します。fooのファイルを追加したり削除
し、コミットしたとします。リビジョン 5 のfoo
がまだあるといえば嘘になります。しかし、コミット後に
fooのリビジョン番号を上げたとすれば、
これもやはり嘘になります。まだ更新してはいないので、
foo に、まだ受け取っていないほかの人の変更が
加えられたかも知れないからです。
Subversion はこの問題を、.svnの領域に
コミットされた追加と削除を静かに記録することで取り扱います。
svn updateを実行すると、
すべての変更点がリポジトリに反映され
ディレクトリの新しいリビジョン番号は正しく設定されます。
そのため、更新後においてだけ、ディレクトリの「完全な」
リビジョンを手にしている、と安全に言うことができます。
ほとんどの場合、作業コピーは「不完全な」 ディレクトリ
リビジョンを含んでいます。
同様にして、もしディレクトリ上の属性変更をコミットしようとした ときに問題が起こります。普通、コミットは作業ディレクトリの ローカルなリビジョン番号を上げます。しかし、やはり、それは 嘘です。というのは、更新がかかっていないことにより、ディレクトリ がまだ受け取っていない追加や削除があるかも知れないからです。 それで、ディレクトリが最新の状態になければ、ディレクトリ上の 属性変更をコミットすることはできません。
ディレクトリのバージョン管理の制限についての詳細は、 混合リビジョン状態の作業コピー項を見てください。