プロ ジェクトホーム >> トップページ >> 開発に参加したい方へ >> Subversion Repositoryの使用にあたって
Sourceforge.netにあるSubversion Repositoryを円滑に運営するため，Commitする場合には本ページのルールに従ってください． （注意： まだ草案です)
[例] メインブランチの最新版にアクセスするURL
(userはsourceforge.netのアカウント名)
https://user@svn.sourceforge.net/svnroot/sakura-editor/sakura/trunk/
Note: TortoiseSVNではuser@を指定しなくてもCommitの際にユーザ名とパスワードを聞かれますので，そこで入力できます．
2006.03.25 Commit手順の検討メモ にて検討を加えて書き直しました．
ファイルに変更を加えたときには必ず別の人のReview processを経ること．(ただし，更新履歴についてはこの限りでない)
変更→パッチ作成→レビュー→(必要に応じて作業ブランチを作成)→問題がな ければtrunkへtrunkへのレビュー前のCommitは禁止する．変更した人はCommit前にパッチを公開してレビューを求め，問題がないことが 確認されたら trunkへCommitする．変更が軽微ではなく十分にバグフィックスが行えないと予想される場合，あるパッチを前提としたのパッチ(機能追加や他の人 からのパッチ)が出るような状況，には 一時的な作業ブランチを作成してそこで作業を行う物とする．
基本手順を以下で説明する．
Checkoutした作業領域でファイルの編集を行う．
Commit権限がない場合には機能の実装あるいはバグ修正が完了したら開発者掲示板にて差分ファイルの提供を行う．
パッチの標準形式は unified diffとするが，リビジョンを明確にした変更ファイル一式でもよい．TortoiseSVNを利用している場合には，TortoiseSVNの 「Create Patch...」を使うことを推奨する(他の人が容易に適用できるので)．差分提供時には変更元となるバージョン/リビジョン番号を明確に伝えること．
[例] sakura/trunk#945 : sakura/trunk がブランチ， #945がリビジョン
Create Patchを使った場合には差分ファイルに元のバージョンが組み込まれて適用時にそれが考慮されるので，掲示板やコメントへのリビジョンの記入は必須では ない．しかし，どのようなツールを使うかは不定という前提の元で一応記入するきまりとしておく．
変更箇所には必ず変更理由，日付，変更者をコメントとして記入すること．
パッチの公開場所
保存期間の短いアップローダは使わないこと．
パッチを公開したら別の人のレビューを待つ．不完全であってもそれを明らかにして公開するのはか
まわない．ただし，不完全なパッチにはコメントが付きにくい傾向にある．公開時には変更点の概略，動作確認済みの手順が添えられていることが望ましい．
レビューの完了は適宜掲示板での返信を目安に判断することにする．
主な確認ポイント：
レビューと並行してテスト版バイナリを用いたテストを進めるのも有効である．これについては各人の判断に任せる．
例外： コメントのみの修正の場合には最初からパッチを作成することなくtrunkへCommitしてもかまわない．但し，コンパイルエラーが出ないことを事前に 確認すること．(修正ミスを防ぐため)
次のような理由により，パッチのままでは管理が難しい場合には一時的なPrivate Branchを作成してリポジトリに登録する．
Private Branchでの確認が不要なケース
Private Branchへは機能的に不完全なものや検証が完了していない物も登録してよい．パッチ提供者がCommit権限を持っていない場合には権限を持つ人が代 理で行う．
レビューにより十分に問題が取り除かれたら，Commit権限のある人がそれをリポジトリのtrunkへ登録する．登録が完了したらブ ランチ名とリビジョンを掲示板の議論に対する返答の形で公開する．
Commit時は原則としてレビューが完了していなくてはならないが，実際問題として機
能追加が大き
く，その内容が複雑あるいは高度な場合など適切なReviewerが見つからない場合も考えられる．そのような場合はテスト版での評価が十分に行われれば
Commit可
能とする．(実際そこまで複雑な変更が加えられた場合に実際の動作確認無しでCommitするのは危険であろう．)
trunk/Privateを問わず，Commit操作を行う場合には以下に述べる点に注意すること
SubversionではAtomicな操作はAtomicとして扱うため，2つの変更ファイルがあった場合に同時にCommitする とリビジョン が１つだけ上がるのに対し，それぞれをCommitするとリビジョンが２つ上がる．後者ではリビジョンが無駄に消費されることもさることながら，1つ前の リビジョンとの差を取った場合に完全な変更イメージを取り出せないという問題がある．
１つのまとまった変更に対するCommitは必ず1回で操作すること．その際１つのリビジョンに対して１つのMessageが付くよう にする．
Messageの前に変更の種別が容易にわかるように接頭辞を付けることを推奨する．
Add: 機能追加， Imp: 機能改善，Fix: バグ修正， Chg: 仕様変更
日付，変更者などCommit時に自動的に記録される物は記入しないこと．但し，パッチ作成者がComitした人と異なる場合にはパッ チ作成者への謝辞を記入してもよい．
[例]
Imp: ツールバーを浮動可能に (by ほろんさん)
Fix: ツールバーアイコンがへこんだまま戻らなくなる
Advised by はららさん
名前，内容は架空の物です．
今のところコメントは大部分が英語で記入されている．これはCVSが日本語を正しく扱えない可能性を考えて2バイト文字の使用を避けた 結果であるが， Subversionではコメ ントをUTF-8で管理するので記入した2バイト文字が文字化けすることはない．しかし，ソースコード中の文字コードがShift-JISであるので， ViewVCにおいて両者が1画面に同時に表示されるケースで文字化けが発生する．そのような場合，現在のViewVCでは文字化け無く表示する方法はな く，view画面ではコメントの方が優先されてしまう．
しかし，downloadを選択してソースコードのみを表示させるか，あるいはブラウザでEncodeを明示的に選択することで文字化 けを回避することができるので，内容が確認できないことはない．(ただしdownloadを選択した場合には色分け表示機能は使えない) また，差分表示においてはコメントは表示されないので文字化けは発生しない．
以上のことから，ViewVCの一部の画面においては多少の不具合があるが，コメントの有効性を最大限に使うためにもコメントに2バイ
ト文字を使用できるものとする．使用言語は日本語または英語とする．
ファイルの追加はコード量や機能単位を勘案して各自の判断で行って良い．新規ファイルは作成時に以下のを付与すること．
新規ファイル作成時にファイル名に応じて自動的にプロパティをするよう予め設定しておくことを強く推奨する．設定方法
Note: Rev. #960よりRevision, Idを削除したので，svn:keywordsの設定は不要です．
ファイル中で使用する漢字コードはSHIFT JISとする．(EUC_JP, iso-2022-jp，UTF-8,
Unicode等を使わないこと)
開発対象そのものに必要なファイルを追加することは上に述べたとおり各自の判断で行ってよい．それ以外に開発ドキュメント，設計文書な ども各自の作業エリアに新規ブランチを作成してテキスト，HTML文書及びそれに付随する図表等を追加してもよい．
次のような物はリポジトリに登録してはならない．
ファイル名の変更，ディレクトリ構成の変更は掲示板での議論の結論を待った上でtrunkブランチに対して行う．(基本的には行わな い)
Subversionではリビジョンがリポジトリ全体の状態を表すことから，頻繁にラベルを貼らなくてもブランチ名とリビジョン番号で 特定の状態を一意に指定することが出来る．ラベルが必要となるのは以下のケースに限られる．
それぞれの番号は以下の場合に１つずつカウントアップする．
a: 本質的な変更， b: 特徴的な機能追加， c: 一般的な機能追加，d: 機能変更を伴わない修正
それぞれの公開時にどのレベルで番号を増加させるかはリリース担当者の判断とする．
テスト版バイナリの作成を目的としてリリース以外のラベルを付与する場合には，リリースラベルと同様の体系の番号を付与しつつラベル名 にリリースラベルでない旨の文字列を付加することとする．
既存リリースラベルと同じ番号体系を用いるのは以下の理由による．
βラベルで使われた番号はリリースラベルでは使わない
大きな機能変更の取り込み時に上の番号を１つ増加させる番号を付ける前段階の公開時には１つ下のレベルの番号を大きく上げた番号を付け る．
例： R1.2.5.0
⇒ R1.2.5.90_b(β1回目)
⇒ R1.2.5.91_b (β2回目)
⇒ R1.2.6.0(正式リリース)
trunk以外のお試し機能をいれたバイナリを開発者個人の判断で公開する場合には作業スペース中のtagエリアを使用すること．
CVSのようにファイル毎にリビジョン番号が振られるシステムにおいてはラベルはその組み合わせを規定するための手段であり，開発者間 の連絡のため にもそのようなラベルは必要不可欠である．しかし最初に説明したとおり，Subversionではリビジョン番号とブランチを指定すれば一意にファイル セットを取り出すことが出来るため，開発途中での目印的なラベル添付は不要と考えられる．しかし，大きな意味を持つ特定のリビジョンについて記録を残して おきたい場合には以下の形式でラベルを添付することができる．
ラベルを作成する際に作成の目的がわかるようなコメントを記入すること．
branch/へ作ったコピーの方は今後改変されていくものであるので，基準点としてのBASEラベルを付ける．ただし，付けたラベル は branchごとのサブディレクトリへ配置する．通常はリビジョン番号によって容易に分岐位置を知ることが出来るが，ファイル毎に異なるリビジョンから分 岐している場合(混合リビジョン)も考えられるので，先頭位置の明確化のために
一般的にはブランチを作成する場合にはブランチ基準点の方にベースラベルを付ける．しかしSubversionの場合はブランチとラベ
ルの対応，ブ
ランチ間の関係が束縛されていないため，元のブランチに貼られたラベルであっても他のブランチと同一のサブディレクトリに配置することでサブ側のもののよ
うに見せることが出来る．
trunk以外のブランチに対してラベルを付与する場合には，混乱を避けるためにブランチ毎の個別のディレクトリに格納する．
[管理単位毎のヘッダ]_バージョン とする．既に付けられているラベルのルールを踏襲すること．(基本的にはエディタ本体と同様)
各自のtags/以下へ各自で決めたルールに従って作成して良い．
不要になったラベルは削除することが出来る．レビューなど開発上の目的で付けられたラベルは他のActiveなtagを容易に見つけら れるようにするため不要になり次第速やかに削除するのが望ましい．
ただし，リリース版及び公開β版に対応するラベルは削除してはならない．これは過去の公開履歴を Subversion上で明らかにするために必要である．
公式なブランチ開発は基本的には行わない．運用を進めた上でレビュープロセス専用のブランチが必要と判断されたらそれについては後日検 討する．
リリースはリリース担当者の判断で行う．新たな変更が入り，Commitが完了したら速やかにリリースを行うものとする．
基本的にはtrunkへ入るコードは検証済みの物であるので，trunkの最新リビジョンをリリースする．
検証が不十分と思われる場合，
Private
branchからの大きなマージが入った場合などはβ版としてリリースしてもよい．β版と正式リリースの違いはバイ
ナリ・ソースのリ
リースエリアへの登録時の記載のみである．その後検証が完了して問題がない場合でも同一の内容であれば再度のリリースは行わず，
SourceForge.netのリリース名称の書き換えで対応する．
実際には微細ではある物の変更があると考えられるので，それを取り込んで正式バージョンを与える．
SourceForgeに登録を行わないテスト版を公開した場合には，動作確認後に改めて登録を行う必要がある．