構成管理/svn運用ルール - 豚吐露＠wiki

---

SubVersion運用ルール(案)

---

■環境
以下の環境を前提とする。
◆Windows OS
◆TortoiseSVN
　　http://tortoisesvn.net/
　　SVNクライアントツール。
◆WinMerge 日本語版
　　http://winmerge.org/
　　diffツール。

---

■SVN運用概要
SVNを用いてVersion管理を行うにあたり、以下のようの運用する。
本件ではSVNを用いて全てのドキュメントのVersion管理を行う。
※全てのドキュメントとは『ソースファイル』『仕様書』など電子fileで管理される全てのものを指す。
全てのドキュメントはSVNのリポジトリに格納される。この時、リポジトリは1projectに対して1リポジトリとする。
リポジトリはバックアップ環境では無いことを認識する。
リポジトリへの操作は、リポジトリが全メンバで共有する環境であることを認識し、他のメンバへの影響を常に考えること。
バイナリファイル(Word、Excelファイル等を含む)を編集する場合、差分のマージができないためロック後編集すること。

【作業手順】
作業は基本的に以下のような手順で行う。

　work作成(trunkからソースをsvn co)
　 ↓
　work修正
　 ↓
　変更箇所が所望の変更のみか確認(svn diff)
　 ↓
　評価
　 ↓
　変更箇所が所望の変更のみか確認(svn diff)
　　ここで修正したら再評価
　 ↓
　修正内容をコミット(svn ci)
　 ↓
　修正logの確認(svn log)
　　コミット漏れが無いか？所望の変更のみコミットされているか？想定外の変更がコミットされていないか？
　　変更とか加えて無い別workをupdateして、buildできるか？とか確認した方が良い。

この作業の際、以下のルールを遵守すること。
◇build出来る環境をciする
◇1対応 1work、1対応 1ciを心がける
　『過去の不要なコメント削除』『インデント変更』『スペース削除・タブ化』『改行変更』『リファクタリング』などを修正対応と同時に行わない。
◇ciの際、コメントに対応内容の概要を記述する
　※Add：機能追加，Imp：機能改善，Fix：バグ修正，Chg：仕様変更，Ref：リファクタリング などのキーワードを用いる方が望ましい。
　※チケット駆動開発の場合、チケット番号を先頭に記述する
◇対応途中の中途半端な状況でciしない
◇無駄にci回数を増やさない(無駄にRevを進ませない。1file毎にCheckInしたりしないように。)

【ユーザ管理】
リポジトリを操作するuser idは各個人毎に作成すること。
LDAPサーバーを保有してあるのであれば、LDAPサーバーと連携させることも可能。

※当該ドキュメントは、Windows OS上からTortoiseSVNを用いてリポジトリ操作を行う場合について書いているが、他環境からであっても、上記ルールを遵守すること。

【リポジトリ構成】
ISMSの観点からリポジトリは1project毎に作成。
これは、業務終了後はリポジトリを破棄しなければならない場合が多く、1つのリポジトリに複数projectの情報を格納してしまうと破棄が難しくなるため。

リポジトリは『trunk』『branches』『tags』の3つのdirをbase dirとして管理する。
それぞれのdirの意味は以下の通り。

repos
 │ 
 ├ trunk
 │   開発のメインライン/ベースライン。基本的に各メンバはtrunkからworkを作成して作業する。
 │   project内で複数のmoduleがある場合、trunk以下でdir分けを行う。
 ├ tags
 │   releaseタイミングで任意のbranchから作成し、release情報を格納するdir。
 │   tagsはrelease情報を格納するためのdirであるため、一度作成したら修正を行ってはならない。
 │   ※tags以下へciを行うのは、tags作成後のrelease情報を作成しciする1回のみ。それ以外のciは認めない。
 └ branches
      trunkのsnapshot。任意のタイミングでrelease用の(tagを生成する用の)安定版を保持する。
      releaseは任意のbranchからtagを作り行う。release後に不具合が発生したらtagを作成したbranchを修正する。
      ※brancheへのciはbug fixなど軽微なもののみとする。
      修正したbranchから再びreleaseする場合は新たにtagを生成する。
      branches以下へはrelease後の不具合発生時のみ修正を行う。
      また、branches以下へ行った修正は速やかにtrunkへ反映させること。
      ※branches以下へのciはtrunkへのciとはルールが異なるため、注意!

project内に複数のmoduleがある場合、base dir以下にmodule毎の固有dirを作成し、管理する。
また、固有dirを作成する場合は『trunk』『branches』『tags』の下にそれぞれ作成すること。
※後で複数のmoduleを管理する可能性がある場合、あらかじめdirを切っておくこと。

e.g.)module calcの場合

repos
 ├ trunk
 │  └ calc
 │      └ calc.c
 ├ tags
 │  └ calc
 │      └ 1.0.x
 │          └ calc.c
 └ branches
     └ calc
         └ 1.0.0
             └ calc.c

【リリース手順】
リリースを行う場合、必ずtagを作成し、tagからリリースモジュールを作成すること。
tagを作成するためには、brancheが必要となるため、必然的にbrancheも作成することとなる。
基本的に作成したtagへの修正ciは、tags作成後のrelease情報を作成しciする1回のみとする。
それ以外のciは認めない。
e.g.)

tags作成(svn cp) → tags co → release情報作成(build結果含む) → release情報ci → release情報co → release

またbrancheへはbag fixなど軽微な修正のみciを許容する。
ただし、brancheへのciルールは、trunkと異なる事に注意！(後述)
brancheへ修正を行った後、再度リリースする場合、新たにtagを作成すること。
また、brancheへ行った修正は速やかにtrunkへ反映させること。
※機能追加など、大きな修正を行う場合はtrunkに対して行ない、新たにbrancheを作成すること。

branchを作成する場合、『MajorVersion』と『MinorVersion』と『x』を『.』でつなぎVersionを表現する。

e.g.)Branche Version定義

1.0.x
││└ PatchVersion: branch作成時は『x』固定とする。
│└─ MinorVersion: branch作成時決定する。0から始まり、前のbranchの『MinorVersion＋1』とする。
└── MajorVersion: Project開始時決定する。

tagを作成する場合、『MajorVersion』と『MinorVersion』と『PatchVersion』を『.』でつなぎVersionを表現する。

e.g.)Tag Version定義

1.0.x
││└ PatchVersion: branch作成時決定する。0から始まり、前のtagの『PatchVersion＋1』とする。
│└─ MinorVersion: tag作成元のbranchのMinorVersionに準じる。
└── MajorVersion: tag作成元のbranchのMajorVersionに準じる。

e.g.)
Release要求 → branches/calc/1.0.x作成 → tags/calc/1.0.0作成 → Release1.0.0
Release1.0.0で不具合発生 → Release元branches/calc/1.0.xを修正 → 新たにtags/calc/1.0.1作成 → Release1.0.1 → 修正内容をtags/calc/1.0.1からtrunkへ反映
新たなRelease要求 → 前回Releaseからtrunkが大幅に変わっているため新たにbranches/calc/1.1.x作成 → tags/calc/1.1.0作成 → Release1.1.0
Release1.1.0で不具合発生 → Release元branches/calc/1.1.xを修正 → 新たにtags/calc/1.1.1作成 → Release1.1.1 → 修正内容をtags/calc/1.1.1からtrunkへ反映
Release1.1.1で不具合発生 → Release元branches/calc/1.1.xを修正 → 新たにtags/calc/1.1.2作成 → Release1.1.2 → 修正内容をtags/calc/1.1.2からtrunkへ反映

【ci】

■リポジトリへの操作

■用語集

■参考URL
http://pinoki.la.coocan.jp/wiki/?Subversion%2F%B1%BF%CD%D1%CA%FD%CB%A1#pea3a7a4
http://usagi-project.org/PUKIWIKI/index.php?%E9%96%8B%E7%99%BA%2FSVN%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA

---

更新日： 2013年01月17日 (木) 10時10分22秒

• 課題： 複数チームでの開発に耐えられるルールか？ -- (s1n) 2010-11-16 20:49:57
• 課題： TrunkへのciとBrancheへのciルールを明確にする必要がある。 -- (s1n) 2010-11-16 20:50:38