« Slony-I まとめ | Home | イギリス生活 »

Subversionのmerge

http://d.hatena.ne.jp/higepon/20071202/1196576743

「いまさら聞けない」的な疑問の一つだったんだけど、やっぱりSubversionのmergeって自分でmergeしたリビジョンを覚えてないといけないのね。いや、確かにドキュメントにもそう書いてあるんだけど「そんな馬鹿な」と思ってた。

普通はどうしてるんだろう。サードパーティっぽいツールもあるけど、どうも使いづらいんだよなあ。

自分は、commitログにリビジョンを書いておくなんてマメなことはできないので、mergeのwrapperコマンド作ってしのいでいる。 そのスクリプトは、どのブランチのどのリビジョンとmergeしたか、という情報を持つファイルを作成して、そのファイル自体も一緒にcommitする。次回のmergeでは、そのファイルを参照して前回commitしたリビジョンからmergeするだけ。

こんな感じ：

$ cd ＜mergeしたいレポジトリの作業ディレクトリ＞
$ sh ~/bin/merge_branch ＜branchの名前＞
  これで、.current_rev_＜branchの名前＞というファイルができて、その中にmergeが完了したリビジョンの履歴が残る。初回は、--stop-on-copyでどこからmergeすれば良いか取得
$ svn commit

自分しかmergeしない場合（または同じレポジトリいじる人に、このスクリプトを使うことを強要できる場合）でしか使えないけど、 これを使い始めてから数年mergeで苦労したことないので取り合えず満足はしている。 もちろんSubversionでちゃんとサポートしてくれると嬉しい。

糞スクリプトだけど取り合えずおいておこう。

他に、Subversionで嫌いなのは、ファイル名の変更とか、ファイルの移動のサポートがいい加減、というかもうちょっと賢くてもいいんじゃないの、ってところ。 Subversionのファイルの移動はただ「commitログを引き継ぐ」というだけで、ファイル自体は別のものとなってしまうので、mergeとかしたときにファイル名が変わってるとうまくいかない。

後、svkでできるようなことがsubversion自体でできればいいのに、と思う。localでcommitしたいことあるからなあ。レポジトリを汚したくないとかそういう理由ではなくて、単純にネットワークがない、とかの場合に。分散SCM使え、は禁止。

それと、サーバサイドでautopropできないのも嫌い。「いつか実装する」的なのは何度か見てるんだけど。

どれもこれもたいして難しそうじゃないのになんで実装されないんだろうか。

その他は特に問題ないかなあ。やっぱりWindowsクライアントがあるのは大きいし、hook関係でも色々しちゃってるので（コーディング規約のチェックとか）、そう簡単には乗り換えられない感じ。