T

コードの管理

Subversionでブランチとトランクのmergeを実行したところ、どうもうまくいかなかったらしい。ブランチの変更がトランクの変更を打ち消してしまっているソースコードがいくつか見つかった。とりあえす手動で直して、原因を突き止めようとしているのだが、まだはっきりとしたところはわからない。

どのツリーへのコミットも全てBTSとメールで記録されているので、毎月のメンテナンスリリース程度ならばSubversionに任せきりではなくこちらでもmergeが確実に実行されているかどうか確認するようにした。運用上のヘマならいいのだが、もっと根深い問題なら困ったものだ。

ソースコードの管理をSubversionに移行してから、CVSよりはるかに簡単な操作で随分と楽をさせてもらっているのだが、やはり複雑に分岐したブランチを取りまとめるのは大変だ。

ふと思ったのだが、Joel on softwareの「ストラテジーレターIV: ブロートウェアと80/20の神話」では触れられていない話があって、市場の拡大による売り上げアップを狙っていわゆる「ライト版」を作るというのは、コードの管理を複雑にしてそのコストを引き上げるので、元のフルバージョンのコストを上げてしまうという弊害もある。開発済みのプログラムから機能を抜くのはときどきかなり面倒くさい作業で、おまけにバージョン毎にちょっとした違いがあったりすると管理コストはさらに跳ね上がる。どうせやるなら、最初から使える機能をコントロールできる機構が組み込まれているようにしないといけない。そうじゃないと、テストのコストだけでも結構なものになるので、ライト版は営業の人たちが思っているほどお安くはならなくなってしまう。おまけに、そんな作業でリリースに失敗したり不具合でも埋め込んでしまっては泣くに泣けない。

Posted by on 7月 11, 2007 in Subversion

コメントを残す