SI業界人は要チェック！！Subversionでのベンダブランチの運用手順。

svn

外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。

レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。

参考：http://hide.xsv.info/tips/svnmanual/merge3/

今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。

レポジトリの構成（最初）

  • root
    • my_project
      • branches
      • tags
      • trunk
    • vendor
      • current

ベンダから提供されたライブラリ(バージョン1.00)をvendor/currentにコミット

  • root
    • my_project
      • branches
      • tags
      • trunk
    • vendor
      • current (ここに展開し、コミット)

vendor/currentのバージョン番号をtag

  • root
    • my_project
      • branches
      • tags
      • trunk
    • vendor
      • current
      • 1.00 (<= vendor/current)

vendor/1.00を自分のプロジェクトのtrunk下に分岐

  • root
    • my_project
      • branches
      • tags
      • trunk
        • lib (<= vendor/1.00)
    • vendor
      • current
      • 1.00

自分のプロジェクト内でlibを改造

  • root
    • my_project
      • branches
      • tags
      • trunk
        • lib (改造してコミット)
    • vendor
      • current
      • 1.00

ベンダからバージョン1.01を受領、vendor/currentに上書きしてコミット

  • root
    • my_project
      • branches
      • tags
      • trunk
        • lib
    • vendor
      • current (上書きしてコミット)
      • 1.00

ファイルの削除、ファイルの移動、フォルダ構成の変更がある場合は、単純に上書きはできないので注意。

vendor/currentを1.01としてtag

  • root
    • my_project
      • branches
      • tags
      • trunk
        • lib
    • vendor
      • current
      • 1.00
      • 1.01 (<= vendor/current)

作業フォルダをtrunk/libとして、merge from 1.00 to 1.01.

で、競合など解消。
TortoiseSVNでいうと、チェックアウトしたtrunk/libで右クリックからマージを選択、3つのラジオボタンの一番下のマージを選択する。
ちなみに、ここで「trunk/lib上で merge from trunk/lib to 1.01」と指示するなどして、時間を浪費しました。

何が困ったかというと

  • ベンダさんがフォルダ構成を変えて下さるので、面倒。
    • 今回はもう諦めて、1.00の構成をあらかじめ1.01の構成に合わせておいて、1.00のcurrentをコミットしてある。そこからtrunk/libを派生させて自社改造分を当てて…となるので、旧レポジトリの変更履歴は失われるわけだけど、整理するなら今のうちだ。
      • もちろん、旧レポジトリには、そのまましばらく生きてもらう。
  • 自社改造の中で「やっぱり改造しない」となったファイルについて、本来は改造前リビジョンとマージさせるべきだが、ファイルを元に戻してコミットしただけのものがあり、無駄にコンフリクトが発生した。
    • テキストファイルなら機械的に「おなじだよ」って判定しやすいけど、Excelファイルなので、コンフリクトは手動で解消するしかない。やつらは、カーソルの位置とか記憶しやがる。
  • この辺を容量が1GB前後で試していたので、SVNサーバに使っているマシンに負荷がかかった。
    • チェックアウトに8分とか余裕。
    • 自分の開発機の方が強かったので、自分のところにSVNサーバを立ててレポジトリフォルダをコピーし、作業した。
    • SVNサーバ、ある程度強くないと敵わん。
    • 分散型に移行すべきだなぁ…。

Excelファイルの競合解消は？

健全なSIerの皆さんは、Excelファイルをレポジトリに突っ込んでると思いますので、競合は基本的に手動で解消することになると思います。
競合したファイルは3つのファイルができる：

  • hoge.xls : trunk/libにあった、作業コピー上のファイル。
  • hoge.xls.merge-left.r13 : vendor/1.00にあった、前のバージョンのファイル
  • hoge.xls.merge-right.r13 : vendor/1.01にあった、更新を取り込みたいバージョンのファイル

ということで、基本的にはhoge.xlsにmerge-rightの内容をペーストするなどしていくことになる。
このとき、拡張子r13を右クリックから「プログラムで開く」を選び、Excelで開くように指定すると楽。Excel2007環境では、拡張子がxlsじゃなくても読込んでくれるので、.xlsをつけて…とかやる必要はない。たしか、2003とかではダメなはずです。
さ、がんばりましょう。で、Excel管理が如何に大変かを実感しよう！

で、下をポチッた

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)