Meld Visual diff and merge tool Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories, and has support for many popular version control systems. Meld helps you review code changes and understand patches. It might even help you to figure out what's going on in that merge you keep avoiding. File comparison
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
分散バージョン管理Git/Mercurial/Bazaar徹底比較：ユカイ、ツーカイ、カイハツ環境！（3）（1/5 ページ） Subversionとは一味違う「分散バージョン管理」とは？ 最近、Linuxをはじめ、Ruby on Rails、MySQL、OpenSolarisなどのオープンソースプロダクトが次々と分散バージョン管理システムを導入し始め、「Git」「Mercurial」「Bazaar」といった、分散バージョン管理システムが注目を浴びています。 本稿では、バージョン管理ツールのデファクトスタンダードであるSubversion（以下、SVN）と分散バージョン管理システムを比較しながら、メジャーな分散バージョン管理システムであるGit、Mercurial、Bazaarについて紹介していきます。 集中型と分散型 最初に、集中管理方式（または、集中型）のバージョン管理システムと分散管理
今回は、対象の構成管理がMercurialであるか否かに関わり無く、Mercurialを併用することで開発効率を向上させる手法を説明します。 題材としてフリーソフト／オープンソースソフトを取り上げますが、ここで説明する手法は、「Mercurial以外の構成管理ツールの使用を指定されている開発」といった、（残念ながら）良くあるシチュエーションでも適用可能です。 なお本稿では、フリーソフト／オープンソースソフトの総称として、以降FLOSS（Free/Libre and Open Source Software）の略称を使用します。 No Patch, No Life 世間的にFLOSSが認知されて随分時間も経ちましたし、その数も相当なものになりました。 その気になれば、CVSやSubversionで運用されているリポジトリにアクセスして、最新成果をいち早く試してみることも、これまでの開発過
企業においてフリーソフト／オープンソースソフトを導入しようとすると、以下のような意見に反対されることがあるのではないでしょうか？ 大規模開発では使えないんでしょ？ そこで今回は、大規模開発における構成管理を効率よく運用するための、Mercurialのリポジトリ分散性を活かした、幾つかのアイディアについて説明したいと思います。 中央集約形式の問題 ある程度以上の規模の開発の場合、事前に（あるいは開発を進めながら）取り決めたI/Fを介して連携する複数の部位に全体を分割し、複数のチームがそれぞれの担当分を開発する、という進め方をするのが一般的です。 このような開発体制を採用した場合、単一サーバが全ての要求を受け付ける中央集約形式のCVSやSubversionでは、サーバの応答性能低下が懸念されます。 図1 フラットな構成 また、全ての開発者が同様にメイントランクにアクセスしていたのでは、他拠点の
今回は、普段使用している共有リポジトリ（＝ マスターリポジトリ）へのアクセスができないような、制約のある状況を考えてみます。このような状況でも、分散リポジトリ形式であることを活かし、共同作業を円滑に進める方法について説明します。 「閉じた環境」での作業 開発成果をリリースする場合、顧客の環境に赴いての導入作業や、場合によっては稼動環境下での障害調査・対応が求められるケースがあります。 ある程度の規模の組織では、システム稼働環境は無論のこと、作業用PCが接続されたネットワークですら、ファイアーウォールや運用規約によって、ガッチリと守られている場合の方が多いのではないでしょうか。 そういった環境には、当然外部からアクセスすることはできませんから、アクセスするためにはターゲット環境側に移動する必要がありますが、今度は逆にマスターリポジトリへのアクセスができなくなってしまいます。 そうなると、中央
今回は、不安定な成果物が混在するメイン開発ラインに対して、リリース作業の構成管理の独立性・平行性を、分散リポジトリを使って確保する方法について説明します。 「リリース」における成果混交の問題 「一度だけリリースしてしまえば、後は野となれ山となれ」という開発は皆無である、とは言いませんが、 一般的な開発の場合、以下のような契機での「リリース」が必要とされるのではないでしょうか。 製品の出荷 本リリース前の試用版の提供 個別カスタマイズ版の提供 障害修正版の提供 開発期間途中での中間納品 こういった「リリース」の際、例えばCVSやSubversionといったモダンな構成管理ツールであれば、「タグ付け」や「ブランチ」といった機能により、以下のようなことを実現します（体系的な詳細に関しては、「パターンによるソフトウェア構成管理」を参照されるのが良いでしょう）。 ベースとなる版の決定 固有の
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ページを開く
