もう一度、svn copy の助けを借ります。 もしHEADリビジョンの/calc/trunk のスナップ ショットを作りたいときには、そのコピーをとればいいのでした:

$ svn copy http://svn.example.com/repos/calc/trunk ¥
           http://svn.example.com/repos/calc/tags/release-1.0 ¥
      -m "Tagging the 1.0 release of the 'calc' project."

Committed revision 351.

This example assumes that a /calc/tags directory already exists. (If it doesn't, you can create it using svn mkdir.) After the copy completes, the new release-1.0 directory is forever a snapshot of how the project looked in the HEAD revision at the time you made the copy. Of course you might want to be more precise about exactly which revision you copy, in case somebody else may have committed changes to the project when you weren't looking. So if you know that revision 350 of /calc/trunk is exactly the snapshot you want, you can specify it by passing -r 350 to the svn copy command.

でもちょっと待ってください: このタグ作成の手続きはブランチを作る ために使ってきた手続きと同じじゃないの? 実はその通りです。 Subversion ではタグとブランチには違いはありません。両方とも コピーで作られた普通のディレクトリです。ちょうどブランチのように コピーされたディレクトリが「タグ」であるといわれるのは、単に 人間がそうやって扱うことに決めたから、ただ それだけです。そのディレクトリに誰もコミットしない限り、それは 永遠にスナップショットとして残ります。もし誰かがそれにコミット し始めると、それはブランチになります。

もしリポジトリを管理しているなら、タグを管理するには二通りの 方法があります。最初のアプローチは、「ユーザ任せ」です。 プロジェクトポリシーとして、あなたのタグを置く場所を決め、 すべてのユーザにそのディレクトリをコピーするときにはどうやって扱うか を知らせます。(つまり、みんながそこにコミットしないように約束します) 二番目のやり方はもっとガチガチです。Subversionが提供するアクセス 制御スクリプトのどれかを使って、タグ領域には新しいコピーを 作ることだけができて、それ以外の操作を禁止します。 (第6章を参照してください。) ガチガチ方式は、普通は不要です。もしユーザが間違ってタグディレクトリ に自分の変更をコミットしてしまったら、前の章で説明した方法で その変更を取り消せばいいのですから。結局、Subversionはバージョン 管理システムなのです。

ときどき、一つのリビジョンの一つのディレクトリよりも もっと複雑な「スナップショット」がほしいことがあります。

たとえば、プロジェクトが私たちのcalc よりも もっと大きいとします。たくさんのサブディレクトリともっとたくさん のファイルがあるとします。仕事の過程で、特定の機能とバグ修正を含んだ 作業コピーが必要になったと判断します。特定のリビジョンの 以前のファイルとディレクトリを選んで(svn update -r liberally を使って), これを作ることもできますし、 特定のブランチにファイルとディレクトリをスイッチすることによっても できます。 (svn switchを使う) これをやると、あなたと作業コピーは別々のリビジョンからなる別々の リポジトリ位置のつぎはぎになります。しかしテスト後、自分がまさに必要と している組み合わせであることがわかりました。

Time to make a snapshot. Copying one URL to another won't work here. In this case, you want to make a snapshot of your exact working copy arrangement and store it in the repository. Luckily, svn copy actually has four different uses (which you can read about in 第9章), including the ability to copy a working-copy tree to the repository:

$ ls
my-working-copy/

$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag

Committed revision 352.

これでリポジトリに新しいディレクトリができました。 /calc/tags/mytagです。これはあなたの作業コピー の正確なスナップショットです— 混合リビジョン、URLそして すべてです。

Other users have found interesting uses for this feature. Sometimes there are situations where you have a bunch of local changes made to your working copy, and you'd like a collaborator to see them. Instead of running svn diff and sending a patch file (which won't capture tree changes, symlink changes or changes in properties), you can instead use svn copy to 「upload」 your working copy to a private area of the repository. Your collaborator can then either check out a verbatim copy of your working copy, or use svn merge to receive your exact changes.

While this is a nice method for uploading a quick snapshot of your working copy, note that this is not a good way to initially create a branch. Branch creation should be an event onto itself, and this method conflates the creation of a branch with extra changes to files, all within a single revision. This makes it very difficult (later on) to identify a single revision number as a branch point.

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/newbranch
Committed revision 353.

$ svn switch http://svn.example.com/repos/calc/branches/newbranch
At revision 353.