世の中的にはGitだとかMercurialだとかの分散バージョン管理システムが流行っているのでしょうが、
私の業務界隈では以前としてSubversionが現役なわけで、
掲題の問題で悩んだ挙句に解決したっぽいので、記録しておきますよ。

＜前提＞

今回のプロジェクトでは、
既にサービスインしているシステムがtrunk下に置かれていて、追加開発プロジェクトがbranches下に複数存在します。
不具合対応などの緊急性のあるものはtrunkで修正し、その修正は都度各branchesにマージされます。
先日、追加開発プロジェクトのうちの一つがめでたくリリースされました。

＜本題＞

さて、じゃあリリースもできたし、リポジトリを整理しようかとなった際に、
基本的にはtrunk側のソースは触ってないし、ブランチの修正ログは引き継ぎたいし、ていう状況下での「あるべきマージの仕方」がよく分かんない。

で、調べてみると、そんな時は svn merge –reintegrate を使えとか言ってるサイトもあったんですが、よく読むと注意書きに**「–reintegrateオプションを使うマージは一つのブランチにつき一回のみ」**とか**「一度 –reintegrate オプションを指定したブランチはそれ以降使い物にならない」**とか書いてあってめっちゃ怖い。

svn help mergeで読んでみると、

–reintegrate : merge a branch back into its parent branch

こんな感じで書いてある。うーん、確かにそれっぽいっちゃそれっぽい内容。

でも「一回きり」だと失敗したときショックだなー
そもそもmergeだとマージ時にログは残せるけどそれまでのコミットログが残せないよなー

とか考えているときに、こんな記事をみつけました。

Trunk(1) --> Trunk(2) --> Trunk(5) --> ×          +--> new Trunk(7)
  \                             \                 |
  fork                         merge             ???
    \                             \               |
     +--> Branch(3) --> Branch(4) --> Branch(6) --+

おお！私がやりたいことはまさにこれ。

そして回答に書いてある svn move がどんぴしゃ。ホントStack Overflowさまさま。

たとえば、Aプロジェクトのリポジトリが

こんな感じだとしたら、

$ svn move http://hoge/svn/A/trunk http://hoge/svn/A/tags/backup
$ svn move http://hoge/svn/A/branches/N http://hoge/svn/A/trunk

という感じでtrunkを一旦tagsとかに退避して（移動先が空じゃないとエラーになるので）、
trunkにしたいbranchesのNブランチをtrunkに移動すればよい、と。

これなら単なる移動なので履歴はNブランチのものがそのまま読める。

やったねー！