Differences between revisions 2 and 3
Revision 2 as of 2009-05-19 19:31:05
Size: 5633
Editor: localhost
Comment: converted to 1.6 markup
Revision 3 as of 2009-09-14 12:40:22
Size: 6625
Comment: Updated to FAQ/GeneralUsage -r7.
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:

[[Merge|merge]] を参照してください。

## 以下は原文から削除されていますが、 Merge が未訳なため残しておきます --------
Line 15: Line 19:
## ここまで ----------------------------------------------------------
Line 16: Line 22:

[[WorkingPractices]] を参照してください。

## 以下は原文から削除されていますが、 WorkingPractices が未訳なため残しておきます --------
Line 23: Line 33:
## ここまで ----------------------------------------------------------
Line 25: Line 37:
ConvertingRepositories を見まょう ConvertingRepositories を参照てください
Line 29: Line 41:
WindowsInstall を見てください。 WindowsInstall を参照してください。

=== GUI フロントエンドはありますか? ===

グラフィカルなマージツールやその他フロントエンドについては、 OtherTools を参照してください。


## 以下は原文から削除されていますが、 念のため残しておきます。 ----------------
## 原文がどこに移動したか分かり次第、同様に移動させる予定です。
Line 65: Line 85:

## ここまで ----------------------------------------------------------

マージはどのようにするの?

merge を参照してください。

マージするのは簡単です。よくあるパターンとして、tipを自分のワーキングディレクトリにマージすることを考えます。この場合hg update -mとするとtipでの変更をローカルでの変更と合併します。

この過程において、Mercurialはまずマージしようとしている2つのバージョンの'共通の祖先'を探しだします。これはプロジェクト全体と各ファイルの両方で調べます。

両方のバージョンで変更が加えられている場合、リモートでの変更をローカルでの変更に加えるため3-wayマージをしようとします。リモートとローカルで変更部が衝突している場合、対話的にユーザに衝突を解決するように求めます。

ユーザは衝突の解決に補助ツールを使うことができます。例えばtkdiffやkdiff3、古典的なRCSのmergeなどです。これは通常hgmergeから呼びだされます。

マージが終わり、結果が正しいと思ったならば、その結果をコミットしましょう。Mercurialにおいてはこのコミットをしないと次のマージはできません。というのは未来にマージするのにこの結果が必要になるかもしれないからです。

Mercurialで分散開発をするためのベストプラクティスは?

WorkingPractices を参照してください。

まず、マージは頻繁にしましょう。そうすればマージは簡単になりますし、衝突(衝突が起きるのは設計上の非互換な決断が原因であることが多いです)の解決も簡単になります。

次に、ローカルに新しいツリーを作るのを躊躇しないようにしましょう。Mercurialではこの操作は高速で低コストです。良くあるやりかたとしては、income treeとoutgoint treeを作り、異なる作業ごとに作業用ツリーを作るというものです。

以下この項目は翻訳されていません。

他のSCMで作ったリポジトリからインポートするにはどうすれば良いですか?

ConvertingRepositories を参照してください。

Windowsでのサポートは?

WindowsInstall を参照してください。

GUI フロントエンドはありますか?

グラフィカルなマージツールやその他フロントエンドについては、 OtherTools を参照してください。

タグについて

タグはMercurial上ではどう使うの?

タグはMercurialと他のSCMではちょっと違いがあります。Mercurialでは以下の目標があります。

  • ファイルのようにタグをバージョン管理したい
  • マージもしたい
  • タグに署名をしたい
  • すでにコミットしたチェンジセットにタグを付けたい
  • タグを後で変更できるようにしたい

そのためMercurialではタグをワーキングディレクトリの.hgtagsというファイルに格納します。.hgtagsにはチェンジセットIDとそれに対応付けられたタグのリストが書かれています。タグを追加すると、Mercurialは.hgtagsに一行追加してコミットします。hg tagはこのような動作をします。hg tagsは現在有効なタグを表示します。

タグはチェンジセットIDを参照し、チェンジセットIDは事実上対応する変更に関するリポジトリ内の内容すべてを指しているわけですから、コミットとタグ付けを同時に行うことはできません。コミットしてからタグを付ける必要があります。

ローカルなタグを作りたいんだけど

hg tagコマンドで-lもしくは--localオプションを付けましょう。こうするとタグは.hg/localtagsに収められ、バージョン管理下に入らず、他のリポジトリに影響を与えることもなくなります。このファイルの形式は.hgtagsとまったく同じであり、ローカルタグも普通のタグと同じように扱えます。

headが複数ある場合tagはどうなるの?

まだ翻訳されていません。

ブランチタグはどうやれば使える?

CVS式のブランチタグはMercurialのような分散SCMでは意味がありません。すべてがブランチだからです。というわけで大抵のMercurialユーザはブランチごとに異なるリポジトリを持ちます。しかし複数のブランチを1つのリポジトリで使いたいのであれば、うまく工夫することで普通のタグをブランチタグのように使えます。

タグは直接的にはある特定のリビジョンのみを指しますが、そのリビジョンがあるブランチのheadを特定するのにも使えます。それぞれのheadに関連付けられたタグを見るためには、hg heads -hとしてください。あるタグに関連付けられたブランチのheadをチェックアウトしたい場合は、hg update -b tagnameが使えます。

あるタグが示すリビジョンから分岐して、そこからもう一度マージをする前であれば、複数のブランチのheadがその同じタグで参照されることになる可能性があることに注意してください。この場合Mercurialは文句を言うので、指定したいリビジョンを直接指定してください。

ある一つのヘッドが異なるブランチ上の互いに関係ない複数のタグに関連付けられる場合もありえますが、通常問題にはなりません。

JapaneseFAQ/GeneralUsage (last edited 2009-09-14 14:40:14 by YuyaNishihara)