Hatena::ブログ(Diary)

torutkの日記 RSSフィード

2010-12-29 バージョン管理ツール

[][]バージョン管理ツールの選択

開発組織、プロジェクトの特性で大きく左右されるのが構成管理なので、バージョン管理ツールはその都度選択しなければならないのが現状です。

選択の前提

  • 開発組織またはプロジェクトで標準化された構成管理(バージョン管理)環境が存在していない
  • 開発支援環境(構成管理)に開発組織またはプロジェクトが十分な資金投入をする意思がない

これは構成管理環境を専任スタッフが構築し、個々のプロジェクトへの適用・運用をサポートするというあるべき姿が取れていない組織でのバージョン管理ツール選択を考えるということを意図しています。

Subversionで対応可能か否か(分散の必要が本当にあるのか)

分散バージョン管理が話題になっていますが、実績/情報/対応ツール/日本語対応を考えるとSubversionが最有力候補です。そこで、Subversionでは構成管理上困ることがプロジェクトの特性上あるかを見極めます。

リポジトリと切り離された場所で修正を行うか

開発場所とバージョン管理用リポジトリがネットワークを介して常時接続できない場合、Subversionの適用は不向きです。

Subversionは、集中型リポジトリなので、バージョン管理の前提はリポジトリと常に接続できることです。リポジトリと切り離された場所で修正を行い、その後リポジトリにコミットするという作業形態があると、そこには構成管理ミスの発生要因が生じます。

具体例をいくつが挙げてみます。

  • ソフトウェア開発の一部を、リポジトリに常時アクセスできない別部門や別会社に委託する場合
  • ソフトウェアの試験/デバッグ環境とリポジトリが常時アクセスできない場合
  • 開発者がリポジトリへ直接アクセスすることを禁じ、人手を介して払い出し/更新を行うルールを強制するプロジェクトの場合

最初のケースには、ブランチ(ベンダーブランチ)で対応することもできますが、2,3番目のケースはブランチでの対応が困難です。また、ブランチで対応する場合、マージ作業をする必要がありますが、この作業は通常専任者を置く作業量です。

サーバープラットフォームに制約があるか

Subversionサーバーを動かすマシンに制約がある場合、Subversionの適用は不向きです。

多数の開発者が常時アクセスするので、サーバーマシンに制約があると、バージョン管理に支障が生じます。

具体例をいくつか挙げてみます。

  • サーバーマシンを24時間運転することができない場合
  • サーバーマシンのディスク容量が逼迫しているが増設できない場合
  • サーバーマシンの性能(CPU・メモリ・I/O等)が貧弱である場合
  • サーバーマシン上で他のサービス(ビルド、ファイルサーバー等)を動かし性能に余力がない場合
  • サーバーマシンとの間のネットワーク帯域が狭い場合
  • サーバーマシンのOSに制約がある場合(Windows 2000/XP/Vista/7などはライセンス上同時接続数に制限がある)

Subversionで対応できないとき

分散バージョン管理ツールの出番です。しかし、世の中には分散バージョン管理ツールが多数あるので、選択に悩んでしまいます。メジャーな(御三家)ツールは、

  • git
  • mercurial
  • bazaar

です。

機能的には細部で差はありますが、おおむね同等に見えます。なので、好きなものを選べばよい、といいたいところですが、日本語の使用等の環境面での制約があります。

なお、MacOSについては知識がないのでここでは触れません。

gitを選ぶ場合の制約
  • プラットフォームはLinuxで統一されている

Windowsでの使用は制約が多いので、いろいろ努力が必要。プロジェクトで多人数が使う環境では厳しい。

  • コミットログ、ファイル名はASCII文字範囲か、日本語を使う場合はUTF-8で全体を統一できる

EUC-JPにこだわっている人、こっそりShift_JISにしている人がいない。

mercurialを選ぶ場合の制約
  • コミットログ、ファイル名に日本語を使う場合、一つのロケールに全体を統一できる(UTF-8でなくてもよい。Windowsオンリーな環境ならCP932)

開発環境が、すべてWindowsであれば、日本語も含めて制約はないと思います。また、すべてLinuxでも同様です。混在すると、文字化けが生じます。

改行コードについては、OSが統一されているという前提で、変換なし、というのがよいと思います。

bazaarを選ぶ場合の制約

ちょっと思いつきません。一応、ロケール混在でも使用できます。Unicodeに伴う問題はあるようですが(正規化問題?)。

日本語ファイル名について

昔は、日本語でディレクトリ/ファイル名をつけるなんて百害あって一利なし、という意見を持っていました。しかし、公用語が日本語であるプロジェクトにおいては、ディレクトリ名や設計文書等のファイル名、コミットログに日本語を使うと一目瞭然というメリットは大です。

コンピュータ側の日本語問題は、現在のコンピュータが技術的にまだ未熟というだけに過ぎません。文字コードの問題は根が深い非常に複雑な技術課題ではありますが・・・。

適材適所もいいが、毎回ツールが違うのも疲れる

なるべく幅広い汎用性の高いツールを厳選して熟練し、それを使いまわすのが、高い生産性につながると思っているのですが、プロジェクトを渡り歩く身では、そうもいかないことが多くて・・・

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/torutk/20101229/p1