干し石榴長文用

長文以外はTumblrへ徐々に移します。

Java勉強会に行ってきました

shuji_w6eさんが主宰する札幌Java勉強会vol.15へ参加してきました.修論というかとりあえず次のゼミがまずいので午前のみで.すみません.

内容としてはバージョン管理システムにおける集中管理と分散管理それぞれの特徴と比較ということでSubversionMercurialでした.

まずSubversionリポジトリが中央に1つで,いわゆるクライアント/サーバな関係のため単純でモデルを把握しやすい.しかしリポジトリありきなため最初が面倒ということでした.あとブランチ切ったりマージしたりということもすべてチームで共有することになるので,うまく人的連携が取れてないとリポジトリがカオスになってしまいかねないとのこと.

対してMercurialの方はルートからcloneした各々のローカルリポジトリがブランチとなる.そしてclone元にはpushしない限り影響を与えないということで,オープンソースにはもってこいということでした.ただしリポジトリ間でpushしたりpullしたりということでモデルは集中管理に比べ複雑になるし,チームで1つの成果物を作ってリリースとなるとやはり人的連携が欠かせません.また,Subversionと違いディレクトリを後から気軽にリポジトリとすることができるため,日常利用で便利ということでした.

shuji_w6eさんの所感としては”エンタープライズな社内開発で分散管理を使う必要性は薄い”
とのことでした.そもそもネットワークがつながらない状況で開発を行うことはない,と.

ただし,前述の通りディレクトリを後から気軽にリポジトリにできるため,集中管理リポジトリからチェックアウトしたローカルコピーを分散管理することは可能.Mercurialであれば.hgディレクトリが増えるだけなので,Subversion側でそれを無視するように設定すれば副作用なし.そうすれば,例えば子会社が親会社側リポジトリへの外からのcommit権を与えられない場合に親会社へ行ってcheck out→子会社内で分散管理で開発→親会社へ行ってまとめてcommitという使い方できるそうです.なるほど.

余談として,gitはLL系の人が,MercurialJavaなどエンタープライズな人がそれぞれ好む傾向にあるらしいです.

参考サイト
Mercurialではじめる分散構成管理|gihyo.jp … 技術評論社
分散バージョン管理Git/Mercurial/Bazaar徹底比較 (1/5) - @IT