|
Size: 17324
Comment:
|
Size: 668
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| = Mercurialよくある質問 = | |
| Line 6: | Line 7: |
| = Mercurialよくある質問 = ---- |
|| [[TableOfContents]] ||<^>[[Include(JapaneseFAQ/Subpages)]] || |
| Line 9: | Line 10: |
=== hg pullとしたのにワーキングディレクトリはからっぽのままです === Mercurialというシステムにはリポジトリとワーキングディレクトリの2つの概念があります。{{{hg pull}}} はリモートリポジトリでの変更をローカルリポジトリに引っ張ってきますがワーキングディレクトリは変更しません。 そのおかげで引っ張ってきた変更をまだマージできずに作業中の状態がめちゃくちゃになるのを防げます。マージもやりやすくなります。 ワーキングディレクトリを更新するには、{{{hg update}}}を実行してください。pullをするときにワーキングディレクトリも更新したい場合は{{{hg pull -u}}}とします。こうした場合はローカルでの変更をマージしたり上書きしたりはしません。 === 古いバージョンに戻したいのですが、どうすればよいですか？ === {{{hg update -C <version>}}}で最新版が上書きされ指定したバージョンに移動します。 {{{hg revert <version>}}}とするとワーキングディレクトの内容は指定したバージョンにまで戻ってしまいますが、次のコミットでのparentは変化しません。revertは現在のバージョンの変更をなかったことにするために使うもので、古いバージョン上で作業するためには使えません。 (訳注:{{{hg update -C}}}ではワーキングディレクトリの内容とparentの両方が変化しますが、{{{hg revert <version>}}}ではワーキングディレクトリの内容は変わりますがparentはもとのままです) === revertでワーキングディレクトリを戻したのですが完全には戻りません === 多分{{{hg update -m}}}をしたのでしょう。つまり{{{hg parents}}}で見られるparentが2つになっていませんか。{{{hg revert}}}ではワーキングディレクトリを''primary parent''に戻すので、2つの親の間で異なる部分は戻されません。{{hg update -C}}で完全に戻ります。 リビジョン間を移動したい場合はきっと{{hg update -C}}が有用でしょう。 === からっぽのきれいなワーキングディレクトリが欲しい === 一番簡単な方法は{{{hg clone -U}}}を使うことです。こうすると新しい複製を作りますがワーキングディレクトリ上には何も置かれません。 '''注''': hgrcをもとのリポジトリからコピーしたほうが良いかもしれません。 === からっぽのディレクトリをaddしようとしたがうまくいきません === Mercurialではディレクトリの履歴を管理しません。ファイルのみ管理します。普通は問題ないのですが、ファイルを1つも持たないディレクトリは取り扱えません。空のディレクトリはそう便利というものでもなく、実装が複雑になりかねないのですぐに修正するつもりはありません。以下のような解決策を用いてください: * "this-dir-intentionally-left-blank" のようなファイルを追加する * Makefileなどのビルドプロセスでディレクトリを生成する === コミットしたときにメールを出したい === CommitHook を見てください。 === 多くのファイルのあるディレクトリのなかで少数のファイルだけをMercurialの管理下に置きたい(例えば ~/ )が、diffやcommitに時間がかかる === {{{ printf "syntax: glob\n*\n" > .hgignore }}} とするか、もしくは 0.7 以降であれば{{{ printf ".*\n" > .hgignore }}} としてもかまいません。 こうするとhgコマンドは明示的にファイルを追加しない限りすべてのファイルを無視します。 === 何故ファイルのmtimeがチェックアウト時に元に(訳注:コミット時のものに？)戻さないの？ === makeやdistutilsのようなビルドツールを使う場合、古いリビジョンにupdateするとそれらのツールによるファイルの更新がうまくいかないかもしれないという問題があるからです。さらに新しいほうのチェンジセットのほうがタイムスタンプが古い可能性もあります、というのは他のリポジトリからのpullや人からのパッチをimportした場合、リポジトリから取り出した ''新しい''チェンジセットのせいでタイムスタンプが ''古く'' なってしまうかもしれないからです。 (訳注:以下の訳はかなり怪しい) ''hg archive''を使うと、別のディレクトリにチェックアウトするようなことができます。これでタイムスタンプを制御できます。このディレクトリは新しく作られるので、後から別のチェンジセットに切り替えられたりすることがなく、上で挙げたような問題は生じません。 |
[[Include(JapaneseFAQ/CommonProblems)]] |
| Line 68: | Line 13: |
=== リビジョンナンバー、ChangeSetID、タグとは何か？ === Mercurialでは基本的に特定のリビジョンを指定するための方法が3つあります。リビジョンナンバー、チェンジセットID、タグとです。 リビジョンナンバーは単なる10進数で、ローカルのリポジトリに何番目にコミットしたかという番号です。この順番はマシンごとに異なるということに十分注意してください。Mercurialは分散型で非集中的な設計になっているからです。 そのためチェンジセットIDが必要になります。チェンジセットIDはチェンジセットおよびチェンジセットの履歴における位置を一意に特定するための160ビットの識別子です。この値はどのマシンでも同じになります。Mercurialユーザに対してはこの値を40文字の16進数の数字として扱います。この形式では扱いずらいため、あいまいでなければ部分文字列を使ってリビジョンを特定することができます。またChangeSetIDを表示する場合、Mercurialは大抵短縮形式と呼ばれるChangeSetIDの先頭12文字を表示します。 他のMercurialユーザとあるリビジョンについて論議する場合、リビジョンナンバーではなくchangeset IDを使うべきです。人のリポジトリとはリビジョンナンバーが異なる可能性があるからです。 最後に、タグとはあるchangeset IDに関連付けられた文字列です。任意に決めることができ、あるリビジョンに名前を付けることができます。 === branches、heads、tip とは何？ === ブランチはMercruialの中心的な概念です。ブランチとは独立した開発ラインのことです。他のほとんどのバージョン管理システムでは、すべての開発者が 'trunk'や 'メインブランチ' と呼ばれるものにコミットするのが一般的です。Mercurialでは各開発者が私的なブランチ上で作業するのでMercurial自身は'メインブランチ'という概念を持っていません。 そのためMercurialはブランチ間のマージの繰り返しをを簡単にできるようにしています。{{{hg pull}}}と{{{hg update -m}}}を走らせてから結果をコミットするだけでマージができます。 'heads' とはあるブランチの上での最も最近のコミットです。技術的に言えば子をまったく持たないチェンジセットのことです。マージとは2つのheadsを一つにまとめる操作であると言えます。{{{hg heads}}}とすると現在のリポジトリ内のheadsを見ることができます。 'tip'とは最も最近に変更されたheadのことであり、最も大きなリビジョンナンバーを持つチェンジセットのことです。何も指定せずにコミットをすると、それは'tip'に対してなされます。一方、他のリポジトリからpullをすると、そのリポジトリのtipが現在のtipになります。 'tip'はupdateのような多くのコマンドのデフォルトのリビジョンとなりますし、また特別なタグとしても機能します。 |
[[Include(JapaneseFAQ/Terminology)]] |
| Line 94: | Line 16: |
=== マージはどのようにするの？ === マージするのは簡単です。よくあるパターンとして、tipを自分のワーキングディレクトリにマージすることを考えます。この場合{{{hg update -m}}}とするとtipでの変更をローカルでの変更と合併します。 この過程において、Mercurialはまずマージしようとしている2つのバージョンの'共通の祖先'を探しだします。これはプロジェクト全体と各ファイルの両方で調べます。 両方のバージョンで変更が加えられている場合、リモートでの変更をローカルでの変更に加えるため3-wayマージをしようとします。リモートとローカルで変更部が衝突している場合、対話的にユーザに衝突を解決するように求めます。 ユーザは衝突の解決に補助ツールを使うことができます。例えばtkdiffやkdiff3、古典的なRCSのmergeなどです。これは通常hgmergeから呼びだされます。 マージが終わり、結果が正しいと思ったならば、その結果をコミットしましょう。Mercurialにおいてはこのコミットをしないと次のマージはできません。というのは未来にマージするのにこの結果が必要になるかもしれないからです。 === Mercurialで分散開発をするためのベストプラクティスは？ === まず、マージは頻繁にしましょう。そうすればマージは簡単になりますし、衝突(衝突が起きるのは設計上の非互換な決断が原因であることが多いです)の解決も簡単になります。 次に、ローカルに新しいツリーを作るのを躊躇しないようにしましょう。Mercurialではこの操作は高速で低コストです。良くあるやりかたとしては、income treeとoutgoint treeを作り、異なる作業ごとに作業用ツリーを作るというものです。 以下この項目は翻訳されていません。 === 他のSCMで作ったリポジトリからインポートするにはどうすれば良いですか？ === ConvertingRepositories を見ましょう。 === Windowsでのサポートは？ === WindowsInstall を見てください。 == タグについて == === タグは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は文句を言うので、指定したいリビジョンを直接指定してください。 ある一つのヘッドが異なるブランチ上の互いに関係ない複数のタグに関連付けられる場合もありえますが、通常問題にはなりません。 |
[[Include(JapaneseFAQ/GeneralUsage)]] |
| Line 159: | Line 19: |
| [[Include(JapaneseFAQ/BugsAndFeatures)]] | |
| Line 160: | Line 21: |
| === バグを見つけたけど、どうすれば良い？ === Mercurialのメーリングリスト ( mercurial@selenic.com ) か バグトラッカ( http://www.selenic.com/mercurial/bts/ )に報告してください。 === バグ報告には何を書けばよい？ === バグを再現するか特定するのに十分な情報です。できれば、hg -v や hg -d switches を使ってMercurialが正確に何をしているのかを突き止めてください。 簡単なリポジトリでバグを再現できるのであれば、とてもありがいことです。一番良いのはこの過程を自動的に実行する簡単なシェルスクリプトを書くことです。そうすればMercurialのテストに追加できます。 === Mercurial は <x> できますか？ === ある機能が欲しいのであれば、メーリングリストに送ってください。Mercurialはまだ新しいため、間違いなく欠けている機能がありますし、どう実装すべきかフィードバックをください。 また、ToDo や MissingFeatures を見れば今後の予定やどのような手助けが必要かわかります。 |
== ウェブインターフェース == [[Include(JapaneseFAQ/WebInterface)]] |
| Line 178: | Line 25: |
| [[Include(JapaneseFAQ/TechnicalDetails)]] | |
| Line 179: | Line 27: |
| === Mercurialの限界は？ === Mercurialは現在ファイルやインデックスやマニフェストは効率のためメモリ内で処理します。 revlogでのオフセットは32bitで処理するため、revlog内での一つのファイルは4GBより小さくなくてはなりません。 その他、ファイル名の長さやファイルの大きさ、ファイルの内容、ファイル数、リビジョン数には制限はありません。 ネットワークプロトコルはビッグエンディアンであると規定されています。 ファイル名にはヌルキャラクタを含んではいけません。コミッタのアドレスは改行を含むことはできません。 Mercurialは主にUNIX上で開発されているため、他への移植版にUnix的要素が表れることがあります。 === Mercurialはデータをどのように格納するの？ === この項はまだ翻訳されていません。 === バイナリファイルの取り扱いはどうなっているの？ === BinaryFiles を見ましょう。 === Windows式改行とUnix式の改行の違いはどう？ === EncodeDecodeFilter を見ましょう。 === $Id$ のようなキーワード置換をしたい === EncodeDecodeFilter を見ましょう。 === Mercurialはどのようにして差分を計算している？ === === manifestやチェンジセットをどのように格納している？ === === ハッシュ値はどのように計算している？ === === リポジトリの完全性をどのように調べている？ === === Mercurialにおける署名はどうなっている？ === === ハッシュ値は衝突しない？ SHA1の脆弱性はどうなの？ === |
このページは ["FAQ"] の翻訳です。まだ不完全ですので適当に修正してください。
Mercurialよくある質問
1. 一般的な問題
Include(JapaneseFAQ/CommonProblems)
2. 用語
Include(JapaneseFAQ/Terminology)
3. 基本的な使い方
Include(JapaneseFAQ/GeneralUsage)
4. バグや新機能
Include(JapaneseFAQ/BugsAndFeatures)
5. ウェブインターフェース
Include(JapaneseFAQ/WebInterface)
6. 技術的詳細
Include(JapaneseFAQ/TechnicalDetails)