scmpolicy - Japan OpenSolaris Users Group Packages Wiki - Japan OpenSolaris Users Group Packag...

構成管理ポリシー

● バージョン管理ポリシー

バージョン管理には Mercurial を使用します。Mercurial に関する詳細は、以下の情報を適宜参照してください。

• Mercurial の利用 (Mercurial 解説ページ)
• Mercurialではじめる分散構成管理 (gihyo.jp での入門記事)
• 入門Mercurial Linux/Windows対応 (書籍)
• mercurial-ja (Mercurial 日本語 ML)

○ ブランチ運用ポリシー

※ 以下は 2012-03-24 時点での暫定運用ルール

スペック毎ブランチ

各スペックファイル毎の作業は、個別の名前付きブランチで実施します。

スペックを SPECNAME とした場合、対応するブランチの名前は spec_SPECNAME とします。

新規のスペックファイルを追加する場合、以下の手順で当該スペック用のブランチを生成してください (以下は SFECeblib スペックでの例)。

$ hg pull # 共有リポジトリから最新成果の取り込み
$ hg update default # 作業領域を default ブランチの最新で更新

$ hg branch spec_SFEeblib # 以後のコミットのブランチを変更
$ hg tag spec_SFEeblib_base # ブランチ元のリビジョンにタグ付け
                            # (= 当該ブランチの初回コミット)

$ hg push --new-branch # 共有リポジトリへの成果反映

Mercurial の版によっては、hg push の --new-branch オプションが使用できない場合があります。--new-branch 無しで『連携先でヘッドが増える云々』と警告される場合は、hg push -f を実施してください。

但し、間違って hg push -f を実施した場合、『マルチプルヘッド』と呼ばれる状態になってしまう可能性があるので注意してください (履歴管理上致命的な状態ではありませんが、事後対処が必要です)。

既にスペックに対応する名前付きブランチが生成されている場合は、当該ブランチで作業をしてください。

$ hg pull # 共有リポジトリから最新成果の取り込み
$ hg update spec_SFEeblib

現行の作業領域が、対応するブランチ上にある場合は、hg update に対するブランチ名指定を省略しても構いません。この場合は、現行の名前付きブランチにおける最新版で作業領域が更新されます。

$ hg branch # 現行ブランチの表示
spec_SFEeblib
$ hg update

default ブランチ

スペック毎ブランチでの作業がリリース品質に達した場合、各スペックの担当者は、当該リビジョンを default ブランチにマージしてください (以下は SFEeblib の例)。

$ hg pull # 共有リポジトリから最新成果の取り込み
$ hg update default # 作業領域を default ブランチの最新で更新

$ hg merge spec_SFEeblib
※ 衝突 (conflict) が発生した場合は、適宜 hg resolve を実施
$ hg commit -m merge # マージリビジョンのコミット

$ hg push # 共有リポジトリへの成果反映

Mercurial での作業に慣れるまでは、commit 前後の hg parents による親リビジョン確認や、push 前の hg outgoing による反映予定リビジョンの確認などを行うと良いでしょう。

○ コミットログポリシー

コミットログは、以下の形式で記述してください。

• コミットログの記述は、日本語で良いものとする
  • 文字コードに関する設定を忘れないように
• コミット時に記録するユーザ名は『フルネーム <mailaddress>』形式とする
  • username 設定を忘れないように
  • sourceforge に登録したメールアドレスを使用することで、個人毎の統計情報に記録される模様
• 最初の一行は、修正内容に関する概要(summary)を表記する
  • マージ実施リビジョンのコミットログは、『merge』のみで良いものとする (ブランチ運用上、衝突が発生し得ないため、マージの詳細は不要な筈)
  • 各パッケージ(スペック)毎の修正における概要は、『スペック名: 概要』形式とする
    • 固有名詞や、強調の必要な語以外は、小文字(英語表記の場合)
    • 末尾のカンマ／ピリオド／句読点等は不要
    • 障害(issue tracker 管理のもの)と関連する修正は、summary 末尾に『(issueXXXX)』を追加することで、 対応する障害番号 (XXXX) との関連付けを明記する
• 詳細記述が必要な場合、概要行との間に空行を挟んで、詳細を記述
• 詳細記述の内容は、以下のような『なぜ(why)』ベース
  • その変更を実施した理由
  • 複数の候補から、その変更を選択した理由
• 詳細記述に、履歴情報から得られる以下のような情報に関しては書かない
  • 追加／削除したファイル名
  • 何を (or どのように) 変更したか？

記述例(1):

SFEeblib: 初期コンテンツを追加

※ この例の場合、"hg log -v" 等で参照可能な、当該スペック用に追加したファイルの一覧等は、記載する必要がありません。

記述例(1):

SFEeblib: 汎用オブジェクトを生成するためにコンパイルオプションを変更

元の設定で使用していたコンパイルオプション xxxx は、
zzzz 環境固有のオブジェクトを生成する要因となっていたので、
このオプションの代わりに yyyy を使用するように修正。

なお、スペックファイルに記述する changelog は、あくまでスペックファイル (あるいはそこから参照される関連ファイル) 自体に対する変更に関する履歴です。必ずしも Mercurial におけるコミットログと同一になるとは限りませんので、注意してください。

○ タグ運用ポリシー

※ 以下は 2012-03-24 時点での暫定運用ルール

ブランチ元リビジョンへのタグ

スペック毎作業用のブランチを生成する際に、ブランチ元リビジョンに対してタグを付けます。

タグの形式は、スペック毎ブランチの名前を spec_SPECNAME とした場合、spec_SPECNAME_base とします。

● ファイル構成ポリシー

TBD