タグ

別のバージョン管理の概念に、タグがあります。 タグはある時点でのプロジェクトの「スナップショット」です。Subversion ではこのアイディアは既にさまざまな場所にあるように見えます。それぞれ のリポジトリリビジョンはまさにそれです—つまり、それはコミット直後の ファイルシステムのスナップショットです。

しかし、人はしばしばタグに対して人間になじみのある名前を付けたいと 思うものです。たとえば、「release-1.0」のような。また、ファイルシステム のもっと小さなサブディレクトリのスナップショットがほしいこともあります。 結局、あるソフトの一部のrelease-1.0 がリビジョン4822の特定のサブディレクトリ であることを思い出すのは簡単ではありません。

簡単なタグの作成

もう一度、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.

この例では/calc/tags ディレクトリが既に 存在しているものとしています。(もしそうでないなら、svn mkdir を見てください)。 コピー完了後、新しい release-1.0 ディレクトリは、あなたがコピーした 時点のHEADリビジョンにおいてプロジェクトがどう見えていたかをスナップ ショットとして永遠に残すものです。 もちろん、どのリビジョンをコピーするかについてもっと正確でありたいと 思うかも知れません。他の人があなたが見ていないときにプロジェクトに 対して変更点をコミットしていたかも知れませんから。もしあなたが /calc/trunk のリビジョン350が自分のほしいスナップ ショットだと知っていればsvn copy コマンドに -r 350を指定することができます。

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

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

複雑なタグの作成

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

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

さあスナップショットをとります。一つのURLを作業していない別の 場所にコピーします。この場合、やりたいことは特定の作業コピー状態 で、それをリポジトリに格納したいのです。幸運なことに svn copy は実際には四種類の異なる使い方が あります。(第9章を読んでください)その中には作業コピーツリー をリポジトリにコピーする、というのもあります:

$ ls
my-working-copy/

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

Committed revision 352.

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

別のユーザはこの機能の面白い使い方を見つけました。 ときどき、自分の作業コピーにローカルな修正をした ブランチがあるが、それを他のメンバーに見せたいというような 状況です。svn diff を使ってパッチファイル (それはツリーの変更、シンボリックリンクの変更、あるいは属性の変更を取得できません) を送るかわりに、svn copyを使って、作業コピーをリポジトリの プライベートな領域に「アップロード」します。他のメンバーは 作業コピーを新しくチェックアウトするか、svn merge を使って変更点のみを受け取ることができます。