【分散型バージョン管理】 Mercurial 【hg】
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/08/25(火) 23:02:30公式
http://mercurial.selenic.com/wiki/
日本語チュートリアル
http://mercurial.selenic.com/wiki/JapaneseTutorial
Mercurial - Wikipedia
http://ja.wikipedia.org/wiki/Mercurial
Mercurialではじめる分散構成管理
http://gihyo.jp/dev/feature/01/mercurial/0001
TortoiseHG
http://tortoisehg.sourceforge.net/
0232デフォルトの名無しさん
2010/04/14(水) 12:50:45|┃ | |
|┃ ＼＿／
ｶﾞﾗｯ |┃ |
|┃ ﾉ// ／ ￣ ￣ ＼
|┃三 ／ ::＼:::／:: ＼
|┃ ／ <●>::::::<●> ＼.
|┃ | （__人__） |
|┃三 ＼ ｀ ⌒´ ／
|┃三 ／￣￣￣￣￣￣￣ ＼
0233デフォルトの名無しさん
2010/04/14(水) 13:24:54だめ、fixutf8が読み込まれる前に、まだUTF-8になっていないコマンドライン引数を
使ってしまっている部分がある。
0234デフォルトの名無しさん
2010/04/14(水) 13:26:110235デフォルトの名無しさん
2010/04/14(水) 18:32:50それでなにか問題なのか？
0236デフォルトの名無しさん
2010/04/28(水) 14:29:410237デフォルトの名無しさん
2010/05/04(火) 21:39:260238デフォルトの名無しさん
2010/05/10(月) 01:00:25他のWindowsプログラムから使いにくいんですが、上手く扱う方法ないんでしょうか？
cygwin版hg.exeないのかな？
cygwin bash上からは使えるけど、cmdからは使えなかったり、NetBeansなどから設定できなかったりします。
0239デフォルトの名無しさん
2010/05/10(月) 07:42:39PATH を通せばいけた気が。
0240デフォルトの名無しさん
2010/05/10(月) 11:30:06@python C:\cygwin\bin\hg %*
とか書いた hg.cmd をパスの通ったとこに置いとけばいいんじゃない？
0241デフォルトの名無しさん
2010/05/13(木) 13:00:15PATHは通してますが、オプション設定でOKするとMercurial見つからないと行ってくる
>>240
いけるかなー、試してみます
0242デフォルトの名無しさん
2010/05/13(木) 17:18:08そういえば、Eclipse のアナウンスがあったけど、この件どうなったんだろう？
0243デフォルトの名無しさん
2010/05/16(日) 08:50:160244デフォルトの名無しさん
2010/05/19(水) 01:19:330245デフォルトの名無しさん
2010/05/19(水) 06:41:03nodeidをconvertしないオプションがあるからそれを使えばいけるかもしれない。
0246デフォルトの名無しさん
2010/05/20(木) 00:45:19ありがと、convertってコマンド自体がないけど、
convertextensionでよいの？
0247デフォルトの名無しさん
2010/05/20(木) 02:30:20Yes.
hg convert --help でいろいろ出てくるんで、試してちょ。
0248デフォルトの名無しさん
2010/05/20(木) 02:49:48ただ単に hg branches で出したくないだけだったら、新たにブランチ作って、
元のはcloseするのが正しいやり方のような気がする。
0249デフォルトの名無しさん
2010/05/22(土) 10:20:04作業できるんだけど、エクスプローラーの右クリックメニューから
どの項目を選択しても、GUIが全く起動せず無反応。
そういう不具合ってうちの環境だけ? 再インストールしてもダメ。
コマンドプロンプトからaddとかするとアイコンオーバーレイは
普通に動作してる。
Win 7 64bitで、ToirtoiseSVNも入ってる環境。
TourtoiseHgをこのマシンに入れたのは初回。
0250デフォルトの名無しさん
2010/05/23(日) 02:05:51普通は２つのリポジトリを作るんだろうけど、
ある数個のプログラムだけ共通処理として同じソースを利用している場合、
Aで共通処理を修正したらBにもマージって
ってことが出来ないから、
１つのリポジトリでA,Bをブランチ作った。
でも、やってみると、その共通ソース以外のも全部マージしなくちゃならないハメになって困ってる。
みんなこういうときどうする？
0251デフォルトの名無しさん
2010/05/23(日) 04:19:33それで、実用性が良く分からないけどsubrepoを試すか、ツールで頑張る。
１つのリポジトリ２つのブランチの場合、Transplant extension で頑張る。
0252デフォルトの名無しさん
2010/05/25(火) 20:58:10Subversionしか知らなかった自分としてはあまりの手軽さに感激してるのですが
一点どうしても不満な点があります。
例えば、dir01/dir02/dir03という階層があり、
dir01をバージョン管理しているとします。
この状態で、Subversionではdir03のみをチェックアウトして
ごにょごにょ操作したのち元のリポジトリにコミットすることができます。
しかしmercurialではdir01以下を丸ごと扱うしか術が無いようです。
.hgディレクトリもトップディレクトリにしか無いですね。
具体的には、
会社でサイズの大きなファイル群をmercurial管理するようにしたのですが、
自宅でも作業したいのです。
しかし自宅では、プロジェクトのごく一部しか修正することは無いので、
その部分のみを取り出して自宅用の小さいリポジトリを作りたいのです。
こんなことは実現可能でしょうか？
0253デフォルトの名無しさん
2010/05/25(火) 21:15:11dir01でdir03の管理部分を .ignore 指定して
0254デフォルトの名無しさん
2010/05/25(火) 22:12:45すでにMercurialに全部突っ込んだのなら、簡単にやる方法は無い。
こういう場合、convertでそのディレクトリだけ抜き出すことができる。
これに限らず、合体は簡単、分離は大変なので、なるべく小さな単位で管理した方が楽。
251 にも書いてあるが、subrepoという手段もある。
0255デフォルトの名無しさん
2010/05/25(火) 22:35:29Mercurialは、チェンジセット指向で、
Subversionの個々のファイル、ディレクトリ単位でコミットできることの方が
おかしいということにそのうち気付くと思う。
重いのは最初のcloneだけで、その後のpull, pushはめちゃくちゃ速いので、
無理に分ける必要は無いのでは？
0256デフォルトの名無しさん
2010/05/25(火) 23:35:50Subversionもチェンジセット指向だし、
Mercurialも個々のファイルごとにコミットできたりするよ。
>>252
とはいえ、Mercurialなら自分は >>254 と同感だけど。
0257デフォルトの名無しさん
2010/05/26(水) 22:23:47defaultのログにブランチの細かなコミットログ要らないよなーって思うんだけど、
オプションはどれなんだ！
0258252
2010/05/27(木) 00:48:34>>254
>>255
>>256
皆様ありがとうございます。
とても参考になりました。
convertというのを調べてみたら拡張機能のようですね。
やはり基本はリポジトリをまとめて扱うべきなのかな。
なるべく小さい単位で管理するというのは勉強になりました。
ここら辺はsubversionと思想が逆ですね。
0259デフォルトの名無しさん
2010/05/27(木) 13:29:29hg log --only-branch
0260デフォルトの名無しさん
2010/06/16(水) 02:32:03ステータス：Aのものがshelveできない。
あと、rollback時。
tipで改造してshelveしてまた改造してロールバックしてshelveに戻すと
ファイルのバージョンがshelve時点と異なる。
0261デフォルトの名無しさん
2010/06/16(水) 09:25:19最近の亀hgはMQもびっくりするくらい楽に扱えるからな。
0262デフォルトの名無しさん
2010/06/17(木) 02:02:270263デフォルトの名無しさん
2010/06/18(金) 03:21:170264デフォルトの名無しさん
2010/06/18(金) 07:19:000265デフォルトの名無しさん
2010/06/18(金) 08:16:58あと亀バザーとかいろいろ先輩もいるかららしいよ。
0266デフォルトの名無しさん
2010/06/18(金) 20:23:17http://groups.google.com/group/thg-dev/browse_thread/thread/f11df410861fbe53#
0267デフォルトの名無しさん
2010/06/20(日) 07:31:190268デフォルトの名無しさん
2010/06/20(日) 09:48:10MQそのものの使い方はさておき、bitbucketにMQだけforkできて容量節約できると思う。
githubで同じことできる？
0269デフォルトの名無しさん
2010/06/20(日) 14:44:46そういうちょっとしたことをやるのには重宝してる。
あと、他の人のパッチとのマージ前に自分のところで作業するときに
パッチが２個あるとどっちがどっちかわからなくなるけど
明示的に２つのコミットに分離されていると変更点がすぐわかる
が細かいところで作りこみが甘い
たとえば最初にコミットした場合には[mq]ってタイトルに自動的について
ＭＱだとわかるのに
一回はずしてまた再適用するとImportedとか違うタイトルになるし
ＭＱをコミット化するとメッセージが変えられないし
そもそもパッチにコメントつけたいけどパッチ名とコメントが一緒なのであれだし
とかゆいところに手が届かないが、最初の２点が便利なので
ほどほどに使ってる。
gitの場合コミットのやり直しができるのでこういう機能はいらないんだろうけど
Mercurialはサクサク動くし自分には直感的に感じるのでＭＱオフィシャル化はありがたい。
0270デフォルトの名無しさん
2010/06/21(月) 10:17:28> ＭＱをコミット化するとメッセージが変えられないし
コミット化っていうのがqfinishのことだったら、qimport -r tipで取り込ん
でqrefreshでメッセージ変えてqfinishすればいいと思うけど違うの?
0271デフォルトの名無しさん
2010/06/22(火) 03:39:100272デフォルトの名無しさん
2010/06/22(火) 07:30:570273デフォルトの名無しさん
2010/06/22(火) 07:50:19stripを提供しているのはMQそのもの
0274デフォルトの名無しさん
2010/06/22(火) 10:10:16gitよりは簡単だよ。
0275デフォルトの名無しさん
2010/06/22(火) 10:29:00いろんなことが出来るってのは分かるけど、その分怖いよね。
hgはMQが別になっているし、無効にも出来るから安心。
0276デフォルトの名無しさん
2010/06/29(火) 04:57:57右クリックメニューからファイルを追加しようとするとウィンドウが凍りつく。
そのまま強制で閉じてみたら
'utf8' codec can't decode byte 0x8e in position 12: unexprected code byte
とかいう感じのエラーが表示される。
ttp://bitbucket.org/stefanrusek/hg-fixutf8/src/tip/README
なんかには
... Shell integration does not work perfectly, since ...
とか書いてあるけど、そうゆこと？
それとも、なんか俺っちの設定が不完全なの？
Torotise-HG は 1.0.4
hg-fixutf8 は以下のをつかってます。
@ changeset: 16:baf283ab9f92
| tag: tip
| user: Stefan Rusek <[email protected]>
| date: Mon Apr 12 23:11:41 2010 +0200
| summary: Disable fixutf8 translations when the console does not have a CP associated with it.
0277デフォルトの名無しさん
2010/06/29(火) 07:29:140278デフォルトの名無しさん
2010/07/02(金) 09:48:330279デフォルトの名無しさん
2010/07/02(金) 12:05:15fixutf8はもう死んでるので・・・
0280デフォルトの名無しさん
2010/07/02(金) 17:53:060281デフォルトの名無しさん
2010/07/03(土) 01:26:270282デフォルトの名無しさん
2010/07/03(土) 07:51:03これで日本人は幸せになれる？
0283デフォルトの名無しさん
2010/07/04(日) 01:20:12いや、ファイルパスはバイト列というのはMercurialの方針であって、
Python3でも変わらない。
BazaarはファイルパスをUnicode文字列として扱ってるから、
Python3になると実装が楽になりそうだけど。
0284デフォルトの名無しさん
2010/07/13(火) 15:16:460285デフォルトの名無しさん
2010/07/18(日) 16:54:57Windowsで作ってた中のファイル名がSJISで格納されているリポジトリのファイル名を
UTF-8のファイル名に修正したいのですがいい方法ないでしょうか？
0286デフォルトの名無しさん
2010/07/18(日) 17:13:38http://mercurial.selenic.com/wiki/FixUtf8Extension
0287デフォルトの名無しさん
2010/07/18(日) 18:31:14サンクス
これでいけそうです
.hgrcでの[extensions]の指定で、
パス区切りを\にするとhgコマンドで、
*** failed to import extension fixutf8 from (パス名)\fixutf8.py: No module named win32helper
とエラーがでてしまうので、/で指定したらいけました
0288デフォルトの名無しさん
2010/08/02(月) 13:59:160289デフォルトの名無しさん
2010/08/03(火) 07:45:380290デフォルトの名無しさん
2010/08/03(火) 16:19:540291デフォルトの名無しさん
2010/08/03(火) 16:23:500292デフォルトの名無しさん
2010/08/03(火) 16:32:16stableにタグが付いていないし、mpmは 時差-05だからネタじゃない？
0293デフォルトの名無しさん
2010/08/03(火) 16:46:530294デフォルトの名無しさん
2010/08/12(木) 13:14:05http://mercurial.selenic.com/wiki/Py3kPort
0295デフォルトの名無しさん
2010/08/21(土) 15:36:41ゴミbranchをhg branchesコマンドに表示しないようにしたいのです。
ちょこっと作業にbranch切りたいのですが
削除できないからリポジトリ汚すのが嫌なので
結局cloneすることになるんですよね。。
0296デフォルトの名無しさん
2010/08/21(土) 15:57:30なんかいろいろとやり方はあるみたいだよ
http://mercurial.selenic.com/wiki/PruningDeadBranches
0297デフォルトの名無しさん
2010/08/21(土) 16:15:28hg branches で表示させないことが目的なら close が一番。
ってwiki見たら一番になっていた。
ちょこっと作業が目的ならMQ。
0298デフォルトの名無しさん
2010/08/21(土) 16:41:010299295
2010/08/21(土) 19:08:32>>297
ありがとうございます。素晴らしいサイトですね。
参考にさせてもらいます。
gitに乗り換えようとも思ってたけどまだ早まらなくてもよさそうだ
0300デフォルトの名無しさん
2010/08/21(土) 21:50:41gitの場合まずローカルブランチを作ってだから余計に感じるかも。
bookmarkという拡張があるからMQよりもこっちの方がいいかもしれない。
0301デフォルトの名無しさん
2010/08/27(金) 08:09:130302デフォルトの名無しさん
2010/08/27(金) 12:15:220303デフォルトの名無しさん
2010/08/27(金) 12:21:40日本語Windows(cygwin除く)に限った話では、
Mercurial本体とToritoiseHgのpython部分についてはwin32mbcsとfixutf8の拡張で使えます。
ファイル名はバイト列なので、Unix/Linuxでは問題ありません。
Macはまた別の問題があるようです。
0304デフォルトの名無しさん
2010/08/27(金) 12:42:31Unix/Linuxだって、UIMがかな漢字変換の結果NFD/NFCのどっちを端末に送るかなんて
決まってないんじゃないか。たまたま揃ってるから上手く行ってるだけだろ。
0305デフォルトの名無しさん
2010/08/27(金) 13:17:430306デフォルトの名無しさん
2010/08/27(金) 13:26:480x5c問題についてはshift-jisとbig5が対象ですが、
fixutf8については全世界が対象なので、こちらをどうするかは課題でしょう。
0307デフォルトの名無しさん
2010/08/27(金) 14:27:10のExisting problemsってところで、
> There are some python 3 APIs that only support (unicode) string arguments
略
> All of them must be of the string type.
ってあって、そこまでUnicode嫌いか？って思ってしまう。
0308デフォルトの名無しさん
2010/08/27(金) 15:13:24Unicodeは悪ともいえる存在じゃないか。
0309デフォルトの名無しさん
2010/08/27(金) 16:58:47> Unix/Linuxだって、UIMがかな漢字変換の結果NFD/NFCのどっちを端末に送るかなんて
> 決まってないんじゃないか。たまたま揃ってるから上手く行ってるだけだろ。
Mercurialはinodeに書かれたバイト列としてのファイル名を
.hg以下の*.iに素直に書いているだけですが。
0310デフォルトの名無しさん
2010/08/27(金) 17:13:01だから、他のIMと違うがUTF-8としてはValidなエンコーディングを吐くIMがひとつ混じったら
Macと同じ問題がLinuxでも出るだろって話なんだけど
0311デフォルトの名無しさん
2010/08/27(金) 18:35:29それってIMの問題であってMercurialの問題じゃないんじゃないですか？
0312デフォルトの名無しさん
2010/08/27(金) 18:45:080313デフォルトの名無しさん
2010/08/27(金) 18:51:34これを同じファイルとして扱えいう主張ですか？
ならば、"AAA.txt","aaa.txt","AAa.txt"を全部同じファイル名として扱わないといけないのですか？
0314デフォルトの名無しさん
2010/08/27(金) 18:54:030315デフォルトの名無しさん
2010/08/27(金) 19:02:33ちょっとまて、独立した濁点は元々「別の文字」扱いだろw
合成用の濁点は独立した濁点とは別だw
……ってか、>>314後は任せた俺はもう知らん。
0316デフォルトの名無しさん
2010/08/27(金) 19:50:50# -*- coding: utf-8 -*-
import unicodedata
nfc = unicodedata.normalize("NFC", u"が")
nfd = unicodedata.normalize("NFD", u"が")
print nfc
print nfd
open(nfc,"w")
open(nfd,"w")
$ python test.py
が
か
$ find .hg/store/data/
.hg/store/data/~e3~81~8c.i
.hg/store/data/~e3~81~8b~e3~82~99.i
0317デフォルトの名無しさん
2010/08/27(金) 19:53:190318デフォルトの名無しさん
2010/08/29(日) 15:13:14e3 81 8c と e3 81 8b e3 82 99 を別々のファイル名として扱える。
もしbzrのようにUTF-8とみなすとそれらを別々のファイル名として扱えない。
ext3などは大文字小文字を区別するけど、FATは大文字小文字を区別しない、
というのも似た問題である。
と>>313は言いたいんだろう。
ファイル名をUTF-8として扱うオプションくらいあってもいいと思うけどな。
0319デフォルトの名無しさん
2010/09/01(水) 18:11:22Linuxの開発に使うことが第一義のgitならともかく……。
0320デフォルトの名無しさん
2010/09/01(水) 18:18:10あとファイル名をUnicodeとして扱うのと正規化するのは別の話
0321デフォルトの名無しさん
2010/09/02(木) 08:36:250322デフォルトの名無しさん
2010/09/02(木) 09:41:27FATは8.3形式とそれ以外の違いがある。
FATのロングファイルネームとNTFSは大文字・小文字を区別はする。
でも、AAA.txt がすでにある場合、aaa.txt は作れない。
0323デフォルトの名無しさん
2010/09/02(木) 09:45:00確かこの対応で、Mercurialは1.1でリポジトリフォーマットがマイナーチェンジしている。
0324デフォルトの名無しさん
2010/09/02(木) 09:47:12ファイル名のバイト列を保つんだ！ってのが無理な話のような
0325デフォルトの名無しさん
2010/09/02(木) 10:05:270326デフォルトの名無しさん
2010/09/02(木) 10:56:520327デフォルトの名無しさん
2010/09/02(木) 11:05:12Explorerで作成ができないだけで、それ以外は問題ないと思うけど。
0328デフォルトの名無しさん
2010/09/02(木) 12:41:42LinuxのFATのマウントオプションもいろいろある。
sambaも細かく大文字・小文字を制御できたはず。
このようなことを、VCSがやるべきかやるべきでないか、だと思う。
0329デフォルトの名無しさん
2010/09/02(木) 13:08:08> そりゃあ128文字あれば十分事足りてしまう連中にとって
> Unicodeは悪ともいえる存在じゃないか。
欧米人にとって、UTF-16は２倍、UTF-32は４倍になる。
このデメリットを持ち出されると・・・
UTF-8は欧米人にとっては非ASCIIだけが２バイトになるからそこそこ受け入れらていると思う。
0330デフォルトの名無しさん
2010/09/02(木) 17:19:03何も考えないなら考えないで、単に「何も考えてませーん」でいいとも思うんだよな……。
(その場合bzrに大きく劣っているのを認めることになるが)
なんか無理して>>307みたいにファイル名=バイト列を貫こうとしてる気がする。
0331デフォルトの名無しさん
2010/09/03(金) 01:17:06独仏ですらアクセント付き記号を使うし、東欧を含めると Latin-1 には収まらないし。
アメリカだけでも、ユーロ記号やコピーライト記号が入ってくるとね。
■ このスレッドは過去ログ倉庫に格納されています