subversionを辞めるべきm個の理由

m個ってなってるのは数えるのが面倒だからです。

別の記事にねじ込んでたので、分離しました。

開発の現場ではバージョン管理ツールは使ってるだろうと思いますが、
「創業当時からのsubversionです」ってところが殆どでしょう。

しかし、subversionは幾つかの明確な問題があり、
業務に支障を来す恐れがあります。
実際に、今小生は出稼ぎにいっている職場では、
支障を来しています。

• 設置面
• 「サーバ」が必ず必要。
• C++による実装のため、ソースから設置は面倒くさい。
• rpmアルよ
• 知ってるよ。ってCentOSだと古かったり、組み合わせるバグトラックシステムが古かったりとか色々。小生はubuntuだから比較的新しいけど。使ってないけど。
• 運用面では
• ローカルコピーでもかなり遅い。→実測しました。
• さらにHTTP経由だと更に遅い
• そのために、.svnディレクトリに、巨大なキャッシュファイルを置いている。
• 迂闊にディレクトリコピーしようとすると、.svnを上書きしちゃって、ややこしいことに。
• .svnを削除してからコピー、って※ツールの癖に手間を増やすな
• 遠隔地にコピーしようとすると、絶望的な時間を要する。
• .svnを削除してからscp/ftp、って※ツールの癖に手間を増やすな
• apacheモジュールサーバの場合だと、リポジトリを破損する可能性が高い。
• 実績＆経験を踏まえると、20MB以上のサイズのバイナリを扱うと、壊れる可能性が飛躍的にあがる
• リポジトリを破損しても
• 次のリビジョンをcommit出来てしまう。
• 修復する手段が少ない。
• しかもsvndumpは壊れたリビジョンに引っかかると異常終了する。
• 信頼性皆無
• ブランチの実装がヘボイ。
• branchって掘ってコピーして使ってね♪とか意味判らん。※ツールの癖に手間を増やすな
• マージの実装がヘボイ。殆ど手伝ってくれない。マージ対象バージョンを必ず人間が指定する、って ※ツールの癖に手間を増やすな

以上の大きなデメリットが、僅かなメリットを凌駕します。

一応、「僅かなメリット」も書いておきましょう。

• 複数種類のOSで、相互に日本語ファイル名を交換できる。

一方、分散バージョン管理は、自前でリポジトリを持つため、ローカルOSのファイル名キャラクタセットとは無縁では居られません。小生もちょっと考えたけど思いつきませんし。