Subversionとなっているけど、実際には Windows上の TortoiseSVNでの作業メモ。*1
試験的な機能を入れてみるために trunkのコピーを作って作業、採用方向なら trunkに統合、不採用なら破棄。
ただし、trunk自体も平行して作業される可能性有りというシチュエーション。
- branchの作成
まずはチェックアウトされている trunkのコンテキストメニューから「ブランチ/タグの作成」で branchを作成。(branches/test_func)*2 - 作業コピーを branchしたバージョンへ更新
eclipseのワークスペースを作り直すのが面倒なので trunk作業コピーのコンテキストメニューから「切り替え」でパスを trunkから先ほど作成したパスへ切り替える。 - 試験的な機能を実装。
試験的な機能を実装中、平行して trunkにて修正が発生し、その内容は branchに mergeする必要があるシチュエーション。
- branch作業コピーのコンテキストメニューから「マージ」を選択し、マージのタイプは「リビジョンの範囲をマージ」
- マージ元は trunkの URL、マージするリビジョンの範囲は trunkにて発生し、branchに mergeすべきリビジョンを指定。
- マージ実行。*3
- 以上で branchの作業コピーに trunkでの変更が mergeされたので、必要なら commitを行うと。
trunkの特定リビジョンから branchし、作業、trunkにマージというシチュエーション。
- trunkの作業コピーのコンテキストメニューから「ログを表示」を選択し、branchしたいリビジョンを特定。*4
- branchしたいリビジョンのコンテキストメニューから「このリビジョンからブランチ/タグを作成」を選択し、branch先を入力し、branchを実行。
- branchをチェックアウトして、作業&コミット。
- trunkの作業コピーのコンテキストメニューからマージ-リビジョンの範囲をマージを選択し、URLに branchを指定し、テスト&マージ実行。
branchにおける試験的な機能の実装が終わり、実装を採用することにして trunkへ統合。
- trunkのコンテキストメニューにてマージ-ブランチを再統合するを選択。*5
- 元の URLに branchを指定し、テスト&マージ実行。
- trunkに統合して用済みになった branchはリポジトリブラウザから削除してスッキリ。*6
いろいろなケースがあるけど、「branchはサーバ上で、mergeは作業コピーに対して行う」が基本かね。
branch/merge周りを使っていると「細かい粒度でコミットしてゆくのが大事」という事がわかる。
逆を言えば「まとめてコミットしていると cvsのメリットを生かせない」と言うことか。
もう一つ言えるのは「trunkとの関係を考えること」かね。
trunkに属するべきコミットと branchに属するコミットをごっちゃにしない。
これをごっちゃにしてしまうと trunkのバグフィックスとして独立してマージすることが出来なくなる。
粒度は細かければ細かいほどよいというわけではなく、修正内容を考える必要があると。
*1 開発自体コマンドラインで行うなら svnコマンドバシバシでもいいんだけどね。
*2 この時、「作業コピーを新しいブランチ/タグへ切り替える」をチェックしておくと新たにチェックアウトしたり作業コピーを branchに切り替える必要が無くなる。
*3 実行の前にテストを行ってみるのが無難かと。
*4 予めリビジョンがわかっているのなら直接「ブランチ/タグを作成」を選択してコピー元としてリポジトリ内の特定リビジョンを入力してもかまわない。
*5 リビジョンの範囲をマージとの違いは branchしてからの変更を一括してマージするか選択してマージするかの違いなのかしら?
*6 これは単に非表示なるだけで必要になれば復活できる。