SubVersion運用ルール(案)

■環境
以下のソフトの導入を前提とする。
	Windows OS
	TortoiseSVN
		http://tortoisesvn.net/
	WinMerge 日本語版
		http://winmerge.org/



■SVN運用概要



リポジトリにはbuild出来ない環境はciしない。
リポジトリは作業環境ではなく、作業の成果を入れるところ。
1work1対応、ici1対応を心掛ける
ci時にコメントは必須


■ルール
work作成
	リポジトリからfileをcheck-out(以降co)し、workを作成する。
	やり方は複数あるのでいくつか紹介。
	リポジトリブラウザから行う方法
		適当なフォルダを右クリック。
		TortoiseSVNのメニューからリポジトリブラウザ選択。
		リポジトリブラウザからcoしたいディレクトリを選択し、右クリックメニューからcoを選択。
		windowが開くのでco先のlocal dirを指定。
		co実施。
	チェックアウト先指定から行う方法。
		co先に指定したいdirを表示。
		右クリックメニューからcoを選択。
		windowが開くのでco元dirとco先dirを確認してco実施。
		※co元dirの右側の『...』ボタン押下でリポジトリブラウザが起動する。
	workは1つの目的に対し1つずつとすること。
	同時に2つの機能を対応している場合は、1対応ごとにworkを作成すること。
	不具合を3つ同時に対応していたらworkは不具合毎に作成すること。
	対応が完了したらworkを削除していけば良い。

リポジトリ更新手順
	check-in(以降ci)は1対応1ciとする。
	※同時に複数対応している場合は作業workを複数用意し、1work1対応とすること。
	build実施
		【確認】work環境でbuildを実行し、Error/Warning共に0件か？
	svn up実施
		SVN更新って書いてあるかな？
		【確認】コンフリクトが発生していないこと
				 ⇒ コンフリクトが発生した場合、コンフリクトの解消を行わないとciできない。
	svn diffの実施�@
		SVNコミットかな？を選択。開いたwindowの下部にチェックイン対象のfile一覧が表示される。
		【確認】一覧にci対象のfileが漏れていないか？
				 ⇒ svn addを忘れるとsvn管理対象とならない。svn add漏れが無いか確認。
				 ⇒ ci対象のdirが間違ってないか？
		【確認】一覧にci対象外のfileが存在しないか？
				 ⇒ 一覧のci対象外fileのcheckを外す。
	svn diffの実施�A
		ci対象のfileをダブルクリックするとWinMergeが起動する。
		ci対象の全てのfileに対しdiffを実行し修正内容が妥当か確認する。
		【確認】差分箇所が自分の意図した箇所のみであるか？
		【確認】想定外の差分が無いか？
		【確認】修正コメントの無い差分は無いか？
		【確認】修正箇所の修正コメントはPjルールに則ったコメントとなっているか？
				 ⇒ 日付、チケット番号、氏名、対応種別
	コミットコメントの記述
		svn log閲覧時簡単にわかるように、対応の概要を記述。
		※チケット駆動開発の場合、チケット番号を先頭に記述する。
	svn ciの実施
		ciに際し、エラーが発生しないこと。
	ciの確認
		ciに利用したworkとは別の場所にworkを作成。
		先ほどciした内容が反映されていることを確認。

fileの追加手順
	svn addの実施
		追加対象のfile/dirを右クリックし、svn addを実行。
		【確認】追加対象のfile/dirのアイコンに『＋』マークが付いていること
	svn ciの実施
		svn add後svn ciを実施。
		リポジトリへ追加することが確実であるfileを作成した場合は、作成と同時にsvn addを実行すること。
		あらかじめsvn addを実行しておけば、svn ciの際、更新対象のfile listに自動で追加されるため、追加忘れを防止できる。

fileの削除手順
	

リポジトリ作成
	base dirとして定番dirを作成する。
	repos
	 ├ trunk
	 │   開発のメインライン。各メンバはtrunkからworkを作成して作業する。
	 ├ tags
	 │   releaseタイミングで任意のbranchから作成し、release情報を格納するdir。
	 │   tagsはrelease情報を格納するためのdirであるため、一度作成したら修正を行ってはならない。
	 │   ※tags以下へciを行ってはならない。
	 └ branches
		  trunkのsnapshot。任意のタイミングでrelease用の(tagを生成する用の)安定版を保持する。
		  releaseは任意のbranchからtagを作り行う。release後に不具合が発生したらtagを作成したbranchを修正する。
		  修正したbranchから再びreleaseする場合は新たにtagを生成する。
		  branches以下へはrelease後の不具合発生時のみ修正を行う。
		  また、branches以下へ行った修正は速やかにtrunkへ反映させること。
	e.g.)
	Release → branch 1.0.x 作成 → tag 1.0.0 作成 → Release1.0.0
	Release 1.0.0で不具合発生 → Release元branch 1.0.x を修正 → 新たなtag 1.0.1作成 → Release1.0.1 → 修正内容をtag 1.0.1 からtrunkへ反映
	新たなRelease → 前回Releaseからtrunkが大幅に変わっているためbranch 1.1.x 作成 → tag 1.1.0 作成 → Release1.1.0
	Release 1.1.0で不具合発生 → Release元branch 1.1.x を修正 → 新たなtag 1.1.1作成 → Release1.1.1 → 修正内容をtag 1.1.1 からtrunkへ反映
	Release 1.1.1で不具合発生 → Release元branch 1.1.x を修正 → 新たなtag 1.1.2作成 → Release1.1.2 → 修正内容をtag 1.1.2 からtrunkへ反映


	※リポジトリ名をreposとする
	http://www.atmarkit.co.jp/fjava/rensai4/devtool02/devtool02_3.html

リリース手順
	branchの作成
	tagの作成
	リリース



■用語集
co
	check-outの略。
ci
	check-inの略。
check-out
	リポジトリからfile等を取得する行為。
check-in
	リポジトリへ作業workの変更内容を反映させる行為。
svn
	SubVersionの略。
repository
	リポジトリ。倉庫、貯蔵庫の意味。file、dir及び、更新履歴を含めた情報のアーカイブ。
work
	リポジトリからcoした作業用領域。各メンバはworkを編集しciすることを繰り返し開発を進めていく。
commit
	check-inの同義語。check-inよりもcommitを好んで使うpjもある。



■SVNコマンド
svn co
svn diff
svn ci
svn up
svn add
svn del



■参考URL
http://pinoki.la.coocan.jp/wiki/?Subversion%2F%B1%BF%CD%D1%CA%FD%CB%A1#pea3a7a4