豚吐露@wiki
svn運用ルール
最終更新:
Bot(ページ名リンク)
-
view
SubVersion運用ルール(案)
■環境
以下の環境を前提とする。
◆Windows OS
◆TortoiseSVN
http://tortoisesvn.net/
SVNクライアントツール。
◆WinMerge 日本語版
http://winmerge.org/
diffツール。
以下の環境を前提とする。
◆Windows OS
◆TortoiseSVN
http://tortoisesvn.net/
SVNクライアントツール。
◆WinMerge 日本語版
http://winmerge.org/
diffツール。
■SVN運用概要
SVNを用いてVersion管理を行うにあたり、以下のようの運用する。
本件ではSVNを用いて全てのドキュメントのVersion管理を行う。
※全てのドキュメントとは『ソースファイル』『仕様書』など電子fileで管理される全てのものを指す。
全てのドキュメントはSVNのリポジトリに格納される。この時、リポジトリは1projectに対して1リポジトリとする。
リポジトリはバックアップ環境では無いことを認識する。
リポジトリへの操作は、リポジトリが全メンバで共有する環境であることを認識し、他のメンバへの影響を常に考えること。
バイナリファイル(Word、Excelファイル等を含む)を編集する場合、差分のマージができないためロック後編集すること。
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できるか?とか確認した方が良い。
↓
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したりしないように。)
◇build出来る環境をciする
◇1対応 1work、1対応 1ciを心がける
『過去の不要なコメント削除』『インデント変更』『スペース削除・タブ化』『改行変更』『リファクタリング』などを修正対応と同時に行わない。
◇ciの際、コメントに対応内容の概要を記述する
※Add:機能追加,Imp:機能改善,Fix:バグ修正,Chg:仕様変更,Ref:リファクタリング などのキーワードを用いる方が望ましい。
※チケット駆動開発の場合、チケット番号を先頭に記述する
◇対応途中の中途半端な状況でciしない
◇無駄にci回数を増やさない(無駄にRevを進ませない。1file毎にCheckInしたりしないように。)
※当該ドキュメントは、Windows OS上からTortoiseSVNを用いてリポジトリ操作を行う場合について書いているが、他環境からであっても、上記ルールを遵守すること。
【リポジトリ構成】
ISMSの観点からリポジトリは1project毎に作成。
これは、業務終了後はリポジトリを破棄しなければならない場合が多く、1つのリポジトリに複数projectの情報を格納してしまうと破棄が難しくなるため。
ISMSの観点からリポジトリは1project毎に作成。
これは、業務終了後はリポジトリを破棄しなければならない場合が多く、1つのリポジトリに複数projectの情報を格納してしまうと破棄が難しくなるため。
リポジトリは『trunk』『branches』『tags』の3つのdirをbase dirとして管理する。
それぞれの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を切っておくこと。
また、固有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.)
リリースを行う場合、必ず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を作成すること。
ただし、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へ反映
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
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