Subversion で文書やプロジェクトを管理している企業は git に移行すべき

私は「流しのプログラマ」なので，それぞれの職場の環境に自分を最適化させて仕事をするわけだが，一度 git の便利さを味わってしまうと以前には戻れないことに気が付いた。

Subversion は branch/merge のコストが高い

Subversion は思想的には RCS（Revision Control System）や CVS（Concurrent Versions System）の流れを汲むもので branch のコストが高い。というより merge のコストが高いというべきか。一度 branch すると trunk への merge がとてつもなく面倒になる。

Subversion では作業を trunk で行うのが通常の workflow なのだが， git では「作業を行う際は branch を作成し branch 上で作業する」のが通常の wrokflow になる。

いったんこれに慣れると「作業用 branch」を作るコストが高い Subversion はストレスになる。また複数人で作業している場合， Subversion ではひとつの trunk に全てのユーザが commit しようとするため衝突が発生しやすく，その調整作業がかなり面倒である。

（衝突が起きるのはまだマシな方で，操作をしくじって知らん間に古い記述に巻き戻されてたりするんだよなぁ。その点 git なら必ず pull/push の操作を行うので失敗が少ない）

Subversion は fork のコストが高い

Subversion は fork のコストが高い。というより中央集権型の Subversion では repository 間の関連を持たせられない。

このことが効いてくる状況としては，ひとつのプラットフォームに複数のプロジェクトが相乗りしている場合である。

企業が保持するプラットフォームは重要な資産である。開発企業が持つ開発プラットフォームは言わずもがなだが，文書管理のプラットフォームもこれに劣らず重要である。特にきょうびは複数部署の文書をそれぞれの部署に最適化されたアプリケーションを使いつつ統合的に管理するようになってきている（Web での運用がこれに拍車をかける）。

ひとつのプラットフォームにある複数のプロジェクトを Subversion でまとめて管理する際は，全てをひとつの repository に包摂するのがいちばん簡単だが，この場合，プラットフォームやプロジェクトの相互関係が密になりすぎて，思うような運用ができなくなる。またプラットフォームとプロジェクトを別々の Subversion repository で管理しようとすると，お互いが関連しあっているにも関わらず repository 同士が関連付けられないので，相互の影響を測定しづらい。

これに関する問題のひとつとしてプラットフォーム自体のアップデートが難しいことが挙げられる。

以前，「踊るセキュリティ」で国税庁を盛大に dis ったわけだが，個人的に似た状況に陥っていて困っていたりする。最大の問題はひとつのプラットフォームに複数のプロジェクトが相乗りになっていて，プラットフォームをバージョンアップしようにもリスクの測定が難しく手を出せないことにある。そうするうちにプラットフォームのサポート期間が終わってしまい，更にリスクが引き上がる。

git でこうした問題がまるっと解決されるわけではないが，少なくとも fork を上手に使えば，影響範囲を最小限にしてリスクの測定ができる。またリスクの測定やそこで得た成果を pull request 等で feedback できる（念のために書いておくと， pull request は git 自体の機能ではなく git を使った workflow の手段のひとつ）。

Subversion で文書やプロジェクトを管理している企業は git に移行すべき

というわけで，まだ Subversion で文書やプロジェクトを管理している企業は git に移行すべき。わざわざ切れ味の悪い道具で苦労する理由はない。