第5回 分散による「多段連携」 ～ 大規模開発への応用 | gihyo.jp
企業においてフリーソフト／オープンソースソフトを導入しようとすると、以下のような意見に反対されることがあるのではないでしょうか？ 大規模開発では使えないんでしょ？ そこで今回は、大規模開発における構成管理を効率よく運用するための、Mercurialのリポジトリ分散性を活かした、幾つかのアイディアについて説明したいと思います。 中央集約形式の問題 ある程度以上の規模の開発の場合、事前に（あるいは開発を進めながら）取り決めたI/Fを介して連携する複数の部位に全体を分割し、複数のチームがそれぞれの担当分を開発する、という進め方をするのが一般的です。 このような開発体制を採用した場合、単一サーバが全ての要求を受け付ける中央集約形式のCVSやSubversionでは、サーバの応答性能低下が懸念されます。 図1 フラットな構成 また、全ての開発者が同様にメイントランクにアクセスしていたのでは、他拠点の
第3回 安全な「リリース」 ～ 複数リポジトリによる作業の隔離 | gihyo.jp
今回は、不安定な成果物が混在するメイン開発ラインに対して、リリース作業の構成管理の独立性・平行性を、分散リポジトリを使って確保する方法について説明します。 「リリース」における成果混交の問題 「一度だけリリースしてしまえば、後は野となれ山となれ」という開発は皆無である、とは言いませんが、 一般的な開発の場合、以下のような契機での「リリース」が必要とされるのではないでしょうか。 製品の出荷 本リリース前の試用版の提供 個別カスタマイズ版の提供 障害修正版の提供 開発期間途中での中間納品 こういった「リリース」の際、例えばCVSやSubversionといったモダンな構成管理ツールであれば、「タグ付け」や「ブランチ」といった機能により、以下のようなことを実現します（体系的な詳細に関しては、「パターンによるソフトウェア構成管理」を参照されるのが良いでしょう）。 ベースとなる版の決定 固有の
第2回 「マージ」は怖くない ～ 分散した成果の集約 | gihyo.jp
前回は、様々な方法で複製したリポジトリにおいて、それぞれ異なる作業成果を"hg commit"し、下図のような状態を構築するところまでを説明しました。 図1 成果の分散 今回は、これら複数の成果を、最終的な成果へと統合する「マージ」について説明します。 成果の集約 成果をマージするためには、マージ作業を行うリポジトリへと成果を集約する必要があります。 成果の集約には"hg pull"を使用します。前回の説明では「リポジトリの複製」に使用した"hg pull"ですが、厳密には「一方の保持していない成果を他方に伝播」する、リポジトリ間連携機能なのです。 myrepo2の成果をmyrepoに取り込む手順を以下に示します。 コマンド1 % cd myrepo % hg pull ../myrepo2 pulling from ../myrepo2 searching for changes add
Mercurial の利用
重要: Mercurial の 1.x ⇒ 2.0 では、 コンセプト／操作性／互換性等における大きな改変はありません。 あくまで通常の定例アップデートに過ぎませんので、 従来の版を元に書かれている情報の多くは、そのまま適用可能です。 はじめに ノート PC での移動中作業が多くて 「オフラインでコミット／ブランチ作成／履歴参照／差分参照できない」 ことに不便を感じていたり、 「システム構成例」 に示すような構成管理の仕組みを必要とした経験がある場合、 分散リポジトリ形式を用いる Mercurial は、 試してみる価値のあるソフトウェア構成管理 （SCM: Software Configuration Management） ツールと言えます。 しかし、 CVS などを常用して SCM ツールの原理／概念を理解している人でも、 意外に「分散リポジトリ」という考え方がピンとこない場合が有る
Mozilla、リポジトリをCVSからMercurialへ移行 | エンタープライズ | マイコミジャーナル
Mozilla Developer CenterにおいてMozilla-CentralがCVSからMercurialへ移行していることを発表した。現在の計画ではFirefox、XULRunner、Gecko/Toolkitコードまたはそれに関係するコードがMercurialリポジトリへマージされることになるという。 MercurialはPythonで開発されたバージョン管理システム。CVSとよく似た操作性を提供しつつも、高速に動作しディスク消費が少ない。さらに名前の変更などCVSではうまく機能しないいくつかの機能を提供している。3月24日(米国時間)にはMercurial 1.0が公開されている。 FLOSSプロジェクトではこれまでバージョン管理システムにCVSが採用されることが多かったが、最近ではSubversionをはじめGit、Mercurialなどに移行する作業が進められている。M
Mercurialではじめる分散構成管理：第1回 「分散」への第一歩 〜 ローカルでの複製｜gihyo.jp … 技術評論社
Linux/Unix環境ならパッケージ管理経由での導入が簡単です。 Windows環境への導入は、Cygwinを常用しているならCygwinのsetup.exe経由でPythonスクリプト形式を、そうでないならインストーラ経由でのバイナリ形式の導入が簡単です。 それぞれのインストール手順に関しては、別途詳細を説明したページを参照してください。 インストールが済んだなら、早速使ってみましょう。 まっさらな状態からリポジトリを作成する手順は次ページ以降で説明しますので、手近な対象としてMercurial自身のリポジトリを複製してみましょう。 コマンド1 % hg clone http://selenic.com/repo/hg mercurial-repo requesting all changes adding changesets adding manifests adding file
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20080311/
http://www.vectrace.com/mercurialeclipse/