svn資料備忘録

元の住所:http://macrochen.iteye.com/blog/353726
Subversion(SVN)は、1つのバージョンの管理ソフトウェアまたはサーバであり、ホスト「ソースコードまたはドキュメント」を提供し、異域同期ファイルの更新ができ、バージョンの違いを記録し、前後のファイルの違いを明確にするプログラムである.
Subversionには標準的なディレクトリ構造があります.例えばプロジェクトはprojで、svnアドレスはsvn://proj/では、スタンダードなsvnレイアウトは

svn://proj/

          |

          +-trunk

          +-branches

          +-tags

これは標準的なレイアウトです.trunkは主に開発カタログで、brancchesはブランチ開発ディレクトリで、tagsは「アーカイブディレクトリ」です.しかし、これらのカタログはどのように使うべきですか?svnは明確な仕様ではなく、もっと多いのはやはりユーザー自身の習慣です.
これらの開発カタログには、一般的な使い方が二つあります.私はもっと多いのはソフトウェア製品の角度から(例えばfreebsd)です.インターネットの開発モデルは全然違っていますから.
第一の方法は、trunkを主な開発ディレクトリとして使用する.一般的に、私達のすべての開発はtrunkに基づいて開発されています.一つのバージョン/releaseの開発が一段落(開発、テスト、ドキュメント、製作インストール、包装など)終わったら、コードは凍結状態にあります.この時は現在凍結されているコードバンクに基づいて、電話するべきです.次のバージョン/段階の開発タスクが開始され、引き続きtrunkで開発されます.この時、前のリリースされたバージョンがいくつかのバグを持っていたり、急な機能要求があったりして、開発中のバージョンが時間要件を満たしていない場合は、前のバージョンで修正する必要があります.発行版に対応するタグに基づいて、相応のブランチを作って開発するべきです.例えば、1.0をリリースしたばかりで、2.0を開発しています.1.0をベースにバグ修正を行います.時間の順に

1.0開発完了、コード凍結

はすでに凍結されたtrunkに基づいて、release 1.0のために打っています.svn://proj/             +trunk/  (freeze)             +brannches/             +tags/                     +同前release_1.0(copy from trunk)

2.0が開発を開始し、trunkはこの時2.0の開発版

である.

は1.0がバグがあることを発見しました.修正が必要です.1.0に基づくディレクトリ構造はsvn://proj/             +trunk/  (dev 2.0)             +brannches/                           +dev_1.0_bugfix(copy from)             +tags/                     +release_1.0(copy from trunk)

は1.0 bugfix branchで1.0 bugfix開発を行い、trunkで2.0開発

を行います.

は1.0 bugfixが完了した後、dev_に基づく.1.0_bugfixのbranchはreleaseなどをします.

必要に応じて、dev_を選択的に行う.1.0_bugfixというブランチmergeはtrunkに戻ります.
これはとても標準的な開発モデルで、多くの会社がこのようなモードで開発しています.trunkは常に開発のメインディレクトリです.
第二の方法は、各releaseのbranchにおいてそれぞれの開発を行い、trunkはリリースのみに使用する.このような開発モードでは、trunkは具体的な開発任務を担っていません.一つのバージョン/段階の開発タスクは開始時に、すでにreleaseのバージョンによって新たな開発分岐をし、この分岐に基づいて開発を行います.やはり上の例を挙げます.この中のタイミング関係は.

1.0開発、dev 1.0のbranchを作成する際のディレクトリ構造svn://proj/             +trunk/  (開発任務を負わない)             +brannches/                           +dev_1.0(copy from trunk)             +tags/

1.0開発が完了し、merge dev 1.0からtrunkまでのディレクトリ構造svn://proj/             +trunk/  (merge from branch devu 1.0)             +brannches/                           +dev_1.0(開発タスク完了、freeze)             +tags/

trunkに基づいて1.0のディレクトリ構造を作成します.svn://proj/             +trunk/  (merge from branch devu 1.0)             +brannches/                           +dev_1.0(開発タスク完了、freeze)             +tags/                     +同前release_1.0(copy from trunk)

1.0開発し、dev 2.0分岐の時のディレクトリ構造を作る.svn://proj/             +trunk/              +brannches/                           +dev_1.0(開発タスク完了、freeze)                           +dev_2.0(2.0の開発を行う)             +tags/                     +同前release_1.0(copy from trunk)

1.0はバグがあり、直接Dev 1.0の分岐上でこの時のディレクトリ構造を修復する.svn://proj/             +trunk/              +brannches/                           +dev_1.0(1.0 bugfix)                           +dev_2.0(2.0の開発を行う)             +tags/                     +同前release_1.0(copy from trunk)

コードmerge

を選択的に行う.
これは実は分散型の開発で、各部分が独立している時に、複数のdevの分岐を開いて開発することができます.例えばdev_2.0_searchとdev_2.0_cacheなど.しかし、このようにmergeを作るのはとてもつらいことです.
ここで注意したいのですが、第六段階で選択的なmergeを行うと、2.0の開発が終わったら一緒にdev_を作ることができます.1.0(bugfix用)とdev_2.0(新バージョン開発用)mergeはtrunkに戻ります.あるいは先にdevを_1.0 mergからdev_まで2.0、テストなどを行ってからmergeはtrunkに戻ります.この二つの方法はそれぞれ長所と短所があります.一番目の方法は比較的に純粋なdev_を得ることができます.2.0の開発分岐、第二の方法はさらに保険になります.テストが必要ですから.
以上ですね.私が言った二つの開発モデルです.具体的にどちらがいいかは決まっていません.ここで大体の長所と短所を説明します.第一の開発モデル(trunkは主に開発、集中中国式):長所:管理が簡単で欠点:開発モジュールが多い時、開発人数/チームが多い時、衝突が発生しやすくて、相手の開発に影響します.すべての変更が相手の変更に触れる可能性があるからです.第二重開発モード(分岐は主な開発、分散式を行います.):長所:それぞれの開発が独立していて、互いに影響しにくいです.短所:管理が複雑で、mergeの時は面倒で、死んでしまいやすいです.
実は、ここには決まった決まりがありません.もっと多いのは2つのモードを組み合わせて使うことです.個人的には第一の方式を採用していますが、場合によっては第二の方法を使用しています.