GMT+0900先日、Subversionの1.9.5がリリースされたというのをTwitterで見かけました。この機会を逃したら2度と書くこともないと思うのでSubversionがgitより良い点と思う部分を書いてみる。個人的にこれがもっともSubversionがgitより優れていた点。gitはコミットログの書き換えが容易ではない。書き換えはできるけど、容易ではない。この話を書き出すと別で記事が書けてしまうので今回は書かないけれども、gitでコミットログを書き換えるのは非常に労力が必要になる。積みあがったコミットのコメントを書き換えるのはgitでは容易なことではない。fileter-branchというgit最強の破壊的オプションを使用して書き換える必要がある。これを使用したときの問題について書き出すとキリがないので今回は書かないけど、このオプションはマジでヤバい。比べて、Subversionはコミットログを容易に書き換えることができる。書き換えるにはhookにちょっとしたコードを書くだけ。いったものを書けば良いかは忘れてしまったが、調べれば出てくると思う。コミットログを後から書き換えることがあるのか?...と言われればちゃんとしたレビュー体制が整っていれば問題ないのかもしれない。マージの前に弾くことができるから。いった体制が整っていなければ、コミットメッセージが多少間違っているくらいならまだしも、ITSを使用している場合などのチケット(Issue)番号の記述が間違っていれば目も当てられない。対象のチケットに対するコミットが誤って表示されてしまうのだから。修正は容易ではない...gitを導入していたとしてもそこまでキッチリしたレビュー体制が整っている組織があるかと言われると、そうでもないのではないかと思う。結果として、チケット番号が異なるコミットがマージされる可能性が高くなる。なると、gitで後でログを変更するのは非常にめんどう(というか現実問題的に不可能に近い)になる。ITSを導入した場合はそのチェックが非常に重要になる。偉そうに書いておきながら、弊社ではできてません...前職の時は私がマージの前に全部やってたんですけどね...対して、Subversionはhookを少し弄れば後からログを変更できるので、この問題に対応することができる。話が逸れてしまうが、私はコミットログは非常に重要な要素だと思っていて、キチンとした単位で、キチンとしたメッセージを残さなければいけないと思っている。「ソースコードを見れば変更箇所が解る」とかいう理屈はある意味もっともだが、だからといってコミットログのメッセージを適当に書いたり、適当な粒度でコミットするには個人的に論外だと思っている。コードを見るまでもなく、コミットログである程度の概要が解るべきだと思っている。したコミットログは残すべき。いう点でgitは中央のリポジトリにpushしない限りはコミットはいくらでも書き換えてよいという思想なので、コミットをキレイにするには最適だと思う。従ってコミットはpushする前に出来る限りキレイにするべきだと思っている。この考えは大方間違ってないと思う。(ちなみにGitHubでgitのリポジトリを見てみるとコミットログは相当詳細なレベルで記述されている。)もっとも、個人的にやる範囲ではある程度適当でもよいと思うし、私も適当にやっていることが多い。個人的な範囲に限ってだが...コミット番号が解り易いgitのコミット番号はsha-1のハッシュ値なので直感的に解り難い。これはブランチの概念がSubversionと違うので仕方ないと思うのだけど、Subversionだと連番なので解り易い。解り易いと書いときながら、正直個人的にはどっちでもよい要素でもある。ファイルの削除がラクgitであるファイルを履歴ごと削除したいとなった場合、そこそこの労力が必要になる。前述のfileter-branchを使用して、かつ場合によってはもう少し複雑な処理が必要になる。コミットのハッシュ値が変わってしまうので、全員が再度cloneしなおさないといけない。対して、Subversionだとdumpでいらんファイルを除外すればいい。gitのfileter-branchにくらべてはるかに高速である。使う機会はそんなにないと思うんですけどね。悲観的ロックができるSubversion(というか中央管理型のバージョン管理システム)だとファイルごとの悲観的ロックをかけることができる。要するに「私がこのファイル編集してるので他の人は触らないでね。これも特に個人的に必要ないと思うんだけど、gitをはじめとした分散型のバージョン管理システムだとできない(git以外は正直知らない)まあ、たぶんプロジェクトによっては必要になる部分も出てくることもないのではないかと思う...特にバイナリのファイル編集するときとか編集するときとか編集するときとか...学習コストが低いgitは学習コストが非常に高いと言われているし、実際にそうだと思う。分散管理の次点で意味が解らんと思う。他の分散管理、例えばMercurialなどは使ったことないので知らないが、それらと比べても学習コストは高いといわれている。それに余りあるだけのメリットがあるし、gitが主流になってるのでいまからバージョン管理するならgitでやるべきだと個人的には思う。バージョン管理の概念とか歴史とか中央管理とか学ぶにはSubversionを一度触ってみるのもアリだという気がしなくもない。くどいけど今からやるならgitからやった方がいいと思うけど。Subversionのメリットに関係ない項目になっちゃったね...まとめプロジェクトによってどっちを使うかは異なると思います。YoshinoriN)。