08/09/28 10:30:27
>>351 でも書いたけど、 亀 Hg 使ってる人はマージはどうやってる？kdiff3 使ってる？
マージペインで日本語が化けるから、やや無理やりだけど WinMerge 使いたいんだよね。
でも premerge が効いてないっぽいし、バイナリファイルはどちらを採用するか聞いてこなかったり
もう設定がわけわかめ。
416:デフォルトの名無しさん
08/09/28 11:28:46
ブランチに試行錯誤や間違いの歴史を残すのに全然抵抗ないですけど
それでも分散型に利点はありますか？
417:デフォルトの名無しさん
08/09/28 11:33:46
>404
418:デフォルトの名無しさん
08/09/28 16:53:16
ベータ版かリリース版かというのはどのように管理してるの？
419:名無し募集中。。。
08/09/28 21:11:17
revisionのコメントに「>>418さんに渡した版」と書いておく程度の管理
または気持ちの問題､ｶﾅ
420:デフォルトの名無しさん
08/09/29 02:37:11
タグ名の最後に"-r"を付けるとか(release)
421:デフォルトの名無しさん
08/09/29 02:56:41
>>418
うちでは例えばバージョン名がB2.4.XからR2.4.0になる。
422:デフォルトの名無しさん
08/09/29 03:00:44
>>418
タグ付けてβ、それを品証がチェックしてリリース
trunk
tag
rel
のディレクトリにタグ化した日付でtagに入れてそのリリースがrelにcopyされる
品証のチェックで出たバグはtagの日付版で修正して、trunkへポートされてる
エンドユーザからのバグレポートはrelに対してになる、
423:デフォルトの名無しさん
08/09/29 03:42:29
>>418
tag つける。でtag名に、beta-ほげほげ とか release-ほげほげ とか
424:デフォルトの名無しさん
08/09/29 12:23:02
リポジトリをbetaフォルダからreleaseフォルダに複製してる
・・・けどタグの方がいいのか
425:デフォルトの名無しさん
08/09/29 12:36:21
いついつリリース版というフォルダをずっと増やしていく方針なら
タグは不要だと思うけど。
426:デフォルトの名無しさん
08/09/30 01:18:54
他所の cvs/svn/git リポジトリから co するときに自動的に hg 方式になって
自分で管理するときは hg でして
ci するときは cvs/svn/git 方式に自動的に変換するフィルタってない？
427:デフォルトの名無しさん
08/09/30 05:37:52
チェックアウト状態ではリードオンリーになっていて
編集しようとするとダイアログが開いて何のための変更か？を記述して
それをコミット時のデフォルトのコメントにしてくれるようなWindowsのツールってないですか？
TortoiseSVNの拡張機能みたいな形であれば一番いいんだけど。
428:デフォルトの名無しさん
08/09/30 09:48:34
それなんて VSS ？
429:デフォルトの名無しさん
08/09/30 10:19:30
>>427
needs-lockじゃ駄目?
lock取得するときに、やる作業をコメントに書く。
コミットするときは、最近のログメッセージから再利用。
430:デフォルトの名無しさん
08/09/30 16:51:34
SubversionリポジトリからMercurialに変換するツールはないんでしょうか？
431:デフォルトの名無しさん
08/09/30 16:51:59
gitだとsvnとの相互運用もできるっぽいのですが・・・
432:デフォルトの名無しさん
08/09/30 17:10:30
hg convert
433:デフォルトの名無しさん
08/09/30 17:35:30
>>432
Mercurial の Subversion convert extension - daily dayflower
URLﾘﾝｸ(d.hatena.ne.jp)
これか・・・かなり未完成っぽいですね
hgsvn？とかいうのがよいらしいですが
434:デフォルトの名無しさん
08/09/30 17:42:15
hgの読み方ってハーゲーでいいの？
435:デフォルトの名無しさん
08/09/30 18:08:50
>>434
銀ちゃんで
436:デフォルトの名無しさん
08/09/30 18:38:11
水銀党で
437:デフォルトの名無しさん
08/09/30 18:56:57
git では
git checkout 古いコミットID
として古い状態に戻すことができます。
このあと最新状態に戻すにはどうしたらいいですか。
git checkout HEAD とか git reset --hard HEAD とかしてもだめみたいです。
438:デフォルトの名無しさん
08/09/30 19:07:14
>>437
HEADは現在居るブランチの先端をあらわすので、その場合のHEADは名無しブランチの先端。
つまり古いコミットIDになる。
最新の状態にしたかったら、そういうブランチをチェックアウトすればいいと思う。
git checkout master とか。
439:デフォルトの名無しさん
08/09/30 20:11:31
>>438
ほんとだ、名無しのブランチになってました。
git checkout master でもとに戻れました。ありがとうございます。
ただ、git checkout COMMIT_ID を実行すると、名無しのブランチができるという挙動がなんか気持ち悪い。
なんで勝手にブランチができるんだろう。。。
440:デフォルトの名無しさん
08/09/30 20:39:40
>>439
どこの先端でもない途中の状態を指定して取り出すんだから、名無しになるんだよ。
今居るブランチをほんとうに古い状態に戻したいなら、そのコミットを指定してresetすればいい。
そうすればそのコミットが今居るブランチの先端になる。そこより先のコミットは無くなっちゃうけどね。
441:デフォルトの名無しさん
08/10/01 00:28:10
俺がHEADだぁぁぁあああ！
442:デフォルトの名無しさん
08/10/01 00:55:10
ヘドが出るぜ!
443:デフォルトの名無しさん
08/10/01 12:04:21
すみませんが、せっかくの機会なので教えていただけますか。
>>440
>どこの先端でもない途中の状態を指定して取り出すんだから、名無しになるんだよ。
新しいブランチを作るのではなく、今のブランチ (main) を使ったまま、古い状態を取り出すことはできないということでしょうか。
>今居るブランチをほんとうに古い状態に戻したいなら、そのコミットを指定してresetすればいい。
>そうすればそのコミットが今居るブランチの先端になる。そこより先のコミットは無くなっちゃうけどね。
reset は、HEAD がどのコミットを表すかを変更するということでしょうか。
HEAD を変更することなく、古い状態に戻すことはできないということですか。
Git は仕組みがよくわからず、困ってます。
Mercurial はすごくわかりやすいんですけど・・・
444:デフォルトの名無しさん
08/10/01 16:43:32
>>443
hgは使ったことないんだが、Gitからフォークしてるので似てるはずだと思ってたんだけど、
そうでもないのか。resetとかrebase無いの？
「古い状態に戻す」が何をしたいのかよくわからないんだけど、例えば、
３つ前の状態をちょっくらワーキングコピーで見たりしたくなったんなら、
３つ前の状態をチェックアウト（git checkout HEAD~3）すればいい。
名無しブランチの先頭に居ることになるが。
今のブランチを３つ前の状態まで戻して、そこからやり直したいならリセット（git reset HEAD~3）
この場合は３つ前以降のコミットは失われる（他のブランチに残ってなければ）
＞新しいブランチを作るのではなく、今のブランチ (main) を使ったまま、古い状態を取り出すことはできないということでしょうか。
mainという名のブランチをチェックアウトしたまま古い状態を取り出す？
いま居るブランチはmain~3ですよ、みたいな感じ？ それはないな。実質そういうことになるのかも
しれないけど、main~3は他のブランチにも含まれるかもしれないし、履歴の途中を引っ張り出した場合、
そこにコミットを続けることも出来るから、それってブランチ(枝)でしょう？
git checkout HEAD~3とした時点で「名無しブランチですよ。必要なら後からgit checkout -b って
出来るよ」みたいなメッセージが出てると思う。
445:デフォルトの名無しさん
08/10/01 19:01:31
443ではないけど
>>444
hgの場合古い状態をワーキングコピーで見るだけならブランチにはならなくて、
古い状態からコミットしたときに初めてブランチが作られる
446:445
08/10/01 19:05:37
それと、hgはgitのフォークではないよな
447:デフォルトの名無しさん
08/10/01 19:47:23
またリポジトリ、プロジェクトホスティング見つけてきた
Project Kenai -- We're More Than Just a Forge
URLﾘﾝｸ(kenai.com)
SubversionとMercurialのリポジトリと、フォーラム、ML、wiki、バグトラックなど一通りのホスティングサービス
448:デフォルトの名無しさん
08/10/02 07:37:45
枝の古い状態みるだけなら、チェックアウトすればそれでいいじゃん?
新しいブランチは作らず名無しの状態で取り出せる。
それぞれのHEADも変更しないし、何に困ってるのか分からないんだが…
多分何がしたいのかを言った方が手っ取り早い。
449:デフォルトの名無しさん
08/10/02 09:26:39
>>445
> 古い状態からコミットしたときに初めてブランチが作られる
前もって hg branch でブランチを指示しないといけないんでなかった？
450:デフォルトの名無しさん
08/10/02 09:40:05
>>446
SDにはそんなようなこと書いてあったけどな。
でもPythonで新たに書き直してるから、フォークとは言わないかもね。
451:デフォルトの名無しさん
08/10/02 12:51:20
>>444
両方ともBitKeeperのコマンドを参考に作ったんじゃなかったか？
452:デフォルトの名無しさん
08/10/02 15:27:04
tortoiseHGの0.5出てたから入れたけど、コミットの日本語は相変わらず
一緒にbazaarも入れてみたけど
右クリックしてもbazaarのメニューが出てこないのは気のせい？
453:デフォルトの名無しさん
08/10/02 18:36:34
>>448
>枝の古い状態みるだけなら、チェックアウトすればそれでいいじゃん?
それだとファイルパスが違うのになるから、設定ファイルをいちいち変更しないといけない。
または現在のディレクトリを別名に変更しないといけない。
454:デフォルトの名無しさん
08/10/02 21:14:48
???
455:デフォルトの名無しさん
08/10/03 11:22:29
hg convert って最強じゃね？
456:デフォルトの名無しさん
08/10/03 11:38:25
>>453
フルパスが書かれたものをリポジトリに入れてるのか。
そうであってもブランチを作る必要はなくて、
チェックアウトまたはclone＋チェックアウトで済むと思うけど。
何をしたいのかがわからないから、あとはエスパーを呼んでもらうしかない。
457:デフォルトの名無しさん
08/10/03 12:01:04
情報を後出しばかりする上に自分の特殊な環境が特殊だと思っていないんだから
誰がどう答えてもどうにもならんでしょ
458:445
08/10/03 13:30:09
>>450
URLﾘﾝｸ(en.wikipedia.org)(software)
>This project started at approximately the same time as another project called Git, started by Linus Torvalds with similar aims.
>>449
名前付きのブランチをつくるならそう。名無しブランチ作るならコミットするだけ。
hgの場合
hg checkout id
で古いワーキングコピーにして、
hg checkout
で最新(tip)にできる。
hg log
はcommitやpullしない限り、何をcheckoutしていても常に同じ内容が出力される。
git少し試したけど、古いのをチェックアウトするとgit logでそれ以降のログが
見えなくなるな。
459:デフォルトの名無しさん
08/10/03 16:21:21
緒マラ教えて下さい。
gitのリポジトリをhgに変換する方法を
460:デフォルトの名無しさん
08/10/03 21:41:25
4レス前は読んだか？
$ hg help convert ~
hg convert [OPTION]... SOURCE [DEST [REVMAP]]
Convert a foreign SCM repository to a Mercurial one.
Accepted source formats:
- Mercurial
- CVS
- Darcs (legacy Darcs 1 format only)
- git
- Subversion
- Monotone
- GNU Arch
461:デフォルトの名無しさん
08/10/03 23:17:10
git checkout ブランチ名
としたときに、
error: You have local changes to 'README'; cannot switch branches.
といわれます。
Gitでは編集中のファイルがあるとブランチを切り替えることはできないのでしょうか。
462:デフォルトの名無しさん
08/10/04 00:51:03
>>460
thanx... hg convertていくつも対応してるのね
463:デフォルトの名無しさん
08/10/04 03:39:36
>>461
たぶんそれチェックアウト先のブランチでREADMEがぶつかってるんじゃないかな。
まっすぐ伸びてれば
M README
Switched to branch
てな感じになるはず。
464:デフォルトの名無しさん
08/10/04 11:15:13
で、git と mercurial のどっち使えばええの？
465:デフォルトの名無しさん
08/10/04 11:31:34
bazaar使えばいい。
466:デフォルトの名無しさん
08/10/04 13:10:06
>>464
git はわかりづらいので、mercurial のほうがいいと思う。
ただ git のほうが機能は豊富。あまり使わないけど。
467:デフォルトの名無しさん
08/10/04 13:35:44
>>464
流行で言えばgitでしょう。
ただ、Windowsと関わることがあるなら git はちとキツイ印象（いろいろ試したが）
そのときは Mercurialでよいかと
468:デフォルトの名無しさん
08/10/04 14:12:39
>>466
mercurial になくて git にある機能って具体的にナニ？
>>466
どこの流行なんでしょうか？
469:デフォルトの名無しさん
08/10/04 15:07:16
>>468
githubでいきなり盛り上がった印象がある。
それまでは、俺はLinux Kernel専用SCMとしか思ってなかった。
470:デフォルトの名無しさん
08/10/04 16:46:55
大型プロジェクトに良く使われている印象>git
linux kernel、X.org、wine、vlcなど。
hgはmozillaだけな予感。
471:デフォルトの名無しさん
08/10/04 17:46:54
hg も netbeans、opensolaris や xen とかで使われてる
…ってちょっとググれば分かるはずなんだがな
472:デフォルトの名無しさん
08/10/04 18:16:14
リポジトリ数
github(git) 30*618=18540ぐらい
launchpad(bazaar) 19002
mercurial専用ホスティング&コラボレーションサービスって無いのな。専用である必要ないって言ったらその通りだが。
473:デフォルトの名無しさん
08/10/04 18:25:41
>>472
bitbucket freehg projectkenai
474:デフォルトの名無しさん
08/10/04 18:30:29
>>473
thx.
bitbucket(mercurial) 15*40=600
他分からず。
475:デフォルトの名無しさん
08/10/04 18:54:37
>>468
git-svnと同等なものがHgに無い。マジで欲しい。
476:デフォルトの名無しさん
08/10/04 19:01:08
>>475
俺もこれほしいな
gitは、gitでGoogle Code Projectのsvnで開発なんて記事もあるくらいだからな
Google Open Source Blog: Develop with Git on a Google Code Project
URLﾘﾝｸ(google-opensource.blogspot.com)
477:デフォルトの名無しさん
08/10/04 19:05:12
>>475-476
hgからsvnにpushする方法
URLﾘﾝｸ(jelmer.vernstok.nl)
478:デフォルトの名無しさん
08/10/04 19:26:00
hgsvnに含まれるhgpushsvnってのもあるらしいがバギーなようだ。hgsvnの開発も芳しくないようだし。
479:デフォルトの名無しさん
08/10/04 19:42:17
windows上ならbzr-svnが標準で含まれているbzrが最強な予感。
cygwin+gitならgit-svn入れるだけだろうけど。
msysgitはgit-svn入れるの難しいはず。
480:デフォルトの名無しさん
08/10/04 20:15:22
TorotoseHGに含まれている hg.exeで
hg mergeしようとすると、gpyfmというウインドウが立ち上がるんだけど、
これは何するものなの？
リストに何も表示されていないから、何をしたらいいかわからんｗ
acceptoとかrejectとかのボタンは表示されているが
481:デフォルトの名無しさん
08/10/04 21:19:29
github を使っていて、他人のプロジェクトをフォークしたんですが、
それを更新する (pull) 方法が分かりません。
つまり someone/proj1 をフォークして myname/proj1 をつくり、
git clone git://github.com/myname/proj1
をして、自分のリポジトリに commit & push するのはいいんですが、
someone/proj1 の変更を myname/proj1 に pull する方法がわかりません。
だれか教えてください。
482:デフォルトの名無しさん
08/10/05 02:37:27
>>481
git remote add someone git://github.com/someone/proj1
git pull someone
かな。
483:デフォルトの名無しさん
08/10/05 02:38:37
>>475
URLﾘﾝｸ(www.bitbucket.org)
まだまだっぽいけど。
484:デフォルトの名無しさん
08/10/05 04:39:52
欲しければ実装しちゃいなよ
485:デフォルトの名無しさん
08/10/05 08:27:55
bazaarを介するのもhgsubversionを使うのも一抹の不安があるなぁ
486:デフォルトの名無しさん
08/10/05 14:11:41
Bazaarが気になったので、GCCのソースを使って計測してみた。
svn://gcc.gnu.org/svn/gcc/trunk
ソースのサイズ: 510MB
Intel(R) Atom(TM) CPU N270 @ 1.60GHz
DISK: SDHC(ext3) ＃ツッコミなしでw
使用コマンド
svn = import (svnadmin create済み)
hg = commit -A (hg init済み)
bzr = add + commit (bzr init済み)
git = add + commit (git init済み)
TAT
git(8m30s) > bzr(10m30s) > hg(12m40s) >> svn(60m38s)
CPUTIME
git(1m10s) > hg(2m55s) > bzr(5m49s) > svn(6m57s)
REPOS SIZE (ソースのサイズ除く)
bzr(122MB) > svn(133MB) > hg(311MB) > git(319MB)
考えていたよりbzrがいい結果。
487:デフォルトの名無しさん
08/10/05 17:59:01
総合的にみて hg の圧勝じゃないか
488:デフォルトの名無しさん
08/10/05 18:31:15
総合的にみたらgitだろ?
489:デフォルトの名無しさん
08/10/05 18:36:26
総合的に見るとrcsだわな。
490:デフォルトの名無しさん
08/10/05 18:39:23
あと10年くらいはsvnでいいや
491:デフォルトの名無しさん
08/10/05 18:40:21
cvsはもう勘弁
492:デフォルトの名無しさん
08/10/05 19:21:08
>>486
What does "TAT" mean?
"CPUTIME" is speed of command execution?
493:デフォルトの名無しさん
08/10/05 19:25:26
turn around timeじゃないか
494:デフォルトの名無しさん
08/10/05 20:54:04
>>493
その通り。
495:デフォルトの名無しさん
08/10/06 09:03:25
どうもです。
>>482
>git remote add someone git://github.com/someone/proj1
>git pull someone
これだと自分のローカルリポジトリのみの変更ですよね。
あとはこれをpushすれば、github上にあるリモートリポジトリにも反映されるということでしょうか。
gitは勉強中なのでわからないことがいっぱいです。
496:デフォルトの名無しさん
08/10/06 19:00:20
Git(ギット)勉強会メモ - kinneko@転職先募集中の日記
URLﾘﾝｸ(d.hatena.ne.jp)
> git stash
> 日本からやってきたパッチ。最近追加。
> する直せ、今直せとボスが言う。
> 中断されると違う事やると思考の流れが止まる。続けられない。
> git stash saveとたたくと、今の状態を保管する。
> 巻き戻されて最初からボスの変更だけやって、コミットしてしまう。
> その後で、git stash applyで保管した結果を戻して作業ができる。
> tarで保管するのと違って、重なる変更点は3 way margeされる。
> ボスの変更が反映された上で、途中の作業に戻れる。
今 hg 使ってるんだが、この git stash に相当するコマンド（群）知ってる人イナイ？
コード弄ってるときにバグ発見とか、よくあるもんで…
497:デフォルトの名無しさん
08/10/06 19:43:01
>>496
意味がわからんし使い方もわからん
cloneすればいいんじゃねーの
498:デフォルトの名無しさん
08/10/06 21:03:46
>>496
URLﾘﾝｸ(www.selenic.com)
これかな
499:デフォルトの名無しさん
08/10/06 21:22:28
>>496
> 今 hg 使ってるんだが、この git stash に相当するコマンド（群）知ってる人イナイ？
つhgext.mq
500:デフォルトの名無しさん
08/10/09 17:25:46
少しお聞きしたいのですが、ためしに 動的なwebページをMercurialで管理しようとしています。
MySQLを使用するCMSを使っているのですが、DBのデータも管理したもんなんでしょうか？
webアプリの場合だと、DBがファイルととは別ってことは普通にあると思いますが、
みなさんはどうしてらっしゃいますか？
てか、Railsもそういった類だと思うけどバージョン管理はどうしているんだろう
501:デフォルトの名無しさん
08/10/09 17:29:10
うちはテーブル、ビュー、関数、ストアドプロシージャのようなスクリプトと
マスターデータをテキストとかで管理してる。
502:デフォルトの名無しさん
08/10/09 19:14:08
>>497-499
ありがとう
拡張になるのかー
503:デフォルトの名無しさん
08/10/09 21:49:34
名前ド忘れしたけど
DB専用Subversionみたいなのがあったな
504:デフォルトの名無しさん
08/10/11 21:52:17
[Visual Studio 2005 Team Edition for Database Professionals]
URLﾘﾝｸ(www.microsoft.com)
505:デフォルトの名無しさん
08/10/12 15:13:25
.flaも管理したい
506:デフォルトの名無しさん
08/10/13 10:20:18
Subversionはバイナリの差分をとってくれますが、Mercurialはしてくれないようです。
ほかにバイナリも差分をとってくれるバージョン管理ツールはありますか。
507:デフォルトの名無しさん
08/10/13 14:54:48
CVS
508:デフォルトの名無しさん
08/10/13 15:00:52
CVS って、差分とったっけ？
バイナリは、そのまま保存しかできないと思っていたけど。
509:デフォルトの名無しさん
08/10/13 16:15:45
>>506
Mercurialも差分を取るだろ
510:デフォルトの名無しさん
08/10/13 16:32:24
>>506
軽く試した感じだとちゃんと差分で保持してるよ。
511:デフォルトの名無しさん
08/10/13 18:22:37
git は?
512:デフォルトの名無しさん
08/10/13 18:23:27
ってそもそも差分じゃないか。スマン。
513:デフォルトの名無しさん
08/10/13 18:42:48
Mercurial を使って自分のコードを管理していたのですが、
Mercurial のリポジトリをホストしてくれる Bitbucket に移行しようとしています。
しかし新しく自分用のリポジトリを登録したのはいいんですが、
ローカルにあるリポジトリをサーバに移動する方法がよくわかりません。
もしご存知の方がいましたら教えてください。
514:デフォルトの名無しさん
08/10/13 19:34:24
>>508
一応無理やり差分は取ってる。あんまり効率的ではないだろうけど(昔の実験結果より)。
515:デフォルトの名無しさん
08/10/13 20:19:43
>>513
hg push URLﾘﾝｸ(hoge@bitbucket.org)
めんどくさかったら .hg/hgrc に書いとけ、な。
516:デフォルトの名無しさん
08/10/14 13:15:59
>>35 mercurialもclone直後はハードリンクになっているけど
変更をcommitすると別物になるようだ。
517:デフォルトの名無しさん
08/10/14 15:03:34
gitはテキストとバイナリの区別をしないで
オブジェクトデータベース内のすべてのオブジェクトについて
「似ているもの同士は差分で保持」という実装
518:デフォルトの名無しさん
08/10/14 19:08:06
いいね、バックアップソリューションでもそういうのが流行ってるみたいだし。
519:デフォルトの名無しさん
08/10/14 20:20:24
>>517
へー、そうなんだ。
「似ているもの同士」ってどうやって判断してるの?
その辺について書かれたドキュメントとか知ってたら教えてもらえると嬉しい。
520:デフォルトの名無しさん
08/10/14 21:21:12
ソース嫁よ
521:デフォルトの名無しさん
08/10/14 21:50:51
>>517
これほんと?
Gitって、差分は管理してなくて、すべてのファイルを圧縮保存していると資料に書いてあったけど。
522:デフォルトの名無しさん
08/10/14 21:54:31
Git と Mercurial の連携・・・・ってできますか？
いや意味があるのかといわれるとそれまでなんですけど。
523:デフォルトの名無しさん
08/10/14 22:03:04
cvsってdiffでバイナリ差分とってる訳？
524:デフォルトの名無しさん
08/10/15 03:37:07
>>517 「似ている」ってどうやって判別してんだ？
525:デフォルトの名無しさん
08/10/15 03:40:21
CVS は「バイナリ」じゃなくて「キーワード・行末変換なし」っていう設定で diff はいちおう
通してたような記憶があるお。 0x0a が現れるといちおう区切られるっていう
526:デフォルトの名無しさん
08/10/15 17:41:15
git pull して git push するのに疲れました。
２つを連続してやってくれるコマンドオプションとかありますか。
527:デフォルトの名無しさん
08/10/15 17:44:00
bat
528:デフォルトの名無しさん
08/10/15 17:58:15
sh & alias
529:デフォルトの名無しさん
08/10/15 23:53:17
>>527,528
そんなオプションはないということですね。
これで安心してshellスクリプトを書けます。
ありがとうございました。
530:デフォルトの名無しさん
08/10/16 22:25:14
aliasでいいじゃん
531:デフォルトの名無しさん
08/10/18 23:40:14
>>503
「DBAを救え! DBリファクタリングツール「LiquiBase」を使ってみよう」
URLﾘﾝｸ(journal.mycom.co.jp)
これのことかな？
532:デフォルトの名無しさん
08/10/19 01:42:03
>>531
それそれ！
533:デフォルトの名無しさん
08/10/19 04:00:46
>>500
データってデータそのもの? スキーマだけじゃなく?
SQLite にしてデータベースファイル突っ込んどけば?
Rails だとマイグレーションという仕組みでスキーマを版管理する。
テスト用のデータについてはフィクスチャで流し込むのが一般的。
実運用のデータをバージョン管理するという話はあまり聞かないな。
534:デフォルトの名無しさん
08/10/19 23:30:08
git push origin master
と同じことを Mercurial でするにはどうしたらいいですか。
ローカルのリポジトリを、リモートに移動しようとしています。
535:デフォルトの名無しさん
08/10/19 23:39:58
clone すればいいんじゃね？
536:デフォルトの名無しさん
08/10/20 23:25:07
>>534
gitのことはよくわからんけど、ローカルのチェンジセットをリモートに push するだけなら
hg push <remote-addr>
ローカルとリモートのリポジトリが同一のツリーでないなら
hg push -f <remote-addr>
537:デフォルトの名無しさん
08/10/21 01:25:59
>>534
git -> hg
538:デフォルトの名無しさん
08/10/21 07:22:29
Subversionスレでも出ていた話題ですが、
ｽﾚﾘﾝｸ(tech板:489-502番)
Mercurial(hg)て file:// でも排他処理されてますか？
多人数で共有ファイル鯖の上にpushしても大丈夫？
どこかドキュメントに記述はありますでしょうか？
539:デフォルトの名無しさん
08/10/21 08:10:28
>>538
問題ない
Distributed revision control with Mercurialに書いてある。
540:デフォルトの名無しさん
08/10/21 09:11:04
>>539
ありがとう
どの辺の章に書いてありましたか？以下で「排他」「file://」あたりで検索したのですが、
見つけられませんでした
Distributed revision control with Mercurial
URLﾘﾝｸ(ursm.jp)
541:デフォルトの名無しさん
08/10/21 09:58:55
>>540
4.5.3 並行アクセス
542:デフォルトの名無しさん
08/10/21 15:53:31
>>541
Thanks!! 見つけられました。安心したっす
4 Behind the scenes
URLﾘﾝｸ(ursm.jp)
543:デフォルトの名無しさん
08/10/25 14:06:51
hg convert がうごかないんだが、なんでかな?
% hg convert -s svn svn://svn.freebsd.org/base
assuming destination base-hg
initializing destination base-hg repository
Subversion python bindings could not be loaded
abort: svn://svn.freebsd.org/base: unknown repository type
% hg convert -s svn freebsd-head
assuming destination freebsd-head-hg
initializing destination freebsd-head-hg repository
Subversion python bindings could not be loaded
abort: freebsd-head: unknown repository type
544:デフォルトの名無しさん
08/10/25 14:57:01
>>543
Subversion python bindings could not be loaded
545:デフォルトの名無しさん
08/10/25 23:48:26
開発やってる奴でその質問はどうなんだ(´・ω・｀)
546:デフォルトの名無しさん
08/10/26 00:27:27
＞バージョン管理システムについて語るスレ2
547:デフォルトの名無しさん
08/10/26 01:55:24
>>546
エラーメッセージ完全スルーで2ch丸投げとか、
流石に情けないんじゃないのか、って話だと思うんだが。
548:デフォルトの名無しさん
08/10/26 17:11:14
んなこと全員分かってるわ
549:543
08/10/26 21:23:22
みなさんぼろくそいってくれてありががとう
devel/py-subversionをインストールしたら動き出しました。
エラーメッセージは読み違えていて
convert/subversion.pyが見つからないのかとおもってました。
ktraceしても原因は見つけられず。
どこかにconvert subversionはプロセスを起動するとあったので
てっきりsvnをforkexecするものだと...
550:デフォルトの名無しさん
08/10/26 23:11:53
おまい、おもろい。ｗ
551:デフォルトの名無しさん
08/10/27 06:54:35
TortoiseHgのリポジトリがBitbucketに移動してた
552:デフォルトの名無しさん
08/10/27 10:59:33
Python 2.5 の公式ドキュメント日本語訳完成
URLﾘﾝｸ(www.python.jp)
553:デフォルトの名無しさん
08/10/27 21:53:54
hgでパーミッションが保存されないんですが仕様ですか?
% hg init a
% cd a
% date>file
% date>file2
% chmod a-w file2
% ls -al
total 8
drwxr-xr-x 3 hoge hoge 5 10 27 21:44 ./
drwxr-xr-x 7 hoge hoge 9 10 27 21:43 ../
drwxr-xr-x 3 hoge hoge 5 10 27 21:43 .hg/
-rw-r--r-- 1 hoge hoge 40 10 27 21:43 file
-r--r--r-- 1 hoge hoge 40 10 27 21:44 file2
% hg add file file2
% hg commit -m "init"
% cd ..
% hg clone a b
updating working directory
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
% cd b
% ls -al
total 8
drwxr-xr-x 3 hoge hoge 5 10 27 21:44 ./
drwxr-xr-x 8 hoge hoge 10 10 27 21:44 ../
drwxr-xr-x 3 hoge hoge 9 10 27 21:44 .hg/
-rw-r--r-- 1 hoge hoge 40 10 27 21:44 file
-rw-r--r-- 1 hoge hoge 40 10 27 21:44 file2
%
554:デフォルトの名無しさん
08/10/31 11:56:13
>>553
パーミッションは保存されません。
hgに限らず、SubversionやVSSでもパーミッションは保存されません。
パーミッションはリビジョン管理システムの外側にある概念です。
555:デフォルトの名無しさん
08/10/31 11:58:59
>>554
Subversionはpropertyとして保存してくれるんだが。
556:デフォルトの名無しさん
08/10/31 13:28:25
だからなに？って話
557:デフォルトの名無しさん
08/10/31 14:48:20
>>556
>パーミッションはリビジョン管理システムの外側にある概念です。
というのが大間違いっていう話。
558:デフォルトの名無しさん
08/10/31 16:33:51
Subversionが自動的にパーミッション保存してくれるなんて初めて聞いたんだが
559:デフォルトの名無しさん
08/10/31 22:01:35
sccsは保存してくれたなぁ、と古い話。
560:デフォルトの名無しさん
08/10/31 22:04:06
svnが保存するのは実行ビットだけであってる?
561:553
08/10/31 23:30:12
hgのソースをみてみたら
どうもexec bitとsymlinkしかあつかえないようだ。
562:デフォルトの名無しさん
08/10/31 23:41:03
なんか問題あんの？
hook で chmod すればそれで終わりじゃん
563:デフォルトの名無しさん
08/11/02 09:12:41
hg はパーミッションは保持しないクソツール、と。
564:デフォルトの名無しさん
08/11/02 11:19:53
ここで煽ってみたところでなにも変わりはしないぞ
565:デフォルトの名無しさん
08/11/02 12:07:38
そもそも644になって問題がある開発環境なんて存在するのか？
566:デフォルトの名無しさん
08/11/03 01:06:15
>>565
というより、SCMとしての機能を考えると、実行属性以外のパーミッションとかACLとかを保存される方が困る気がする。
567:デフォルトの名無しさん
08/11/03 02:53:28
OSやfsによってマチマチだからなぁ
568:デフォルトの名無しさん
08/11/03 13:01:37
POSIX標準くらいサポートしてもバチは当たらない
569:デフォルトの名無しさん
08/11/03 14:17:51
属性を用意したからあとは勝手にやってくれって思想だよな
svn:permissionsを追加したってパッチはみつかったけど
設計や互換性の面で却下されてるようだ
570:デフォルトの名無しさん
08/11/04 18:32:59
TortoiseHGでBitbucketでssh経由でpushしたいのですが、上手くいかず困っています。
ToritoiseSVNでは同じようにして上手くいったのですが・・・
やったこと
・Bitbucketのアカウントをとる
・Bitbucketにssh公開鍵を追加
・setting->repogitoryの設定ダイアログにて、Pathのdefaultを
ssh://(ユーザー名)@bitbucket.org/(ユーザー名)/(project名)/
に設定（＝ .hg/hgrcの[paths] の default = に上記パスを設定することと等価）
・TortoiseHGのpageantを起動し、対応する秘密鍵を追加
・コマンドラインから hg push → pageantで設定してあるのに何故かパスワードを聞かれる →
２回ほど入力したら pagelinkが落ちる。
出力：
*** no suitable response from remote hg[command interrupted]
・GUIの Synchronize... から push 選択
コマンドラインの時と同様になる
571:デフォルトの名無しさん
08/11/04 18:35:38
>>570
ToritoiseSVNでBitbucketでssh経由でpushする方法kwsk
572:デフォルトの名無しさん
08/11/04 18:49:33
ああ、スマソ。BitbucketではTortoiseSVNは使ってません・・・。
別のローカル鯖でTortoiseSVNのssh+svnで上手くいったという話です。
573:デフォルトの名無しさん
08/11/04 19:11:00
>>570
追記：
・hg push や GUIでsynchroize->push でパスワード聞かれるときは、
ユーザー名@bitbucket.org's password と言われる。
(鍵の場合 passphraseだったはず？)
・puttyで 秘密鍵を指定してBitbucket に接続すると、passwordを聞かれ、
アカウントのパスワードや秘密鍵のパスワードを入れても接続できない。
状況がどうもおかしい気がします・・・
574:570
08/11/04 19:53:47
解決しますた。
>・setting->repogitoryの設定ダイアログにて、Pathのdefaultを
> ssh://(ユーザー名)@bitbucket.org/(ユーザー名)/(project名)/
ここが間違ってました。
正しくは、
ssh://hg@bitbucket.org/(ユーザー名)/(project名)/
以下に書いてありました。
Using SSH - Help ? bitbucket.org
URLﾘﾝｸ(www.bitbucket.org)
リポジトリページの https://をそのままコピペしてssh://に変えていたせいなのと、
上記ページの例をサンプルだからユーザーがhgになってるのかと思ってた・・・
575:デフォルトの名無しさん
08/11/05 23:58:24
mercurialはtransactionを意識しているのにfsyncしないのはなぜか?
576:デフォルトの名無しさん
08/11/06 18:55:10
SubversionからMercurialに変換したいのですが、
hg convert が動かない？のですが、何か必要なものがありますでしょうか？
> hg help convert
hg: unknown command 'convert'
> hg convert
hg: unknown command 'convert'
TortoiseHgの付属のhgです。
577:576
08/11/06 18:56:00
追記です。
> hg -v
Mercurial Distributed SCM (version 1.0.2+tortoisehg)
578:576
08/11/06 19:12:52
Mercurial.iniに以下を書き込んだら hg convert 自体はうごくようでした。
[extensions]
hgext.convert=
ConvertExtension - Mercurial
URLﾘﾝｸ(www.selenic.com)
ここ読め、オレ・・・
579:デフォルトの名無しさん
08/11/06 20:03:02
hg convertで、Subversionリポジトリからコンバートしているのですが、
もしかして、日本語ログを含んでいると壊れますか？
変換後のリポジトリをTortoiseHgのView Change Logで見ると、
アスキーのみのログのところでは問題なく履歴が見られますが、
日本語ログのリビジョンでは、まったく異なる履歴が表示されます。
（ファイル一覧、差分などがsvnのとは異なります）
これを回避して日本語ログのものもコンバートすることはできないのでしょうか？
580:デフォルトの名無しさん
08/11/06 20:28:33
>>579
TortoiseHgのことは知らないけど、Unix上では日本語ログもきれいに変換され
たよ
581:579
08/11/06 20:48:48
hgsvnも試したけど、hgimportsvnはおｋ。
hgpullsvnが、以下のエラーで途中死亡します orz
transaction abort!
rollback completed
abort: decoding near '縺阪↑縺・ｈ縺・↓菫': 'utf8' codec can't decode byte 0x82
in position 138: unexpected code byte!
>>580
ええ、まじすかー。
svnの日本語ログが変なのかなあ？TortoiseSVNで入れたログのはずですけど
582:579
08/11/06 21:02:40
2008-09-15 - kokiyaの日記
URLﾘﾝｸ(d.hatena.ne.jp)
こちらのサイトの
> 2.hgsvnの文字コードの変更
を行うと上手くいったような気がしました。
TortoiseSVNでのログはUTFとかで入ってないのかなぁ？
今時間がないので後でまた確かめて見ます。
583:579
08/11/07 07:59:05
日記みたいで、すいません。
hgsvnでsvnからhgへの変換が上手くいったかなーと思ったのですが、
trunk指定すると branchesとかtags 考慮してくれない orz
trunkの親ディレクトリを指定すると、今度はtrunk,branches,tagsと全部できてしまうし・・・
やっぱり、svnと連携するためのものか、これは・・・。
hg convertでなんとか変換する方法を模索したほうがよいようですね。
584:579
08/11/07 08:36:28
>>579の件ですが、
どうやら、壊れると思っていたsvnリポジトリは、hg convert で変換後、
問題のあるリビジョンを hg log -r2 -p などで見ると特に問題ない様子でした。
TortoiseHgのView Changelogのバグ？みたいですね。
585:デフォルトの名無しさん
08/11/07 17:27:47
git rebase origin
を実行すると
README.txt: needs update
とでてくるのですが、これはどういう意味ですか。
README.txtは変更されているのですが、updateが必要というのがよくわかりません。
またこのような状態のときにgit rebase originを問題なく実行するにはどうしたらいいですか。
586:デフォルトの名無しさん
08/11/07 23:37:48
>>583
そもそもsubversionにタグやブランチがないのが原因
587:デフォルトの名無しさん
08/11/08 03:27:23
>>585
README.txtを変更したままなんじゃない？
変更してるファイルがある状態ではrebaseは出来ないよ。
README.txtをコミットするかresetするかstashに追い出すかしてからrebase。
588:デフォルトの名無しさん
08/11/08 04:22:58
>>586
cvs done wrong
589:デフォルトの名無しさん
08/11/08 10:25:48
もっとも使われているらしいsvnはhgやgitよりもそんなに優れているの？
590:デフォルトの名無しさん
08/11/08 11:56:21
優劣ではなくそれぞれに特徴があるんだから、好きなの使えばいい
591:デフォルトの名無しさん
08/11/08 18:40:11
ここ最近のsvnマンセー祭りに吐き気を感じているアルファギークは多いだろうね
592:デフォルトの名無しさん
08/11/08 18:49:39
gitを使うぜみたいな話は最近目に余るようになってきたが、
いまさらsvnマンセーなんて言い出してるトコあるか?
593:デフォルトの名無しさん
08/11/08 18:54:09
アルファギークとかいっちゃってるやつに吐き気を感じる
594:デフォルトの名無しさん
08/11/08 19:29:14
svnマンセーはないだろうｗ
素晴らしい所は、ToritoiseSVNの完成度の高さぐらいだな。
595:デフォルトの名無しさん
08/11/08 19:37:27
アルファギークとか、スイーツ（笑）と同類だろ
596:デフォルトの名無しさん
08/11/08 20:58:46
嫉妬丸出しのレスばかりで笑った
>>593
底辺で蠢いてる奴発見ｗ
アルファギークはもう何歩先も行ってるからｗ
597:デフォルトの名無しさん
08/11/08 22:28:22
Pythonがsvnから移行したがってるようだけど
BazaarになるかMercurialになるか……もしかしてGitもあり?
598:デフォルトの名無しさん
08/11/08 22:28:58
集中管理の svn でも、「なんか変なツール」とか言われてるのに
このレベルで分散システムとか絶対無理だな、うちは
599:デフォルトの名無しさん
08/11/08 22:32:22
Windowsを軽視していないPythonなら、gitはまずないだろう。
MercurialがPython製ということを考えると、Mercurialが優勢ではなかろうか
600:デフォルトの名無しさん
08/11/08 22:35:59
>>599
BazaarもPython製ですよ
↓ソース。まだ検討始まったばかりだけど
URLﾘﾝｸ(www.python.org)
601:デフォルトの名無しさん
08/11/08 22:54:22
svnからの移行を検討するなら
遅くてもレポジトリ効率で選ぶならbazaar
そこそこ速くて使いやすさで選ぶならhg
速くて機能で選ぶならgit
602:デフォルトの名無しさん
08/11/08 22:56:17
pythonで書かれているツールってことでbzrが有利だろうな
603:デフォルトの名無しさん
08/11/08 23:07:35
>>602
MercurialもPython製ですよ
604:デフォルトの名無しさん
08/11/08 23:34:12
Mercurialが優勢ということか
605:デフォルトの名無しさん
08/11/09 01:14:45
水銀党なのでhgの一択なのだが・・・
606:デフォルトの名無しさん
08/11/09 02:06:54
UNIX系で使って他(Windowsとか)を、それほど考慮しないとか
LinuxやLinusが個人的に嫌いじゃなかったら git
上記に当てはまるなら、他かな？
あてはまる人が結構いるから分かれるんだが
607:デフォルトの名無しさん
08/11/09 02:11:00
分散型って、ゲーム開発みたいに画像などのバイナリデータが容量のほとんどを
占めてスナップショットでも数ギガに行くようなプロジェクトでも、 Subversion より良いの？
それともプログラムソースがメインなプロジェクトに限って良いの？
608:デフォルトの名無しさん
08/11/09 02:18:36
607じゃないが、分散型に興味がある。
今までcvsとsvnしか使ったことがないが、どんなときにどんなメリットがあるのか。
またどんなデメリットがあるのか。
どんな点に注意して使えばよいのか。
そこら辺を具体的に解説したページはないだろうか？
「慣れろ」と言われるかも知れないが、
誰も知らない状態でいきなり本番プロジェクトに導入は出来ないし、
一人gitとかで試してみてもあんまり意味なさそうで・・・
609:デフォルトの名無しさん
08/11/09 02:27:43
分散型のメリット
すべてを手許に置けるのでオフラインででも開発可能でマージもバックアップも気楽にできる
分散型のデメリット
オリジナルの証明が難しい(事実上無い)
610:デフォルトの名無しさん
08/11/09 02:34:01
結局巨大バイナリを一番上手に扱えるのはどれ？
どうせテキストなんかサイズも小さいしある意味バイナリだし。
611:デフォルトの名無しさん
08/11/09 03:48:00
>>607-608
テキスト向きかバイナリ向きかっていうのは集中型か分散型かの差っていうより
ツールごとの差が大きい。開発形態が伽藍的かバザール的か、開発者が一箇所に
いるのか離れてるのかって観点で選んだほうがいいと思ってる。
会社である程度きっちり設計して2～3人で実装していくって形態ならsvnで十分まわせてるけど、
開発者が数人以上いるOSSのコントリビュータって立場のときはまじ分散型導入してくれって感じ
612:608
08/11/09 07:13:50
>>609
「オリジナルがない」という点は大きなデメリットだと思うのですが使用していてどうでしょうか？
皆が同じソースを見ることが出来ない＝AさんとBさんで同じソースについて認識が異なってしまう ということで。
Aさん：rev329で試験したけど、これこれこういう動作がおかしいよ。直しておいて。
Bさん：それrev332で修正済みです
みたいな会話をどうやるのかがわからない。
仕事の現場なら非常に良くある話だと思うのですが。
メリットの方はsvn+svk(使ったことはないですが)でも可能なような。
>>611
仕事のプロジェクトなので伽藍方式オンリーですね。
開発者は大体同じ拠点にいますが、東京3人北海道3人大阪・・・ということもありました(svnで問題なく回っていました)。
2～3人で実装していく現場ってのは経験無いですなぁ。実装チームは5～10人が普通。
613:デフォルトの名無しさん
08/11/09 07:31:10
>>612
あなたのような「分散型使ってないけどどうなの？」っていう人は定期的に見かけるけど
チュートリアル見ながら触ってみるぐらいやってみたらどうだろう。たいした手間じゃないよ。
＞メリットの方はsvn+svk(使ったことはないですが)でも可能なような。
私はGitの前にsvkを使ってたけど、svkは遅すぎると思った。
あとオリジナルが無いという点については、Gitの場合はツリーに一意なIDが付くので問題ないと思う。
614:デフォルトの名無しさん
08/11/09 07:35:45
>>612
> 「オリジナルがない」という点は大きなデメリットだと思うのですが使用していてどうでしょうか？
オリジナルは決めとけばいいんじゃないか。集中管理のときと同じように、オリジナル用のサーバーってのを。
議論はそのサーバーにあるものに対してする。
push し忘れとか、pull した後 update し忘れとかが当面の問題になるんじゃないかなあ。
Mercurial 導入を提案しようかと自分で試用中だけど、ほかの人たちが使いこなせるとは思えないので、
今までどおり CVS にしようと思ってる。プロジェクト(リポジトリ)ツリーの好きなところからちぎって
持ってきて組み合わせられるような SCM はほかにはなさそうだし。
615:デフォルトの名無しさん
08/11/09 08:50:25
オリジナルが無いって語弊があるんじゃない?
svnと同じように中央レポジトリを作ればそれがオリジナルになる。
616:デフォルトの名無しさん
08/11/09 09:11:32
>>605
そいやmercurialだけ単独スレないな
617:デフォルトの名無しさん
08/11/09 12:03:16
Linux板にgitスレあったのか。CVSはUNIX板だし…。
スレも分散管理ですか。
618:デフォルトの名無しさん
08/11/09 12:12:36
>>616
何がそいやなんだｗ
619:デフォルトの名無しさん
08/11/09 12:22:20
どうもありがとうございます。
>>587
>変更してるファイルがある状態ではrebaseは出来ないよ。
この制約はどういう理由からきてるんでしょうか。
変更したファイルがあっても merge はできるんだから、rebase ぐらいできてもよさそうですが。
620:デフォルトの名無しさん
08/11/09 12:26:37
上の話が本当なら Python が hg か bzr になるかってのは試金石だな
621:デフォルトの名無しさん
08/11/09 13:31:09
リトマス？
622:デフォルトの名無しさん
08/11/09 13:40:35
普通に考えて分散型の方が良いとしか思えないなあ
623:デフォルトの名無しさん
08/11/09 13:51:49
>>622
bazaar＝分散型とはいえない
624:デフォルトの名無しさん
08/11/09 14:11:09
>>623
くわしく
625:デフォルトの名無しさん
08/11/09 14:18:44
>>608
分散型はローカルでもバージョン管理ができるというメリットがある。
よくプロジェクト全体でSVN使っていてローカルではRCSというような
使い方をしている人がいるが、分散型なら1つのシステムで対応できる。
626:デフォルトの名無しさん
08/11/09 15:00:35
>>625
>よくプロジェクト全体でSVN使っていてローカルではRCSというような
>使い方をしている人がいるが、分散型なら1つのシステムで対応できる。
GitやMercurialは、RCSの代わりに使えるのがいいよね。
プロジェクト全体はSVNで管理して、自分用のブランチはGitやMercurialで管理するのが楽でいいや。
627:デフォルトの名無しさん
08/11/09 15:10:32
>>626
Bazaar も仲間に入れてあげてください(´・ω・｀)
628:デフォルトの名無しさん
08/11/09 15:14:54
>>624
URLﾘﾝｸ(doc.bazaar-vcs.org)
629:デフォルトの名無しさん
08/11/09 15:27:23
俺いままでずっとバザールって読んでたよ
ダサイ名前だと思ってた
630:デフォルトの名無しさん
08/11/09 15:46:53
分散型はバージョン管理の入門用にうってつけなんだよね
スタンドアロンで使う場合最も敷居が低い
631:デフォルトの名無しさん
08/11/09 15:54:20
>>629
え、違うの?なんとなくエリックレイモンドの
「伽藍とバザール (The Cathedral and the Bazaar)」
から来てるんじゃないかと思ってたが。
632:デフォルトの名無しさん
08/11/09 16:07:50
>>618
そういえば →(口語化)→ そういやぁ →(短縮)→ そいや
かけ声じゃないよｗ
633:デフォルトの名無しさん
08/11/09 16:11:27
>>619
rebaseは、reset ＋ cherry-pick×n回 を自動化してるだけだから、マージとは違う。
たしかに、現在の変更をstashしてrebase後にstashから戻す、という作業も、
rebaseで自動でやってくれれば、もっといいかもしれないね。
634:デフォルトの名無しさん
08/11/09 17:26:06
URLﾘﾝｸ(www.thefreedictionary.com)
敢えてカタカナにするなら、「バザール」以外にどうしろというのだろう。
635:デフォルトの名無しさん
08/11/09 17:30:15
ござーる
636:デフォルトの名無しさん
08/11/09 17:44:37
>>632で>>618の意味がわかってﾜﾛﾀ
637:デフォルトの名無しさん
08/11/09 17:44:48
おおいなるマンション セザーーール
というのがあったな。
638:デフォルトの名無しさん
08/11/09 19:20:30
>>633
ありがとうございます。
変更したファイルがある状態で rebase したいとき、stashする方法と、ダミー commit + reset HEAD^ を使う方法を思いついたんですが、
どっちがいいと思いますか。
つまり
$ git stash
$ git rebase origin
$ stash apply
$ stash clear
または
$ git ci -a -m 'dummy'
$ git rebase origin
$ git reset HEAD^
のどっちがいいかという話です。
Git はまだよくわからんので、たとえばダミーでもcommitするのはイクナイ！とかあれば教えてください。
639:デフォルトの名無しさん
08/11/09 19:35:26
セザールはカエサル(シーザー)のフランス語読み。
640:デフォルトの名無しさん
08/11/09 20:19:12
おおいなるマンション バザールでござーる の巻
641:デフォルトの名無しさん
08/11/09 22:20:02
github についてなんですが…
誰か他人のプロジェクト
(1) git://github.com/誰か/プロジェクト.git
をforkしてできた
(2) git://github.com/自分/プロジェクト.git
をいじっても、(1)にpull requestを出してマージされない限りは
(1)に反映されることはないってことでいいんでしょうか？
642:デフォルトの名無しさん
08/11/10 09:57:54
hg qinit+qnewした状態でhg pushすると面倒なことになるんだけど
安全装置が付いてないのはなぜ?
643:デフォルトの名無しさん
08/11/10 11:03:26
>>641
はい、そうです。
他のひとのリポジトリを汚さないためのforkなので、当然です。
他のひとのリポジトリに書き込みしたいなら、そのリポジトリへのアクセス権をもらう必要があります。
644:デフォルトの名無しさん
08/11/10 19:27:04
>>628
ごめん、何がいいたいのかわかんない。
３行でまとめてくれ。
これじゃあBazaarのよさがわかんない。
645:デフォルトの名無しさん
08/11/10 23:30:17
>>642
面倒な事についてkwsk
646:デフォルトの名無しさん
08/11/11 00:12:47
>>644
リンク先は読んだ？ 図解までされてものすごく解りやすかったぞ。
647:デフォルトの名無しさん
08/11/11 07:13:45
>>643
ありがとうございます。
やっぱりそうですよね…
こないだ自分のリポジトリを更新したら、勝手にfork元の
リポジトリも更新されたように見えて焦ったんですが
相手がpullしたってことなんだろうか。。
648:642
08/11/11 12:29:09
>>645 pushじゃなくてpullだった
rm -rf repo myrepo
HGUSER=alice@example.jp
export HGUSER
hg init repo
cd repo
date >file
hg commit -A -m "start"
hg clone . ../myrepo
hg qinit
hg qnew PATCH
for X in 1 2 3; do
date >>file
hg qrefresh
cd ../myrepo
hg pull
cd ../repo
done
hg glog --style=compact
cd ../myrepo
hg glog --style=compact
649:642
08/11/11 12:30:08
+ hg glog --style=compact
@ 1[qtip,qbase,tip,PATCH] 1a93f26efdf7 2008-11-11 12:27 +0900 alice
| [mq]: PATCH
|
o 0[qparent] c96ce7235e6b 2008-11-11 12:27 +0900 alice
start
+ cd ../myrepo
+ hg glog --style=compact
o 3[tip]:0 1a93f26efdf7 2008-11-11 12:27 +0900 alice
| [mq]: PATCH
|
| o 2:0 b3c2e24e33e9 2008-11-11 12:27 +0900 alice
|/ [mq]: PATCH
|
| o 1 b6fb28c1e4ff 2008-11-11 12:27 +0900 alice
|/ [mq]: PATCH
|
@ 0 c96ce7235e6b 2008-11-11 12:27 +0900 alice
start
650:デフォルトの名無しさん
08/11/11 22:45:30
subversionでｺﾐｯﾄしてる内容を、Google Codeみたくブラウザでも見れるようにしたいんだけど、
それってTracﾅﾝﾁｬﾗみたいなのに移行しないとダメ？
651:デフォルトの名無しさん
08/11/11 22:47:15
>>650
WebDAV
652:デフォルトの名無しさん
08/11/11 22:48:13
ﾎｹﾞｰｯ!!!ごめんなすって！viewﾅﾝﾁｬﾗってので出来る感じね！
ｺﾞﾒﾝﾈｺﾞﾒﾝﾈ
653:デフォルトの名無しさん
08/11/11 22:49:04
>>651
ありがDo！＿|＼○_
654:デフォルトの名無しさん
08/11/11 22:59:27
>>646
>>623
>>>622
>bazaar＝分散型とはいえない
>>628のリンク先を読んだけど、
bazaarはやはり分散型だと思うのだが、
分散型ではないという根拠は何？
655:デフォルトの名無しさん
08/11/11 23:04:02
>>654
分散型を分散型として使わなくても良いって意味じゃね？
656:デフォルトの名無しさん
08/11/11 23:45:26
>>638
どちらでもいいと思いますよ。
私は普段git-svn使ってるので、よくrebaseすることになるんだけど、最近使うのはstashかな。
少し前のバージョンまではstashが無かったので、ダミーコミットしてやってましたが、
stashの機能自体、内部では同じようなことをやってるんだと思う。ソース見てないですが。
657:デフォルトの名無しさん
08/11/12 01:19:03
すごい遅レスだけど、分散型のメリットは一言で言うなら、
「リポジトリ同士で」履歴のマージ等の操作ができるという点では。
非分散型=集中型でも、手元にリポジトリ作ればローカル管理はでき、
ファイル自体は他のリポジトリに移せるけれども、
履歴等を他のリポジトリに移すとかってのはできない。
違うかな?
658:デフォルトの名無しさん
08/11/12 01:42:50
分散型は分散した運用が可能な設計であるが、集中型の運用も可能ということだよね。
反対に集中型が基本のシステムで分散的な運用が必要になる時はものすごく苦痛。
集中型のシステムで開発してたのが、会社合併、アウトソーシング等で分散型の運用が
必要になったことが二回ほどあるがかなり苦労した。
659:デフォルトの名無しさん
08/11/12 03:48:01
使ったことないが、bzrにはwikipediaにこういう記述があるから
> 中央サーバを使わない純粋な分散型バージョン管理システムと比べて、
> Bazaarは中央サーバ有り・無しの両方での動作をサポートしており、
> 同じプロジェクトに対し同時に両方の方法を使うことも可能である。
>>623が言いたかったのはそのこと(そういう機能？)じゃないか。
660:デフォルトの名無しさん
08/11/12 07:41:00
自分の作業するところは細かくコミットしたいから、こんなことやってる。
ちょっと面倒だし、もっと良い方法はあると思うけど。。
中央サーバ-からcheck out - A
coしたやつからbranch - B
Bをいじって適当にコミット
適当なところで、AでBの変更を取り込み
Aをコミットして中央サーバへ
更新を持ってくるときは、Aでupdateして, Bでpullする。
661:デフォルトの名無しさん
08/11/12 18:03:09
>>659
>> 同じプロジェクトに対し同時に両方の方法を使うことも可能である。
これすごいな。bzr++
662:デフォルトの名無しさん
08/11/13 01:42:08
集中型の利点は、チェックアウト→コミットの間の
ネットワーク転送量が少ない（記憶領域の使用量も少ない）ということかな。
分散型だと、リポジトリ全体を持ってきたりして、転送量がすごいことになったりするでしょ。
たとえば100GBのリポジトリをcloneすることを考えてみて。
663:デフォルトの名無しさん
08/11/13 01:55:40
|
＼ __ ／
＿ （ｍ） ＿ﾋﾟｺｰﾝ
|ミ| torrentみたいに分散させれば
／ ｀´ ＼
('A`)
ノヽノヽ
くく
664:デフォルトの名無しさん
08/11/13 06:44:35
CoreserverにTracってのを入れてみたいんだけど難しくて判んないよ～(´･ω･`)
665:デフォルトの名無しさん
08/11/13 07:02:40
>>664
レンタルサーバーか。
コンパイルしてホームにつっこむだけじゃないの？
666:デフォルトの名無しさん
08/11/13 08:04:20
Tracは依存関係がものすごいからな。
レン鯖の制限があると苦労しそうだ
667:デフォルトの名無しさん
08/11/13 10:08:28
Tracの話題はこっちじゃないかな
【バグ管理】 BTS使ってる？【追跡ﾞ】 ２
ｽﾚﾘﾝｸ(tech板)
668:デフォルトの名無しさん
08/11/13 10:59:24
>>667
ありがとう。いってきまーす。なにかヒントがあると良いな～(´･ω･`)
669:デフォルトの名無しさん
08/11/13 11:25:05
mantisっていうのは、TracやGoogle Codeみたいにファイル変更の差分が見れるものではない？(´･ω･`)
670:デフォルトの名無しさん
08/11/13 16:47:29
>>662
それ分散型か集中型かに関係なく仕組みによる。独立(standalone)なら全部取得だし、軽量(lightweight)なら一部のみ取得。
svnは軽量チェックアウト。
mercurialは独立ブランチ。
gitは軽量ブランチ。
bzrは独立チェックアウト(bzr co)、軽量チェックアウト(bzr co --lightweight)、独立ブランチ(bzr branch)。軽量ブランチはbzr cbranch --lightweightやbzr branch --stackedが当てはまるのかなぁ、良く分からね。
671:デフォルトの名無しさん
08/11/13 16:51:35
ああ、bzr cbranch --lightweightは勘違い。
他にも間違いありそうだから補足頼む。
672:デフォルトの名無しさん
08/11/14 01:35:44
日本語ディレクトリとかファイル名をバリバリに使ってるプロジェクトを
分散型バージョン管理システムで管理したいのですが、何を選択すべきでしょうか？
ちなみに環境はwindowsです。
（svkは試したのですが、あれは重すぎたのでそれ以外で）
673:デフォルトの名無しさん
08/11/14 06:51:19
使えるかどうかだったらhg, git, bzrのどれも使える。
ファイル毎にファイル名のencodingが違うとどれもダメだけど。
windowsだけならcp932だけになるのでどれもOK。
ただしTortoiseSVNのようなものを期待しているなら、
Hgにあるけどhgkだけが表示上は文字化けする、けど問題なく使えてる。
日本語ファイル名を使いたいならSVNが一番いいけど、
分散型でどれを選択すべきかはどれも微妙。
674:デフォルトの名無しさん
08/11/14 12:57:31
svn, bzrは基本的に問題ないだろう。
675:デフォルトの名無しさん
08/11/14 23:29:09
URLﾘﾝｸ(sourceforge.jp)
＞新規プロジェクトでは Git が標準で有効、CVS が無効に変更されました。
なんかすごいな。
676:デフォルトの名無しさん
08/11/14 23:32:56
>>675
おいおい、本家ではGit対応してなかったはずじゃ…と思ったら書いてある記事があった(下)。とはいえgithubやlaunchpadのように使えないと旨味が少ない気が。
SourceForge.JP、Gitのサポートを開始
URLﾘﾝｸ(www.itmedia.co.jp)
677:デフォルトの名無しさん
08/11/14 23:37:01
gitはWindowsで日本語ファイルはダメダメですよ
その前に、gitは日本語ファイル名を使うようなユーザー間ではまともに使えないと思うよ
678:デフォルトの名無しさん
08/11/14 23:44:59
集中型は svn、分散型は git になるのが加速されるのだろうか？
679:デフォルトの名無しさん
08/11/14 23:45:45
gitはないな
つうかいつまで集中型使われるんだ
680:デフォルトの名無しさん
08/11/14 23:46:17
☆ ﾁﾝﾁﾝ 〃 ∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
ヽ ＿＿_＼（＼・∀・） ＜ Bazaarの対応まだー？
＼＿／⊂ ⊂＿ ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
／￣￣￣￣￣￣ ／|
|￣￣￣￣￣￣￣| |
681:デフォルトの名無しさん
08/11/14 23:48:41
これで日本語ファイルのエンコード対応パッチも投げられるか。
682:デフォルトの名無しさん
08/11/15 00:24:51
国際化するなら、内部ではunicodeで処理、それぞれの環境でファイル名変換が妥当？
683:デフォルトの名無しさん
08/11/15 00:35:10
集中型はずっと使われると思うよ、svnで充分なこと多いし。
分散型はしばらく戦国時代だろうな。天下統一は遠いとみた。
684:デフォルトの名無しさん
08/11/15 01:04:10
Pythonで実装されてるやつは、Python3.0ベースになれば
文字コード問題は解決されそうだけどなぁ。
俺は、hgもgitも天下を取らないうちに次の新星が出てきて
そっちが天下を取ると思っているw
685:デフォルトの名無しさん
08/11/15 06:22:47
>>684
十分ありえそうな話ですね。
つうかgitでもhgでもbzrでもいいから、
一番優れた物がさっさと天下取ってほしい。
戦乱状態だと、使いつづけるのに不安が残る。
686:デフォルトの名無しさん
08/11/15 08:47:33
集中型は今はsvnって決まったも同然だから楽なんだけどね
687:デフォルトの名無しさん
08/11/15 12:52:08
>>677
Windows(Cygwin)のgitで日本語ファイル名を普通に使ってるけど
688:デフォルトの名無しさん
08/11/15 13:27:15
でも、やっぱプロジェクト内に浸透させるにはtortoise*が必要だわ
689:デフォルトの名無しさん
08/11/15 18:38:18
>>687
gitで日本語周りどういう風に運用してます？参考までに教えてください。
私が以前試したときの話ですが、
・UTF-8対応ターミナル用意した上で(もしくは、nkfとか通す前提で)
・コミットログは UTF-8
・エディタ(GIT_EDITOR)はデフォルトでUTF-8で起動させる必要がある
（UTF-8で起動できるソフトを使う。例：GreenPadなど）
・日本語ファイルは？ >>312 の問題があって、ここでオレはあきらめてしまった口だけど・・・
SJISだとWindows上ではOKだけど、
別プラットフォームだと×とかだったりしそうで
俺の周りだと、UTF-8ターミナル+cygwin+コマンドラインという環境用意させるのと、
日本語ファイル使う運用が矛盾をきたしたので結局やめてしまった。
（個人的にはオプソとかの開発とかパッチ作ったりには使ってる）
690:デフォルトの名無しさん
08/11/15 23:28:10
>>689
普通に、と書いてしまいましたが少しウソ。
Cygwin は ntf-8パッチの dllを使っています。
git は core level でファイル名の encode は考慮しません。
なので、ファイル名は utf-8 で統一します。
だた、これは subversion 等でも同じこと。
ツール群が良きに図らってくれるか、自分でそうするかという違い。
結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い
ということですけど。
691:デフォルトの名無しさん
08/11/16 00:28:43
> Cygwin は ntf-8パッチの dllを使っています。
はあ。そうですよね。まだ対応してませんもんね。
> ツール群が良きに図らってくれるか、自分でそうするかという違い。
こりゃまた「敷居」って言葉を考えさせる発言ですね。
692:デフォルトの名無しさん
08/11/16 00:46:20
>>690
Subversionはファイル名のエンコードはロケールに合わせてくれるので、
日本語ファイル名はOSXでのNFD問題以外は問題はないな。
> 結局(ファイルの中身以外)utf-8で統一するなら、何使っても問題無い
これはOSXとLinuxで日本語の濁点を含むファイル名を利用してみれば、
そんなに簡単ではないということが分かるハズ。
693:デフォルトの名無しさん
08/11/16 00:51:10
URLﾘﾝｸ(sourceforge.jp)
694:689
08/11/16 00:59:26
>>690
なるほど、過去レスでも出てたCygwinのUTF-8パッチですね。
これは、試してみないとあかんなあ。
>>692
そこまで考えてなかたよ
>>693
ニュース: Gitサポートを開始しました - SourceForge.JP - SourceForge.JP
URLﾘﾝｸ(sourceforge.jp)
ソースフォルゲは相変わらず、Windows軽視だよなあｗ
695:デフォルトの名無しさん
08/11/16 02:28:02
Windows（笑）
696:デフォルトの名無しさん
08/11/16 05:40:03
>>684
Mercurialは3.0待ちかもしれないけど、Ｂａｚａａｒはもう日本語まったく問題ないよ。
ＴｏｒｔｏｉｓｅＢｚｒも日本語ちゃんと扱えてる。
(参考) URLﾘﾝｸ(dsas.blog.klab.org)
697:デフォルトの名無しさん
08/11/16 09:25:01
全角英数字使う奴は信用ならん
698:デフォルトの名無しさん
08/11/16 09:30:12
とはいえBzrにTotoiseがでたんだね。試してみる価値はありそう。
あとは速度がhg以上なら乗り換えるんだが。
699:デフォルトの名無しさん
08/11/16 10:21:09
>>696
やっぱり日本語だめだったよ。
TortoiseBzrで Init して日本語ファイル名をTortoiseBzrでaddし、
ファイルの中も日本語にしした結果、
TortoiseBzrでdiff → ファイル名は日本語で表示されるが中身が文字化け
cmd.exe上でdiff→中身は日本語で表示されるがファイル名が文字化け
ちなみに1.9のレポジトリフォーマットにしてみた。
あとGeneral Bazaar Options.. が開かないがバグかな。
それと、デスクトップ上でInitしようとしたらできなかった。
空文字入りパスは対応できない様だ。
ちょっと使っただけでこれだけ不具合が見つかる様じゃ、
まったく実用に耐えないね。まぁ、今後に期待はするが。
700:デフォルトの名無しさん
08/11/16 11:09:39
>>696
MercurialはUnicodeベースに変更できるからもう問題ないだろ
どこに問題があるんだ？
701:デフォルトの名無しさん
08/11/16 11:22:35
TortoiseBzr入れてみたんだが、そもそも日本語フォルダで Init できないのは
なんか設定ミスってる？
702:デフォルトの名無しさん
08/11/16 11:29:59
つかこれだけ国際化についての問題意識が広まっていながら
この体たらくって一体なんなんだろうね
703:デフォルトの名無しさん
08/11/16 11:44:30
海の向こうの変な文字のことなんて気にしないニダ
704:デフォルトの名無しさん
08/11/16 12:16:05
海の向こうはマジで
「『漢字』などという象形文字を使っている国は文化レベルが低い」
と思ってるらしいぜ。
705:デフォルトの名無しさん
08/11/16 12:29:26
自分らの文字は letter で漢字は character ですって。笑わせますよね。
706:デフォルトの名無しさん
08/11/16 12:38:03
よく体に漢字を彫ったりしてるじゃんｗ
自分にないものは格好良く見えるのか
707:デフォルトの名無しさん
08/11/16 12:39:08
全角英数字使う奴は信用ならないというのは正解だったということか。
708:デフォルトの名無しさん
08/11/16 12:43:00
>>706
あれはイラスト
709:デフォルトの名無しさん
08/11/16 13:20:05
>>699
あー、diffは仕方ないね。Subversionだって同じだろ？
ああ、「ファイル名」は日本語に対応しているけど、「ファイルの内容」は
文字コードとか気にせずにそのまま記録しているだけだから、
文字コードの自動認識してくれないdiffで見ると中身文字化けする。
ＷｉｎＭｅｒｇｅのような、文字コードを自動認識してくれる外部diffを使わないと
いけないな。
710:デフォルトの名無しさん
08/11/16 13:44:17
デスクトップ上でも空文字(スペース？)入りパスでもInitできたけど、なにが違うんだろ
711:デフォルトの名無しさん
08/11/16 14:28:10
>>709
すべてwindows上でやってるのにそれはないだろ。
subversionで同じ事やっても文字化けなどしないよ。
712:デフォルトの名無しさん
08/11/16 15:38:08
文句言うだけじゃなくて、日本人がもっと開発に参加して
日本語バッチリにしてやろうぜ。
713:デフォルトの名無しさん
08/11/16 15:50:37
Tortoise BZR doesn't support repos with non-latin characters in path
URLﾘﾝｸ(bugs.launchpad.net)
714:デフォルトの名無しさん
08/11/16 15:55:10
>>711
いやいや、俺Windowsでも普段UTF-8でテキストファイル書くし。
エンコーディングの自動判別していない限り、「たまたま」テキストファイルの
エンコーディングと表示に使うエンコーディングが一致したときに化けずに
表示されるだけ。
715:デフォルトの名無しさん
08/11/16 16:14:08
つーか中国でも普段使いの文字コードはだいたい１つだし、
環境によって文字コードを３種類から使い分ける必要がある国なんて日本ぐらいなんじゃね
日本人が対応するしかないだろ
716:デフォルトの名無しさん
08/11/16 16:18:12
>>700
設定の煩雑さ。
…使ってるけどさ。
717:デフォルトの名無しさん
08/11/16 16:32:36
>>715
何言ってんだ
中国のほうが環境によって使われる文字コードは多いだろ
日本語の EUC-JP(UNIX系),シフトJIS(DOS系),JIS(メール)に対応するものが
中国にもある上、繁体字・簡体字の区別もある
718:デフォルトの名無しさん
08/11/16 16:48:02
URLﾘﾝｸ(repo.or.cz)
719:デフォルトの名無しさん
08/11/16 17:05:02
>>718
Windowsでまともに動かないのにwww
作ったやつは頭がいかれてんじゃねwww
720:デフォルトの名無しさん
08/11/16 18:46:33
>>717
中国の 繁体字 簡体字 は文字体系そのものが違うから関係無い話
繁体字で保存したテキストを簡体字で読むこともあるとか考えてたなら帰れ
721:デフォルトの名無しさん
08/11/16 22:34:07
>>720
バカの言い訳は見苦しい
そもそも何の話をしてるか理解してるか？
722:デフォルトの名無しさん
08/11/16 22:52:07
>>720
723:デフォルトの名無しさん
08/11/16 22:59:30
>>721-722
何の話をしてるか理解していないようだから言っておくが
中国では繁体字 は big5 簡体字は EUC で FA だ
日本のように保存したファイルを別の文字コードに変換して表示したい
＝Windows でコミットしたファイルを Unix でも見たい
と言った状況でも何ら問題無いため文字コードの変換という実装は必要無い
＝現在の実装でも運用にさしたる問題は生じない
＝運用に問題が生じる日本から声を出していかないと開発側には問題が伝わらない
分かったなら俺と一緒に英語メールの書き方勉強しろや
724:デフォルトの名無しさん
08/11/16 23:04:45
簡体字はgbの方が主流。適当に語るのはやめれ。
725:デフォルトの名無しさん
08/11/16 23:10:06
EUC-CN と GB は同じだから。
726:デフォルトの名無しさん
08/11/17 00:00:04
bzrのdiffがコードページを無視してutf8を使ってるという話が、
文字コード自動判別の話になり、
中国語の文字コードの話になって、
文字コードを勝手に変換してプラットフォーム間の差異を吸収して欲しいという話になりました。
終わり。
727:デフォルトの名無しさん
08/11/17 00:06:21
出力時にコンソールのコードページをcp65001にすればいいだけじゃ?
728:デフォルトの名無しさん
08/11/17 00:17:32
中国はどうでもいい。
日本語環境だけが興味あるんだが。
729:デフォルトの名無しさん
08/11/17 00:20:22
日本語環境
svn >> git > hg >> bzr
でFA?
730:デフォルトの名無しさん
08/11/17 00:28:56
svn = bzr > hg = git
731:デフォルトの名無しさん
08/11/17 00:39:26
gitとhgは中身がロケール依存なので個人的にはなしの方向だな
732:デフォルトの名無しさん
08/11/17 01:32:34
gitがその位置ってのはありえないだろう
733:デフォルトの名無しさん
08/11/17 01:34:08
ごめんgitありえないだろうは、>>729ね。
734:デフォルトの名無しさん
08/11/17 07:19:22
おいおい、windows環境だけで化け化けの
bzrはどう見ても最下位だろう
735:デフォルトの名無しさん
08/11/17 09:04:21
>>734
化けて見えるのはdiffの表面上の問題だけで、リポジトリの中身はしっかりしてるから。
diff も、 bzr diff | vim - みたいにエディタで見れば問題ない。
svn, bzr:
ファイルの内容はそのまま、ファイル名はUnicode
(Windows と Linux で日本語ファイル名のファイルを行き来させても大丈夫)
git, hg:
ファイルの内容はそのまま、ファイル名もそのまま
(Windows と Linux で日本語ファイル名を行き来させるとどっちかで化ける)
736:デフォルトの名無しさん
08/11/17 09:38:33
svnもcygwin版じゃダメだぞ
737:デフォルトの名無しさん
08/11/17 09:44:32
>>736
cygwinはlocaleないからなぁ。。。
UTF-8版cygwinならなんとかなるのかな。
738:デフォルトの名無しさん
08/11/17 12:19:57
>>735
ログは皆UTF-8かな?
739:デフォルトの名無しさん
08/11/17 12:20:23
結局どれやねーん
740:デフォルトの名無しさん
08/11/17 12:36:08
>>739
わかるぞ、その気持ち
741:デフォルトの名無しさん
08/11/17 15:08:35
名前 bzr >>> hg >> git # ギット(笑) 商売の神マーキュリーから取った"気が変わりやすい"(笑)
コマンド名 hg >> git >>>>> bzr # 打ちやすさから。hgとmercurialの差が大きすぎるのは考慮してない。
使いやすさ ??? # 主観入るだろうから省略
Webインターフェース bzr > git >>>> hg # bzrはloggerhead(hgwebの派生)ね。hgwebの使いにくさは異常。
ホスティングサービス bzr >>>> git >>>> hg # launchpadはバグトラッカー付きでいたれりつくせり、githubは普及している、bitbucketは…
拡張性 bzr >>>> hg >> git # gitはC言語だからしゃーねーわな、でもgit-svnの酷さはフォローしない。あとhgは内部APIがショボいとか。プラグインの数の少なさからも裏付けられる。
設計の良さ bzr >> git > hg # 抽象化度
実装の良さ git >>>> bzr > hg # diffやmergeのアルゴリズムとか
SVNとの親和性 bzr >> git >>>>>>>> hg # bzrはbzr-svn、gitはgit-svnで評価。
使用率 git >>>> hg > bzr # Debianのpopconのデータからなので正確では無い
速度 git >>>> hg = bzr(1.9) >>>>> bzr(pack-0.92) # ちゃんと計測していない…。ちゃんと計測したいが…。
将来性 git >>> bzr >>> hg # gitはLinux Kernelで使われ続ける、bzrはUbuntuで使われ続ける、hgは…?
国際化 ??? # どれも完璧じゃない。cygwinに関してはcygwin側の問題だからそちら側で解決してもらえ…と言いたいけど、確か開発元がRHだから無理だろうなぁ(RH/Fedoraは未だに閉鎖的と感じる)。
とりあえず速度厨はgitを、拡張厨はbzrを、どっちつかずはhgを使っておけば良いと思うよ^^
742:デフォルトの名無しさん
08/11/17 15:53:35
たぶん、日本国内だと、日本語解説サイトの数や充実度と、解説本の数で
勝負が決まってしまうと思う。Fedoraが日本でだけ万人向けディストロとして
流行ったみたいに。
743:デフォルトの名無しさん
08/11/17 17:46:56
hg のフォローしておくと、まず Mozilla や Sun では使われてる。
あと、コマンドが少なくて良い。同じことをやるのに迷う必要が無い。
一番良いのが基本的に push pull が HTTP で完結してること。
FW の設定いらんから大概使える。
Tortoise も一応あるし、速度 git 拡張 bzr 可搬 hg ってことにしといて。
744:デフォルトの名無しさん
08/11/17 18:08:02
>Mozilla や Sun では使われてる
いや、そうでなくVCS自体の開発の後ろ盾の話。gitならLinuxのカーネルコミュニティ、bzrならCanonicalだけど、hgはどうだっけか。
>コマンドが少なくて良い
--helpに出てくるコマンド多くね? むしろいくつかの面白いコマンドがあるところがhgの利点だと思うが。
>push pull が HTTP で完結
bzrもgitも対応してね?
745:デフォルトの名無しさん
08/11/17 19:23:02
hg mercurial >> bzr bazaar
URLﾘﾝｸ(www.google.com)
git >> hg mercurial
URLﾘﾝｸ(www.google.com)
git > subversion
URLﾘﾝｸ(www.google.com)
subversion >> git (in japan)
URLﾘﾝｸ(www.google.com)
746:デフォルトの名無しさん
08/11/17 19:29:59
git って HTTP で完結してたの？
747:デフォルトの名無しさん
08/11/17 19:33:08
>>746
URLﾘﾝｸ(en.wikipedia.org)
Bazaar: HTTP, SFTP, FTP, custom, custom over ssh, email bundles, WebDAV (with plugin)
Git: custom, custom over ssh, rsync, HTTP, email, bundles
Mercurial: HTTP, custom over ssh, email bundles (with standard plugin)
748:デフォルトの名無しさん
08/11/17 20:43:18
>>747
FTP, SFTPがあることにびっくりだよBazaar!
749:デフォルトの名無しさん
08/11/17 22:20:07
主観は入りまくりだけど、そこがよい
>>741乙
750:デフォルトの名無しさん
08/11/17 22:39:12
>>735
表面が化けてちゃ、おいしさも半減なわけですが。
いちいちvimでなんかみたくないし、Tortoiseで化けるのは
設定でなんとかなるの？
751:デフォルトの名無しさん
08/11/17 23:11:22
>>750
Tortoiseの方は.bzr/.branch/branch.confで
「encoding = エンコーディング」を指定したら
logメニューからの表示は文字化けしなくなった。
diffメニューからの表示は文字化けするようだ。
コマンドラインから起動する場合はbzr qdiff --encoding=ARGで
一回実行すればエンコーディングのオプションはbranch.confに記録される。
752:デフォルトの名無しさん
08/11/17 23:15:17
>>741
Gitのマージアルゴリズムはhgやbzrよりも劣るんじゃなかったっけ。
最近はそうでもないのかな?
753:デフォルトの名無しさん
08/11/18 02:47:52
Mercurialで、不要になったbranchを閉じるって、今のところ実装されてないんだね。
↓一応、対策は提案されてるけど。
URLﾘﾝｸ(www.selenic.com)
開発チーム内に余計なbranchを作る奴が居ても、ずっと放置か。
hg branchしてない、名無しのheadでも同じ事だよね。
今のところは、リポジトリのcloneによる（概念的）branchの方が整理をつけやすくて
安全って事なのかな。
754:デフォルトの名無しさん
08/11/18 03:01:03
>>748
そう。さくらのレンタルサーバーとか、FTPやsftpが使えれば、サーバーに
bzrをインストールしなくてもクライアントにだけbzrがあれば使えるのが強み。
これに慣れると、gitとかサーバー側にインストールするの面倒。
755:デフォルトの名無しさん
08/11/18 03:06:22
>>750
中身がしっかりしてれば、表面なんてどうにでもなる。
あるひとつの条件で、たまたまsvnが化けずにbzrが化けたからって、
svnの方が良いと考えるのは軽率すぎる。
bzrで化けるときの対策方は>>751が教えてくれたけど、TortoiseBzrで
WinMerge使えるようにはしたいね。今忙しいけど、手の空いたときに
試してみる。
756:デフォルトの名無しさん
08/11/18 03:17:06
>>754
sshfs でマウントしてしまえば git だろうが hg だろうが自由自在だと思うが.
757:デフォルトの名無しさん
08/11/18 03:25:17
Windowsでsshfsとかできないじゃん
sshfsする一手間が面倒じゃん
そもそも、安いレンサバだとssh使えないでFTPだけ使えるとかあるじゃん。
758:デフォルトの名無しさん
08/11/18 06:49:18
>>755
bzrは日本語全く問題ないんではなかったのか？
問題ありありなわけだが。嘘つき。
単一プラットホームで化けるなんて、中身がどうのこうの以前の問題だろ。
いくら、小手先の対策示しても意味ない。
759:デフォルトの名無しさん
08/11/18 11:33:44
>>758
そもそもdiffってのは、二つのファイルのエンコーディングと、ファイル名のエンコーディング、
合計3つのエンコーディングが混ざってるから、「完全」なんてありえないんだよ。
たとえば、コンソールでdiff出力してファイル名が化けるのは、ファイル名をUTF-8で出してるから。
svnで化けないって事は、svnはlocaleやコードページに変換してるんだろうな。
でも、そのdiffで作ったパッチを、メールでLinuxユーザーに送ったらどうなると思う？
「問題ない」といってるのは、「ソ連」みたいな0x5c問題や、環境依存のファイル名エンコーディングを
そのままリポジトリにぶち込んでしまってほかの環境でファイル名が化けたりといった、日本語
ファイル名を扱う上での話をしてるんだよ。
760:デフォルトの名無しさん
08/11/18 15:21:47
それってdiff一般の話じゃないよね。
bzrのdiffの実装がそうなってるってこと？
761:デフォルトの名無しさん
08/11/18 20:01:04
>>760
コンソール上のdiff一般の話だよ。
diffが化けないのは、(1)コンソール、(2)ファイル名、(3)二つの入力ファイルの内容
すべてのエンコーディングが一致したときのみ。
ファイル名に関しては、diffで作ったパッチを送信したりすることを考えるとエンコーディングを
統一するべきで、統一するならUTF-8が妥当。なので、コマンドプロンプトをchcpでUTF-8
モードにするか、 diff | gvim - みたいにテキストエディタで見るしかない。
Linux でも、 diff の出力はリダイレクトでファイルに保存するかパイプで直接エディタで見るのが基本。
Bazaar Plugin の extdiff を使えば、外部の diff プログラムと連携できる。Windowsなら
WinMergeとか使うと吉。
762:デフォルトの名無しさん
08/11/18 20:02:56
>>755
せっかくなので外部コマンドとエイリアスの使い方を書いておきます。
当面はコマンドツールとの併用になるでしょうから。
bzr diffでWinMergeを使いたいならオプションとして--using=WinMergeを指定します。
WinMergeの注意事項としてはmlang.dllによるコードページの検出オプションを
有効にしていないと付けないと文字化けします。
オプションの入力を省略したければbazaar.confファイルを
編集してエイリアスを設定します。
設定ファイルの位置はbzr versionで見つかります。
[ALIASES]
diff=diff --using=WinMerge
763:デフォルトの名無しさん
08/11/18 20:10:06
ちなみに、GUIのdiffプログラムだとテキストエディタと同じで文字コード指定が
簡単にできたり自動認識したりすると良くて、その点 TortoiseBzr の中の qdiff は
機能不足。（これはBazaarの問題ではないが、周辺環境が揃ってない一例）
俺はソースをはじめテキスト類は全部UTF-8で書いてるから qdiff でも全く文字化け
しない。
Windowsも早く日本語の標準マルチバイトエンコーディングをUTF-8にすれば良いのに、
いつまでcp932なんて使ってるんだろう・・・
764:デフォルトの名無しさん
08/11/18 23:43:44
cp932なのはwindowsが悪いけど、
今のbzrだと文字コードのせいですんなり使えないね。
765:デフォルトの名無しさん
08/11/19 01:05:57
Mercurialのレポジトリをhgwebdir.fcgiで公開してるんだけど，これってすごく重くない？
うちのサーバがボロってのもあるかもしれないけど，大きめのファイルを開くと一気に
ロードアベレージが跳ね上がってしまう．
pdfファイルに至っては選択するといつまでたっても応答が返ってこないでCPU食いつぶしてるし．
これってこういうもんなの？
766:デフォルトの名無しさん
08/11/19 01:51:29
>>765
スペック、構成、設定、ロードアベレージは具体的にどのプロセスが、IOとCPUのどちらで
重いのか、hg serve と比べてどれくらい遅いのか。
これくらいまとめてから質問しようぜ。
767:765
08/11/19 10:04:11
>>766
単に愚痴るだけのつもりだったんだけど，そのくらいの情報は出しとかないと
毒にも薬にもならんわな．すまん．
サーバ機のスペックは
CPU: Celeron 2.4GHz （詳しいことは忘れた．4年前くらいのセレロン）
メモリ: 256MB
OS: Ubuntu 8.10
このマシン上でlighttpdからhgwebdir.fcgiを呼び出してる．
hgwebdir.fcgiはHGENCODINGをUTF-8に指定したくらいで，
他は特ににいじってない．
各レポジトリはbz2，gz，zipでのダウンロードを許可していて，
pushにはDigest認証が必要にしてある
で，pdfを開くと応答が返ってこないんだけど，このときCPU使用率が
跳ね上がっていることを確認済みで，IOなどは特に異常な数値は示し
ていない．原因になっているプロセスはwebサーバを走らせているユー
ザの権限で動いている
python /usr/share/hg/cgi-bin/hgwebdir.fcgi
他の形式（テキスト形式のファイルや画像）だと，pdfよりサイズが
大きい場合でも一時的にCPU使用率があがるものの，きちんと表示される．
あと，hg serveだと動作が軽快にはなってるみたいなんだけど，
pdfを開こうとすると上で書いたのと同じような症状になって応答が
返ってこなくなる．
768:デフォルトの名無しさん
08/11/19 10:12:13
>767
知らんけど、内部でPDFをテキスト化するツールとか、Ghostscriptとかを
呼び出そうとしてトラブってるんじゃないの？ Prostscriptの記述がバグって
無限ループしてるとか、展開サイズが大きすぎてメモリ不足になってるとか。
769:デフォルトの名無しさん
08/11/19 12:10:57
TortoiseHg 0.5での質問があります。
・日本語ログがupdate revisionで化けるので、事実上日本語ログが使えなくない？
・GUIで hg mv する方法はないのでしょうか？
・pushした日本語ファイル名がWindows以外の環境で化ける、というのは本当でしょうか？
770:766
08/11/19 12:21:38
>>767
ん、メモリが少なめだから、全体的にロードアベレージが高いのは
リポジトリがキャッシュからすぐに消えちゃってる可能性がある。
pdfに関してはIOが低いならメモリの問題じゃないんだけど、Mercurialは「pdfだけ」
という処理はしてない。変なプラグインは入れてないよね？
ということで、こっからエスパー。
pdfって、ブラウザプラグインで、ブラウザの画面内に表示してない？
その場合、HTTPクライアントはブラウザじゃなくてプラグインになってるから、
それが分割ダウンロードとかしようとして負荷をかけてる可能性がある。
Adobe Readerのブラウザプラグインを無効にして、ブラウザが
「テンポラリファイルに保存→スタンドアロンのAdobe Reader 起動」
するようにしてみて。
あと、hg serveで軽くなるなら、fcgiの設定が良くない（メモリ食い）という可能性がある。
fcgi使ったこと無いんだけど、スレッド数やプロセス数を減らせない？
lighttpd も同時接続数を3くらいに減らしてみて。
771:デフォルトの名無しさん
08/11/19 12:31:35
>>769
最後の問題、ファイル名エンコーディングをロケールから判別して、リポジトリに
入れる前にUnicodeへデコードするパッチを日本人が本家MLに送ったんだけど、
「ファイル名はファイルの内容と同じでバイナリ弄らない」とか言われてrejectされた。
なので、今は win32mbcs という拡張で対応しないといけない。一人でも対応してない
ヤツがpushしたら、そのリポジトリはcp932ファイル名で汚される。
ただし、これはコンソールのエンコーディングがUTF-8じゃない場合の話で、
TortoiseHgだと最初からUnicodeでファイル名を使ってるかもしれない。
俺は TortoiseHg 使ってないんだけど、コンソールとTortoiseで日本語ファイル名を
やり取りしてみたら？
772:769
08/11/19 12:36:20
> ・pushした日本語ファイル名がWindows以外の環境で化ける、というのは本当でしょうか？
そもそも、Mercurialでは日本語ファイル名がコミットできないようです。
TortoiseHgでは、コミットウインドウでファイルを追加してもcommitボタンが押せず、
全選択チェックボックスを押すとcommitボタンが押せるのですが、
正常コミット時のように閉じてくれず、hg stで確認しても変化なしでした。
コマンドラインのhgでは、
> hg ci -A -m "initial commit from command line"
adding ・が怖い、・の・フトSJIS.txt
removing ・が怖い、・の・フトSJIS.txt
・が怖い、・の・フトSJIS.txt not tracked!
・が怖い、・の・フトSJIS.txt does not exist!
nothing changed
というように言われ、hg stで確認しましても変化ありません。
実はWindowsでのhgは日本語ファイル名に対応してなかったのですね・・・。
TortoiseHg 0.5と付属のコマンドラインのhgで確認しました。
ファイル名：表が怖い、噂のソフトSJIS.txt
中身は適当な感動コピペをSJISで保存です。
773:769
08/11/19 12:40:13
>>771
ああ、わかりました。
標準でSubversionのようにUnicodeへのデコードなどはやってないわけですか。
で、ロケール（日本語WindowsだとSJIS？）で入ってしまう、と
（そもそも入りすらしなかったけどｗ）
ファイル名とかログのエンコード周りは基本的なことだと思うのになあ。
OSSで使うならなお更なのに・・・
774:デフォルトの名無しさん
08/11/19 12:46:20
>>773
入りすらしないのは、0x5c問題だと思うよ。
0x5cが入ってないファイル名だと、コミットはできるけど、そのままリポジトリに入っちゃう。
(から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)
そもそも「ファイル名はバイト列として変更せずに扱う」というポリシーが間違ってると思うけど、
外国人には伝えにくいからねぇ。gitは最初からWindowsなんて気にしてないし。
Python3.0になると、文字列＝unicodeになるから、「ファイル名のバイト列」自体消滅する。
MercurialもPython3.0対応する時点で嫌でもポリシーを修正するはず。
その前にBazaarに乗り換えたほうが幸せな気もする。
775:765
08/11/19 13:03:46
>>768
Mercurialのレポジトリブラウザってpdfをテキスト化して表示するの？
コード眺めた感じそれっぽい部分は見当たらなかったけど．
>>770
> pdfに関してはIOが低いならメモリの問題じゃないんだけど、Mercurialは「pdfだけ」
> という処理はしてない。変なプラグインは入れてないよね？
そうなんだよね．なんでpdfに限ってこんなことになるのかがよくわかんない．
プラグインもなにも入れてないです．
> Adobe Readerのブラウザプラグインを無効にして、ブラウザが
> 「テンポラリファイルに保存→スタンドアロンのAdobe Reader 起動」
> するようにしてみて。
やってみたけど，症状はかわらずです．
というか，テキスト表示できないタイプのファイルってチェンジセットから
選択すると，最初に"これはバイナリファイルですよ"みたいなページに
遷移するよね？そのページのrawの項目を選択するとダウンロードが始まる，
みたいな．
pdfの場合，チェンジセットから選択したあとの最初の遷移の段階でとまって
しまうので，そのあたりは関係ないような気もする．
> あと、hg serveで軽くなるなら、fcgiの設定が良くない（メモリ食い）という可能性がある。
> fcgi使ったこと無いんだけど、スレッド数やプロセス数を減らせない？
> lighttpd も同時接続数を3くらいに減らしてみて。
いちおうlighttpd側でmaxprocsを3にはしてあるんですけど，だめですね．
776:769
08/11/19 13:05:29
>>774
> (から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)
いけますタ！
hg と TortoiseHgの両方でいけることを確認しました。
どうやらすごいFAQみたいですね。
それにしても、TortoiseHgがコミットログやらファイル名やら化けまくりで実用に耐えられないなあ・・・
プログラマはそんなでもないけど、デザイナとか複数人で使う時に、
英語ファイル名、英語ログ強制はまず使ってもらえないわ ｗ
バージョン管理ソフトとかこういう環境的な物の導入には、
手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。
> その前にBazaarに乗り換えたほうが幸せな気もする。
そちらを検討してみます。
いろいろ教えてくれてありがとう。
777:769
08/11/19 13:06:19
> バージョン管理ソフトとかこういう環境的な物の導入には、
> 手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。
バージョン管理ソフトとかこういう環境的な物の導入には、
ソフトウェアの使い勝手よりも、むしろ
手回しが一番重要だということはわかっているつもりだけど、さすがに致命的すぎる。
778:766
08/11/19 14:24:59
>>775
あらら、エスパー失敗か。
じゃぁ、その pdf ファイルの先頭 4096 バイト内に 0 というバイトが存在しないと予測。
Mercurialは先頭4096バイトの中に 0 が有るかどうかでバイナリとテキストを判別しているから、
テキストだと思って頑張って表示しようとしている可能性がある。
779:デフォルトの名無しさん
08/11/19 14:33:54
>>774
> (から、win32mbcs が必要。 mercurial.ini の [extensions] で win32mbcs= という一行を追加)
環境変数 HGENCODING に cp932 を設定するのとでは何か違いある？
780:765
08/11/19 17:35:50
>>778
それであたりっぽい．util.binaryが問題の部分だね．
開発ブランチだとファイル全体で0というバイトの有無を判定してるので，
そっちを使ってみることにするよ．
今サーバが落ちてるので，結果がわかり次第また書き込むわ．
781:デフォルトの名無しさん
08/11/19 17:57:13
Mercurialは、どんなにTortoiseの完成度が高くなっても
デザイナーには使えない。概念的な部分の複雑度が高すぎる、
ってのが俺の印象だな。
プログラマーさえ、チームの2割もまともに理解できる奴いないと思う。
782:デフォルトの名無しさん
08/11/19 19:14:28
PDFってテキストファイルの中に一部バイナリ埋まってるような構造だからなぁ
783:765
08/11/19 20:44:14
765です。>>766さんの指摘で問題解決したので報告します。
問題の原因はファイルがバイナリかテキストかを判定するutil.binaryが、ファイルの先頭4096バイ
ト中に0というバイトがあるかどうかをチェックしていたことでした。
なので、この問題はutil.binaryを書き換えることで解決可能です。最初は開発版を使おうかと思って
いたけど、書き換えのみでとりあえず解決できたのでそうしました。ちなみに、バージョン1.0.1
のものを書き換えました。
書き換え自体は簡単なのでここには書かないけど、わからなければ開発版のコードを見れば大丈夫。
以上報告でした。付き合ってくれた方々ありがとう。
784:デフォルトの名無しさん
08/11/19 21:04:22
git format-patch でできたパッチを適用するのは git am しかないんでしょうか。
メールボックスとかシランので、単に git format-patch でできたパッチを適用したいだけなんですけど。
785:デフォルトの名無しさん
08/11/19 21:17:51
>>784
git am 0001-patch-name.patch
でいけました。メールボックスじゃなくてもいけますね。すんません。