https://sourceforge.net/p/sakura-editor/wiki/CommitProcessReview/Recent changes to CommitProcessReviewenSat, 10 Nov 2012 14:31:28 -0000https://sourceforge.net/p/sakura-editor/wiki/CommitProcessReview/[開発に参加したい方へ](Join)＞[Subversion]＞[リポジトリガイドライン](RepositoryManage)＞[Commit](RepoCommit)＞Commit手順の検討 # Commit手順の検討 # Subversionによるソース管理上方法に関して，基本をパッチベースとするかリポジトリベースとするか迷ったので，両者を比較して最適な方法について考える． ## パッチベースの場合 ## ### 大まかな流れ ### パッチ提供→パッチのままレビュー→問題があればパッチを更新→問題がなくなったらTrunkへCommit ### Pros & Cons ### 利点 * リポジトリに変なコードが混ざらない * ブランチ作成～マージ～廃棄のオーバーヘッドが少ない 問題点 * 複数のパッチが同時に出た場合にCommit時に衝突する．後からCommitする人の負担が大きくなる． * 実質的なCommit回数が減少し，ActiveなProjectと認識されにくくなる． * 1つのパッチに次々と機能が追加されると，1Commit1機能の原則が守れなくなる．(まとめパッチの問題) * Trunkのリビジョンが上がった後にパッチを創るときに対応リビジョンをあげて追従する必要がある． * 問題が長引きそうで元に戻すケースにおいて，途中の履歴がないためにパッチの一部のみ戻すことができない． * 問題が無くなったと思っても，trunkへ入れたとたんに問題が発覚する可能性もあり，そうなるとtrunkを直接変更した場合と同じになってしまう． ## リポジトリベースの場合1 (その都度専用ブランチ) ## パッチ提供→リポジトリへ登録(専用ブランチ)→レビュー→問題があれば再度→問題がなくなったらTrunkへMerge ### Pros & Cons ### 利点 * パッチ組み込み済みのコードをブラウザで確認できる． * 変更したファイルの一覧をブラウザで確認できる． * パッチに対するパッチの作成が容易 問題点 * ブランチ作成～マージ～廃棄のオーバーヘッドがある． * 最終的にtrunkへ組み込まれなかったパッチがブランチのまま宙に浮き，消すに消せずに残骸が増える可能性がある． * 複数のブランチが並行すると，最終的なMergeの負荷が増える． * コメントのみの変更など明らかに機能と無関係な変更の際にブランチの意味が果たしてあるのか * ルール通りにすると，問題発生時に迅速な対応が取れない． * お試しバイナリの複数乱立 ## リポジトリベースの場合2 (trunk) ## パッチ提供→リポジトリへ登録(trunk)→レビュー→問題があれば修正→問題がなくなったらリリース ### Pros & Cons ### 利点 * パッチ組み込み済みのコードをブラウザで確認できる * パッチの衝突が起こりにくい * お試しバイナリの複数乱立が起こらない． 問題点 * 複数の機能が並行して入るとtrunkが安定しない * Updateによって予期しないコードが入り，落ち着いて開発が出来ない． * 本人がいくら軽微な変更だと思っても問題を引き起こすことがある． * 問題が長引きそうで元に戻すケース． ## リポジトリベースの場合3 (trunk + stableブランチ) ## trunkへCommitする点は上と同じだが，リリース用のstableブランチを用意して，リリースはそこから行う．メジャーリリース版は機能追加を最小限にとどめてバグフィックスのみとする場合の一般的なスタイル． パッチ提供→リポジトリへ登録(trunk)→レビュー→問題があれば修正→問題がなくなったら変更をstableブランチへマージ→stableブランチからリリース ### Pros & Cons ### 基本的には前項の性質に加えて， 利点 * trunkが不安定でもstable branchで問題発生時のパッチ作成が可能． 問題点 * リリース前のマージが面倒 * 安定した一部の変更のみをtrunkから取り出してstableへ入れる場合，リビジョンの一部のみマージ済みとなって後からstableへ入れていない箇所がわかりづらくなる可能性がある． * trunkとstableの２つの異なるコードがかけ離れてしまう危険性がある． * trunkのみ修正して，stableへ反映を忘れる可能性がある． * 単にある時点のtrunkのコピーであるならば，stableでないコードが入ってしまう． 問題発生による緊急対応がそんなに頻繁に起こる物ではないので，問題が起こってからパッチ用ブランチを作る方がstableブランチを常に持つよりも作業負荷が低く済む． ## 実際には...(過去の事例) ## 衝突時に単純なマージで解決できないケース * アイコンビットマップ * リソースファイル．リソースヘッダ (リソースIDの重複，最終ID番号) * ShareData.cppの共有データ形式識別番号 軽微な変更と思っていてもポインタの扱いや関数の誤解によって大きな問題を引き起こすことがある． * リリース前に完全なソースが見えない(勝手に軽微な変更を入れるとか)のでリリース後に問題が発覚した． * 急いでバイナリのみ更新した物の，時間が無くてソースコードのパッチまでは出せなかった． * リソースファイルを変更するパッチが複数出てきたため，まとめパッチが作成された． * 同じところから複数に分岐した物を１つに集めるのは結構しんどい novice123Sat, 10 Nov 2012 14:31:28 -0000https://sourceforge.net16a6d02cd85e8773d615edccd2581370975aa9d9