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を実行すると、 すべての変更点がリポジトリに反映され ディレクトリの新しいリビジョン番号は正しく設定されます。 そのため、更新後においてだけ、ディレクトリの「完全な」 リビジョンを手にしている、と安全に言うことができます。 ほとんどの場合、作業コピーは「不完全な」 ディレクトリ リビジョンを含んでいます。
同様にして、もしディレクトリ上の属性変更をコミットしようとした ときに問題が起こります。普通、コミットは作業ディレクトリの ローカルなリビジョン番号を上げます。しかし、やはり、それは 嘘です。というのは、更新がかかっていないことにより、ディレクトリ がまだ受け取っていない追加や削除があるかも知れないからです。 それで、ディレクトリが最新の状態になければ、ディレクトリ上の 属性変更をコミットすることはできません。
ディレクトリのバージョン管理の制限についての詳細は、 混合リビジョン状態の作業コピー項を見てください。