バージョン管理システムについて語るスレ

1 名前：デフォルトの名無しさん [2007/10/26(金) 02:15:00 ] バージョン管理システムについて語りましょう。 関連スレ CVS 1.3 [UNIX板] pc11.2ch.net/test/read.cgi/unix/1093611448/ CVS導入スレ〜 Rev.3 [プログラム板] pc11.2ch.net/test/read.cgi/tech/1113141518/ Subversion r7 [プログラム板] pc11.2ch.net/test/read.cgi/tech/1180858500/ 528 名前：デフォルトの名無しさん mailto:sage [2008/04/09(水) 15:40:54 ] >>527 本当だ、u にアクセントがある。 ttp://dictionary.goo.ne.jp/search.php?kind=ej&kwassist=1&mode=0&ej.x=1&ej.y=1&MT=Mercurial 「マーキュロ」に似た感じで発音すればいいのかな。 529 名前：デフォルトの名無しさん mailto:sage [2008/04/09(水) 16:03:13 ] メルクリアルだとばっかり 530 名前：デフォルトの名無しさん mailto:sage [2008/04/09(水) 20:48:51 ] Mercurial って、バイナリファイルの保管は効率的でないの？ まぁ svn でも過剰な期待をしているわけではないんですが。 531 名前：デフォルトの名無しさん mailto:sage [2008/04/09(水) 20:57:47 ] マテリアルと同じ感じでマキュリアルかな。 532 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 01:12:26 ] >>530 自分の経験では、 MS Access の MDB ファイル(300KB)を修正しながら 6回チェックインしてリポジトリのサイズが 200KB くらいです。 元ファイルより小さいってことは、初期バージョンを 圧縮して格納しているのでしょうか？ 533 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 01:39:42 ] git 使ってみたけどリビジョンがないのが面倒に思えた。 実際に使ってる人は不便に感じない？ 534 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 09:39:52 ] >>533 リビジョンの使い道ってどんな時があるでしょうか？ headやhead^,head~2しか使ったこと無いので… 535 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 11:59:15 ] 533じゃないけど、バージョン番号に入れたとき長いと人が覚えきれないとかw 536 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 12:45:57 ] Mercurial を単独で使い始めてみました。 JapaneseTutorialや、有益なサイトの説明を読んでもみました。 お手軽さはぴかいちですね。 ちょこっと修正履歴を残しておきたい場合など、本当にあっという間に環境が整いますね。 まだまだ使い込みが足りませんが、分散システム故の運用の難しさを感じています。 ・本流はどれだろう？ ・現時点の最新はどこ？ ・自分は今どの位置にいるの？ etc・・・ やっぱり中央リポジトリみたいなものは用意されるんでしょうか？ こまめにマージとかもされてるんでしょうか？ ん〜 537 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 13:06:52 ] >>533 > git 使ってみたけどリビジョンがないのが面倒に思えた。 > 実際に使ってる人は不便に感じない？ うはｗ　俺といっしょｗ 俺もGit使い始めの頃に同じ質問をしたら「リビジョンがあったら何が嬉しいの？」って言われたｗ たぶん使ってるうちに必要ないなと思うようになると思うよ。 実際気軽にフォークできるから、あんま意味がなくなっちゃうんだよね、番号は。 プロジェクトの公開リポジトリなら自動で番号振っても良いような気もするけど、 まあタグで事足りるんだよなぁ。 どちらかというと「番号が年上かどうか」で知りたかったことは「いま見ているブランチに どのコミットが含まれている（いない）か」のほうが重要だから、git show-branchを 俺は多用しています。 538 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 13:38:52 ] Subversion 使ってて、まっすぐ増えてくリビジョン番号が無いと困りそうなんだが、 要らなくなるもんなのか？ たとえばこんなの。 ・バグレポートがいつの時点のものなのか？ ・バグ修正がリポジトリ内のどの時点で行われたのか？ ・テストを実行しているのはどの時点の実行ファイルなのか？ 全部リビジョン番号で示してれば、以前に報告したバグが今回のテストで 修正確認できるかどうか、すぐにわかるんだが。 539 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 13:47:33 ] svn使ってるけど、その手の管理でrev番号を必要とした記憶が無い 540 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:06:54 ] rev XXXXで・・・って表現の仕方はよくするかな 541 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:31:09 ] >>538 リリースするときバージョンつけないの？ 542 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:33:28 ] 短い番号ってのは自分が把握するのにも人に伝えるのにもわかりやすくて便利だと思う 200804101426みたいなタイムスタンプでもいいけど 何かの暗号みたいなハッシュはちょっととっつきにくい感じ･･･ 543 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:37:44 ] >>541 つけないね。開発と同じフロアにテストする人が居て、少なくとも日に一回ってペースで 実行ファイル更新するから、毎回つけるとなるとちょっと面倒。 それに、リリースにバージョンつけても、そのバージョンで特定のバグが直ってるかどうか すぐに（リビジョン番号の大小ぐらい簡単に）判別はできないんじゃない？ 544 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:41:39 ] それって、その日解決されたレポート番号一覧を出せばいいんじゃないの？ というか、テストチームに対して、dailyで実行ファイルを更新するという環境が想像できないのだが・・・ 545 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:44:01 ] 普通は、「この問題は、（マイルストーン名｜タグ名）で解決される」って感じで、 BTSに登録するんじゃないの？ 546 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 14:57:26 ] bugtraq:*使ってないだろ？ 547 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 17:03:01 ] つーか、BTS使ってないんじゃね？ 548 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 17:03:50 ] >>543 リビジョン番号を見てバグが直ってるかどうか判別できるって事のほうがすごいと思うんだが。 毎日テストチームにバイナリリリースするってことはけっこう変更がたて込んでるってことだよね。 俺はSubversionも使ってるけど、リビジョン番号聞いて「あーそれ古い」なんて言えない。 コミットされる度にインクリメントされる番号なんて憶えてられないし印象にも残らない。。。 リリースしてるならバージョンが付くはずだし、その時には変更履歴が付くからそれで分かる、 リリースしてないなら、リビジョン番号があろうと無かろうとログを見て判断するしかないと思う。 549 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 17:15:48 ] というか、テスターが勝手にcoなりexportなりして、修正されたバグがないかどうか 調べて、あればそれをテストする、という混沌とした現場なんじゃ。 550 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 17:17:20 ] テストチーム（個人？）って、そのときfixされたバグだけを確認してるわけじゃなくて、 リグレッションテストもするはずだから、頻繁にリリースされても困ると思うけど 551 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 17:28:56 ] いわゆる「リリース」じゃないんだよ、きっと 552 名前：いろんな現場を体験したことのあるマ mailto:sage [2008/04/10(木) 17:45:27 ] リグレッションテストなんて　ここぞ！　という時以外あまりやらないな・・・ 細かなバグ対処リリースでは無視無視 運用方法に依るんだけどね・・・ 553 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 17:48:39 ] プログラマならともかく、テスターがリグレッションテストやらないのは問題だろ・・・ 554 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 19:26:27 ] リビジョン番号の代わりにタグをうつ事をするようにしたら 修正の順番が分かるようになると思う。 今まで番号でやってきたのが変だった、ということか？ 555 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 20:43:27 ] >>536 > ・本流はどれだろう？ Mercurial では、すべてのリポジトリが対等で本流です。 …が、どれかを本流にし、全ユーザーがそこから clone すれば 中央リポジトリ的な使い方ができます。 > ・現時点の最新はどこ？ リビジョンに「tip」と表示されるのが、そのリポジトリでの最新です。 hg tip で表示できます。 ブランチが複数あった場合には、それぞれの最新が head と呼ばれ、 hg heads で表示できます。 わからなくなったら hg glog をすると、わかりやすく（？）表示されます。 > ・自分は今どの位置にいるの？ 上の hg glog のほか、hg stat -v でリビジョンが表示されます。 hg parents で、現在のワーキングディレクトリの元リビジョンが表示されます。 556 名前：デフォルトの名無しさん mailto:sage [2008/04/10(木) 20:48:37 ] リビジョン番号は前後関係がわかるのでよい。 ハッシュは長すぎて覚えられないし。 monotoneのマニュアルには、補完できるように シェル弄れみたいなことが書いてあったが、 そんなのめんどくせえよ、と思った。 darcsは半分ズレがあるので却下。 bzrが一番よい。-1とか分かりやすいしシンプル。 557 名前：533 mailto:sage [2008/04/11(金) 00:56:32 ] >>537 リリースサイクルが長い開発で使用するとなると公開（メイン）リポジトリでは 定期的にタグを打たないと駄目そうかな まだ個人使用だし考えていてもしゃあないのでまず使ってみる >>556 ＞ハッシュは長すぎて覚えられないし。 先頭 4 文字から絞ってくれるよ。 4 文字だと重複する可能性は少し高いだろうけど 558 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 00:57:08 ] www.moongift.jp/2008/04/git_gui/ Git の GUI ツールが紹介されてた 559 名前：538 mailto:sage [2008/04/11(金) 01:22:41 ] うわ。なんかダメな子みたいになってる。 何か重要な概念が欠けてるのかもしれないけど、いちおう返答してみる。 >>544 一覧を「出せばいい」じゃなくて、「出さないといけない」ってことにならない？ めんどくさくね？ リビジョン番号で示してればそれは要らないんだ。少なくともそう思ってる。 修正するときは「rXXXX で修正」で、テスト用の実行ファイルを更新するときに 「rXXXX でビルドしたもの」って伝えれば済む。未確認のバグのうち、テスト中の リビジョン番号より小さい番号で修正を入れた問題の動作を確認してもらう。 >>548 たとえば r100 のテストで見つかった２つの問題に対してそれぞれ r105 と r108 で 修正を入れたとして、次のテストが r107 で行われた場合は前者だけ動作確認して もらえるってことがわかる。 560 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:31:23 ] いやだから、テスターに「bugid 78,80を修正したから」って伝えれば済むんじゃねってことなんだが。 テスターがリポジトリの更新履歴でも見て、何が修正されたかいちいち調べるのか？ 561 名前：538 mailto:sage [2008/04/11(金) 01:35:27 ] >>560 「rXXXX で修正」って BTS に書き込む（そのときにメールも飛ぶ）から、 いちいち別でまとめてバグ ID 伝えたり、リポジトリ見て調べたりしなくていい。 562 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:35:36 ] >>559 BTS使ってる？ 使ってるなら、何使ってる？ プログラマは何人くらいいるの？ テスターは何人くらいいるの？ 563 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:35:38 ] 分散vcsだと結構ブランチが気軽に作れちゃう分リビジョンだと混乱しそう。 いいとこ取りのbzrはその辺どうやって解決してるの? ユーザー間のチェンジセットとかも考慮できるようだが今のところ興味よりもﾏﾝﾄﾞｸｾが勝る。 中央リポジトリばかりで開発するようなスタイルだとそこにリビジョンはあってよいと思う。 564 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:37:19 ] >>561 だったら、BTSのステータスが「修正済み（未確認）」のものをテストすればいいわけで、 リビジョン番号はおろか、タグも必要ないよね？ 565 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:41:15 ] >>559 そこまで理解してくれるテスターがいる事に嫉妬。 こっちはマにリビジョンxxxで〜って言って、 「リビジョンって分からないんですけど？」って後で質問が来る世界だ・・・orz 566 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:43:52 ] まさかとは思うが、ひょっとして、ビルド済みバイナリをテストチームに渡したりしてないよな？ 567 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:49:16 ] つーか、根本的に破たんしてる気がする。 ひょっとすると、プログラマ一人、テスター一人で、デバッグレベルのテストをやってもらってるのだろうか。 それなら頻繁なテスト依頼が行われるというのも理解できる。 568 名前：538 mailto:sage [2008/04/11(金) 01:57:20 ] >>564 >559 の最後の例では、 r108 で修正したバグのステータスは「修正済み」になるけど、 r107 をテストしてるときにそいつの動作確認はまだできないと区別できる。 569 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 01:57:57 ] よそで自分の意に沿わない運用がなされたとしても、それがなんだと言うんだろう？ そこではリビジョンさえあればうまくいってると言ってるんだから、外野がごちゃごちゃ 言う必要無いよ。 何がしたいの？やりこめたいの？ 570 名前：538 mailto:sage [2008/04/11(金) 02:02:36 ] 悪いけどテスト環境について議論するつもりはないから、リビジョン番号の有用性に 関すること意外はスルーさせてもらうよ。 「リビジョン番号の無いバージョン管理システムでも、こういうテスト体制なら問題ない」 と紹介してくれるんなら歓迎。 571 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:04:07 ] 何で上から目線なんだ 572 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:05:05 ] >>570 だーかーらー、解決されたbugid一覧をテスターに渡せばいいじゃんか。 やりたくないの？ 573 名前：538 mailto:sage [2008/04/11(金) 02:07:48 ] >>572 もちろん。めんどくさいじゃないか。リビジョン番号さえあれば済むんだから。 574 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:08:13 ] じゃぁ、svnに戻せよ。 アホか 575 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:09:08 ] BTSに、修正リビジョンを書くことが、なんで破綻してるとかって話になるんだ？ いつ何を修正したか記録するのは当然だと思うんだが…。 576 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:12:11 ] >>575 いや、破綻してると思ったのは、開発プロセス全体がってことで、BTSに修正した リビジョンを書くのは問題ない。 プロセスに関しては議論したくないみたいだから、俺は消える。 577 名前：538 mailto:sage [2008/04/11(金) 02:13:21 ] >>572 もしかして、リビジョン番号の無いバージョン管理システムでは リポジトリ内のある時点からある時点までの間に「解決されたbugid一覧」を 作るための機能がついてるの？ そうじゃなけりゃ >572 の言い方は、リビジョン番号がなくなると（538的な意味で） 不便になる点があるってのを言ってくれてることになる。 578 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:14:37 ] 575書いたあとに570とか読んでちょっと馬鹿馬鹿しくなった（´・ω・｀） >>570 リビジョンのないVCSなら素直にタグ打てば済む話だと思う。 分散VCSの性質上、連続したリビジョンが付けられないのは当然だろう。 579 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:18:01 ] >>577 だーかーらー、タグ使うか、おまえが一覧作れって。 タグ打つのもいやで、svnでうまく回ってるなら、svnでいいだろうが。 お前は一体何がしたいんだ。 580 名前：538 mailto:sage [2008/04/11(金) 02:18:50 ] 仮に今回挙げたテスト体制をリビジョン番号の無いシステムに移すとすれば、 テストするバージョンにタグをちゃんと打つこと、タグ間で修正されたバグの一覧は 別で作成すること、が必要になるってことだね。 ひととおり納得したよ。ありがとう。 570 の書き込みは、正直スマンカッタよ。 581 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 02:21:11 ] なぁ、各VCSのcook book的なものを一通り読んでから議論しても遅くなかったぞ。 582 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 07:58:28 ] これはひどい 583 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 08:16:08 ] ゆとりに構ってスレの無駄使いは止めましょう 584 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 08:51:11 ] コミットログちゃんと書けば済む話ジャネーノと思った 585 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 13:51:41 ] >>557で＞まだ個人使用だし考えていてもしゃあないのでまず使ってみる って書いてるしそれでいいんじゃないかと思うけどね。うまく説明できないのは少し残念だが。 俺も最初番号が無いのに戸惑ったけど、使ってるうちにリビジョン番号は必要ないなって 思うようになった。 586 名前：デフォルトの名無しさん mailto:sage [2008/04/11(金) 19:02:31 ] 538には必要なんだよ 587 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 02:02:48 ] Subversionのリビジョン番号は、その時点のリポジトリ全体の状態を決定するけど、 gitやMercurialのハッシュ値はそのチェンジセットを表してるだけなんだな。 この辺の考え方の違いに気づくまでわかりづらかった。 588 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 10:59:32 ] 全体で一貫したリビジョン番号である svn は、リリース時のバージョン�ｕt与する時に便利だったんだよね V1.0.2553 とか　３番目をリビジョン番号使ってたんだけど、 Mercurial を使ったとしても、各リポジトリでリビジョン番号は合ってないから無理だな・・・ ハッシュ値は付けられんし・・・、ちょっと考えないといけないな。 589 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 13:06:40 ] >>588 つ[日付] 590 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 13:18:20 ] 適材適所で Subversion 使えばいいじゃん。 ただしリビジョン番号に依存した運用は、 dump → restore したときに番号が変わると破綻する。 591 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 15:22:59 ] ほんとタグ付けのが嫌いなやつが多いな。 それとも、そんなに頻繁にリリースるのが流行ってるのか？ 一週間に一回なら、手動でリリースタグ打ってもたいしたことないだろ。 デイリーなら日付入りな。 それ以上頻繁なリリースなら・・・知るか。 592 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 18:09:10 ] 自分はリリースごとにタグ打ってるけど、 それぞれ好きでいいんじゃないだろうか。 593 名前：デフォルトの名無しさん mailto:sage [2008/04/14(月) 14:09:29 ] いや、多分集中レポジトリ使ってると タグうつ権限とかも運用上集中管理してて大変だというイメージがあるんじゃなかろうか？ やっぱ、運用がごろっと変わると大変なんだろうけど その辺りの共通認識がここで話をしてる人の間でないから話が食い違うんだろう。 594 名前：デフォルトの名無しさん mailto:sage [2008/04/16(水) 23:00:10 ] いままで CVS をひたすら使ってて、Subversion に移行しつつあったけど、 Mercurial というのを知って、こちらに本格的に移行することにしました。 あとは、Xcode が Mercurial に対応してくれたらなぁ。 595 名前：デフォルトの名無しさん [2008/04/18(金) 02:07:37 ] >>470 kwsk!! メインがsvnでも、自分のとこ？（というかクライアントマシン？）だけ 分散型でいけるの？ 参考になるページとかないですかね >>591 それこそ、svnならタグ付ってメッチャ早かったとおもうけどｎ・・・ 596 名前：デフォルトの名無しさん mailto:sage [2008/04/18(金) 09:57:54 ] >>595 詳しくないけど答えてみる。 svnリポジトリからcoした作業コピーを、ローカルでgitみたいな別のツールで管理する ことはできるんじゃないか？ svn co ほげ git init git add . git commit -a 編集 以下、リモートとやりとりするときはsvn、ローカルではgitと、使い分ければいいような。 以上、妄想でした。 597 名前：デフォルトの名無しさん mailto:sage [2008/04/18(金) 14:34:10 ] >>595-596 git-svn を使うって話じゃないの? 598 名前：470 mailto:sage [2008/04/18(金) 15:59:09 ] >>595 >>597の言うようにgit-svnでやってますえ。 中央のSubversionリポジトリとローカルのGitリポジトリをマージしながら 使うようなイメージ。 けれど中央をsvnしてるぶん、つねにsvnにくっついていかないといけないのが ちょい面倒に感じるけど、まあ仕方ないかな。 >>596 そんなやり方でも出来そう！って思ったけど、svn upした時に上書きされて泣いたりとか しそうだな。。。git-svnならsvn upの代わりにrebaseを使うので、いい感じです。 599 名前：デフォルトの名無しさん [2008/04/18(金) 16:42:47 ] hgsvnにバグがある aというディレクトリがあって、その中にfoo.txtっていうファイルがある。 aをbという名前でコピーしてコミット。 b/foo.txtをsvn rmで削除して、a/foo.txtをbの下にコピーしてコミット。 こうやって作ったsubversionのリポジトリからhgimportsvnとhgpullsvnを使うと a/foo.txtが削除された状態(hg stで?が付く)になってしまう 600 名前：デフォルトの名無しさん [2008/04/18(金) 17:20:50 ] ちなみに、開発者にはメールで報告済みだが、連絡・修正はない 601 名前：デフォルトの名無しさん mailto:sage [2008/04/20(日) 14:40:35 ] Mercurial のマージの概念がよくわかりません 同じリポジトリ内の複数リビジョンの間でしかマージできない？ それとも､過去に hg clone して派生したリポジトリ間でしかマージできない？ 同一リポジトリ内の tip リビジョンのファイルとコミット前のファイルのマージはできないのでしょうか？ そのとき、ファイル名は指定できませんか？ ファイル構成がほとんど同じだが過去に hg clone では派生していない 2 つのリポジトリ間ではマージできないのでしょうか？ 例えば､ディレクトリコピーなどで複製され、それぞれのディレクトリで 1 回目の hg commit を実行した場合など 602 名前：デフォルトの名無しさん mailto:sage [2008/04/22(火) 17:17:40 ] >>601 >>601 Mercurial では無関係なリポジトリ同士でマージができる。 ちょいと長いけど、以下、やってみたのを貼ってみる。 たとえば2つのリポジトリ、repo1 と repo2 を作成する。 （TortoiseHG 付属の hg で実行） > mkdir repo1 > hg init repo1 > mkdir repo2 > hg init repo2 repo1 には A.txt を作成する。 > cd repo1 repo1> echo A >A.txt repo1> hg add A.txt repo1> hg commit repo2 には B.txt を作成する。 repo1> cd ..\repo2 repo2> echo B >B.txt repo2> hg add B.txt repo2> hg commit 続く。 603 名前：デフォルトの名無しさん mailto:sage [2008/04/22(火) 17:18:03 ] 続き。 repo2 に repo1 の内容をマージする。 hg pull に -f オプションを付けるのがミソ。付けないとエラーになる。 repo2> hg pull -f ..\repo1 pulling from ..\repo1 searching for changes warning: repository is unrelated adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) 結果的に、repo2 内に2つの head（ローカルブランチ）ができる。 repo2> hg heads changeset: 1:74581af5a0ee tag: tip parent: -1:000000000000 user: hoge date: Tue Apr 22 16:43:54 2008 +0900 summary: Initial. changeset: 0:f58274ede46b user: hoge date: Tue Apr 22 16:44:23 2008 +0900 summary: Initial. 続く。 604 名前：デフォルトの名無しさん mailto:sage [2008/04/22(火) 17:18:16 ] 続き。 ブランチをマージする。 repo2> hg merge tip 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) repo2>hg commit repo2>hg update （同名ファイルがあった場合には、内容を編集しなければいけない。 いわゆるマージ・コンフリクト） するとローカルに A.txt と B.txt ができるので、無事に2つのリポジトリが合成されたのがわかる。 Mercurial のリポジトリは対称なので、repo1 では repo2 から pull すればいい。 ただし、repo2 には「repo1 と合成した」という記録が残っているので、-f は必要ない。 repo1> hg pull ..\repo2 でいける。 605 名前：デフォルトの名無しさん mailto:sage [2008/04/23(水) 23:32:12 ] >>602 サンプル付きでありがとー 今度試してみます じゃあ、ファイル中の一部分を差分比較対象から除くことはできますか？ 例えば、RCS/CVS/Subversion のキーワード置換 ($Revision とか) みたいな 内容が異なる可能性があるけど、差分としては検出して欲しくない部分 606 名前：605 mailto:sage [2008/04/23(水) 23:33:30 ] そういえば、Subversion でもキーワード置換以外に ファイル内の一部分を差分比較対象から除く方法を知らない… 607 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 13:09:57 ] >>605 KeywordExtension というのがあります。 「どのファイルの」「どんなキーワードを」「何にする」というのを指定できます。 www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension リポジトリ中のファイルにはキーワードが未展開で（$Id$ とか）格納され、 ワーキングディレクトリに取り出すと展開型（$Id: hoge.txt 2008/04/24 moge$ とか）に なります。 608 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:56:48 ] >>605 実際にやってみたので、ちょっと長いけど貼ってみる。 まず、リポジトリ repo1 を作成する。 >hg init repo1 >cd repo1 ここで以下の内容で repo1\.hg\hgrc というファイルを作成する。 *.txt でキーワード展開せよ、という指示をしている。 [extensions] hgext.keyword= [keyword] *.txt= [keywordmaps] キーワードは最後の [keywordmaps] の後に書き込む。 $Id$ は書かなくてもキーワード登録されているので、 今回はそれを使用する。 続く。 609 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 16:59:23 ] 続き。 test.txt というファイルを作成し、リポジトリに追加する。 >echo $Id$ >test.txt >echo テスト。 >>test.txt >hg add test.txt >hg commit -m "Add test.txt." この時点ですでに $Id$ がキーワード展開されている。 >type test.txt $Id: test.txt,v c5c7047c9e51 2008/04/24 07:38:09 maru $ テスト。 次に test.txt に変化を与える。 >echo 追加。 >>test.txt >type test.txt $Id: test.txt,v c5c7047c9e51 2008/04/24 07:38:09 maru $ テスト。 追加。 続く。 610 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 17:00:06 ] 続き。 変更は Mercurial に認識されるが、キーワードは変更から無視されている。 >hg stat M test.txt >hg diff test.txt diff -r c5c7047c9e51 test.txt --- a/test.txt Thu Apr 24 16:38:09 2008 +0900 +++ b/test.txt Thu Apr 24 16:38:35 2008 +0900 @@ -1,2 +1,3 @@ $Id: test.txt,v c5c7047c9e51 2008/04/24 07:38:09 maru $ テスト。 +追加。 コミットすると $Id$ の内容が更新される。 >hg commit -m "Add a line to test.txt." >type test.txt $Id: test.txt,v 1ebd174ad8f0 2008/04/24 07:38:35 maru $ テスト。 追加。 続く。 611 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 17:00:49 ] 続き。 前のリビジョンとの差分を取ってみる。やはりキーワードは無視されている。 >hg diff -r 0:1 test.txt diff -r c5c7047c9e51 -r 1ebd174ad8f0 test.txt --- a/test.txt Thu Apr 24 16:38:09 2008 +0900 +++ b/test.txt Thu Apr 24 16:38:35 2008 +0900 @@ -1,2 +1,3 @@ $Id$ テスト。 +追加。 長々とスレ汚しスマソ。 612 名前：デフォルトの名無しさん mailto:sage [2008/04/24(木) 21:34:24 ] 駄目なレポートの典型だな。 まず結論を書け 613 名前：608 mailto:sage [2008/04/25(金) 02:32:56 ] >>612 すいません。 結論は >>607 に書いたつもりでした。 614 名前：デフォルトの名無しさん mailto:sage [2008/04/29(火) 08:17:14 ] >>612 だめな講評の典型的な例だな まず本文を読め 615 名前：デフォルトの名無しさん mailto:sage [2008/04/29(火) 08:56:10 ] そういうのいいから 616 名前：デフォルトの名無しさん mailto:sage [2008/05/12(月) 03:25:59 ] MercurialHgでpushするときの方法を書き留めておくテスト *** http authorization required user:password@mydomain.org 617 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 00:09:53 ] Mercurial使いたい…… けどHaskellerだからdarcsなんだ。 618 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 00:46:11 ] 言語に括っても良い事無いよ 619 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 01:19:09 ] tracとhg使ってる理由 620 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 18:55:09 ] >>617 HaskellerがdarcsではなくMercurialを使いたい理由を詳しく 621 名前：デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:31:30 ] Windows版のdarcsで、 darcs unrevertを実行すると、 darcs failed: Couldn't parse unrevert patch: Patch bundle failed hash! This probably means that the patch has been corrupted by a mailer. The most likely culprit is CRLF newlines. こうなってしまうんですがどうすればいいんでしょうか？ 622 名前：デフォルトの名無しさん mailto:sage [2008/05/18(日) 05:28:07 ] darcsに興味をもっていろいろ読んでみたけど，darcsでは1つのリポジトリに複数のブランチを作れないんだね。 ブランチを作りたかったら，新たにリポジトリを作りなさいとある。 1リポジトリ，1ブランチということらしい。 wiki.darcs.net/DarcsWiki/BestPractices マージ機能が強力そうだからそれで問題ないのかもしれないが， 管理が面倒そうだな。 623 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 13:32:51 ] Mercurialのような分散リポジトリでは、作業ディレクトリ 自体が既にリポジトリなわけで、そうするとそれはどんどん 肥大化してしまうのでしょうか？めちゃくちゃ過去の変更 に関してはどっかのリポジトリにあってくれれば良いので、 自分の手元には最近のリビジョンに関する情報だけ あってくれれば十分なんですが･･ 624 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 13:34:22 ] バカはうだうだ言うよりまず使ってみた方が良いよ バカな質問してるのが良く分かるから 625 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 21:41:19 ] >>624の方が馬鹿っぽい 626 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 23:43:59 ] バカバカ言い合う事に何の意味があろうか。 627 名前：デフォルトの名無しさん mailto:sage [2008/05/23(金) 00:24:38 ] >>623 HGはよく分からないけど、GitだとたまにGCして圧縮したり、 同じファイルシステムにある同じようなリポジトリ（クローン元とか）は ハードリンク使ったりとかしてるね。 分散リポジトリという仕組み自体、裕福なリソースが無いと実現出来なかったものだと 俺は思ってるんで、あまり気にしなくて良いような気もするけど。 KDEまるごとクローンしたりするとかなり大変らしいが。 628 名前：デフォルトの名無しさん mailto:sage [2008/05/23(金) 09:30:52 ] mercurial-1.0.1.tar.gz

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef