m個ってなってるのは数えるのが面倒だからです。
別の記事にねじ込んでたので、分離しました。
開発の現場ではバージョン管理ツールは使ってるだろうと思いますが、
「創業当時からのsubversionです」ってところが殆どでしょう。
しかし、subversionは幾つかの明確な問題があり、
業務に支障を来す恐れがあります。
実際に、今小生は出稼ぎにいっている職場では、
支障を来しています。
以上の大きなデメリットが、僅かなメリットを凌駕します。
一応、「僅かなメリット」も書いておきましょう。
一方、分散バージョン管理は、自前でリポジトリを持つため、ローカルOSのファイル名キャラクタセットとは無縁では居られません。小生もちょっと考えたけど思いつきませんし。
別の記事にねじ込んでたので、分離しました。
開発の現場ではバージョン管理ツールは使ってるだろうと思いますが、
「創業当時からのsubversionです」ってところが殆どでしょう。
しかし、subversionは幾つかの明確な問題があり、
業務に支障を来す恐れがあります。
実際に、今小生は出稼ぎにいっている職場では、
支障を来しています。
- 設置面
- 「サーバ」が必ず必要。
- C++による実装のため、ソースから設置は面倒くさい。
- rpmアルよ
- 知ってるよ。ってCentOSだと古かったり、組み合わせるバグトラックシステムが古かったりとか色々。小生はubuntuだから比較的新しいけど。使ってないけど。
- 運用面では
- ローカルコピーでもかなり遅い。→実測しました。
- さらにHTTP経由だと更に遅い
- そのために、.svnディレクトリに、巨大なキャッシュファイルを置いている。
- 迂闊にディレクトリコピーしようとすると、.svnを上書きしちゃって、ややこしいことに。
- .svnを削除してからコピー、って※ツールの癖に手間を増やすな
- 遠隔地にコピーしようとすると、絶望的な時間を要する。
- .svnを削除してからscp/ftp、って※ツールの癖に手間を増やすな
- apacheモジュールサーバの場合だと、リポジトリを破損する可能性が高い。
- 実績＆経験を踏まえると、20MB以上のサイズのバイナリを扱うと、壊れる可能性が飛躍的にあがる
- リポジトリを破損しても
- 次のリビジョンをcommit出来てしまう。
- 修復する手段が少ない。
- しかもsvndumpは壊れたリビジョンに引っかかると異常終了する。
- 信頼性皆無
- ブランチの実装がヘボイ。
- branchって掘ってコピーして使ってね♪とか意味判らん。※ツールの癖に手間を増やすな
- マージの実装がヘボイ。殆ど手伝ってくれない。マージ対象バージョンを必ず人間が指定する、って ※ツールの癖に手間を増やすな
以上の大きなデメリットが、僅かなメリットを凌駕します。
一応、「僅かなメリット」も書いておきましょう。
- 複数種類のOSで、相互に日本語ファイル名を交換できる。
一方、分散バージョン管理は、自前でリポジトリを持つため、ローカルOSのファイル名キャラクタセットとは無縁では居られません。小生もちょっと考えたけど思いつきませんし。
