08/02/02 10:35:54
git-svnよいねぇ。
svnで開発するのは無理自慰だし、svkなんか微妙だし(エラーハンドリングが微妙)、git使いやすいから楽だ。
370:デフォルトの名無しさん
08/02/02 21:32:56
>>364
だがそれがいい。
VBはDLLを要求しやがるから困る。
>>368
その記法はPython3000だとエラーなんだよな～
これに限らず、いまhgを完全にUnicode化しても、
新たに作業が発生しそうで躊躇する。
371:デフォルトの名無しさん
08/02/02 22:18:52
Mercurial vs git
ここ分かりやすいな 短いけど
URLﾘﾝｸ(www.atmarkit.co.jp)
372:デフォルトの名無しさん
08/02/02 22:26:51
>>371
2005っていつの記事だよ、と思ったらやっぱり三年前じゃねえか。
こんなの今と相当違ってるぞ？
373:デフォルトの名無しさん
08/02/02 22:30:17
>>372
メインはsvnだけど 気になる２人なので基本的な情報を集めようとしてるんだけど
やっぱりそうですか。
すんません
374:デフォルトの名無しさん
08/02/02 23:37:34
>>369
> git-svn
kwsk
手元でgitで、サーバー側のsvnにコミットする手法？
375:デフォルトの名無しさん
08/02/03 02:32:45
TortoiseHg 0.3 が出たな
376:デフォルトの名無しさん
08/02/03 09:23:46
>>374
まぁそういうこと。コミットもできるけど、まだしてない。(権限がなす)
BTSにパッチ上げる開発用にローカルでつかってる。
普段のそー言うのは、git-svn cloneのほうでブッコ抜き。
git-svnimportの方はログコンバーターなのでリポジトリをgitに移行するときだけですね。
377:デフォルトの名無しさん
08/02/03 10:33:35
ブランチをマージしようとしてsvn mergeがフリーズしたので、
代わりにgit-svn で git上でマージできてよかった。
だけど、svn:externals とかgit-svnは扱ってくれないのね。
svn:ignoreはgit-svnで一応扱えるけど、機能が微妙。
378:デフォルトの名無しさん
08/02/03 17:43:28
【10.1】 「日本語ファイル名を追加できない」
URLﾘﾝｸ(python.matrix.jp)
379:デフォルトの名無しさん
08/02/03 18:46:02
・既出
・ググればすぐ出る
・直リン
380:デフォルトの名無しさん
08/02/04 13:59:43
直リン？
381:デフォルトの名無しさん
08/02/07 15:08:37
燃料?
URLﾘﾝｸ(texagon.blogspot.com)
382:デフォルトの名無しさん
08/02/07 19:30:51
お前初めてかhgは?
力抜けよ
383:デフォルトの名無しさん
08/02/07 20:21:09
>>381
文章の先頭から大嘘じゃないかｗｗｗ
384:デフォルトの名無しさん
08/02/07 22:18:11
>>383
ごめん，どこが？
385:デフォルトの名無しさん
08/02/08 19:10:44
subversion での svn update は、git では git pull でしょうか。
git clone したリポジトリがあって、これを更新したいんだけど、git pull だけでいいのでしょうか。
なんかうまくいってるのかどうか分からなくて。
386:デフォルトの名無しさん
08/02/08 20:44:36
>>385
それで合ってる
git branch -r でorigin（pullしてくる元）が表示されるはず
git スレッド
ｽﾚﾘﾝｸ(linux板)
387:デフォルトの名無しさん
08/02/12 15:47:32
>>303
使い方がよくわからないんですが、Mercurialを新しくするだけではだめなんでしょうか?
$ hg add
adding クソ.txt
ク・.txt does not exist!
みたいになってしまいます。
388:デフォルトの名無しさん
08/02/12 18:55:56
sjisファイルネームは通らない。
389:デフォルトの名無しさん
08/02/12 23:14:55
SVN(TortoiseSVN)だとその辺もやってくれるんだけど、Hgはやってくれないか
390:387
08/02/13 13:33:47
>>387
extentionを有効にしてなかったせいでした。
Mercurial.iniの[extensions]に
hgext.win32mbcs =
を足したらちゃんとaddできるようになりました。
391:デフォルトの名無しさん
08/02/14 00:06:24
はじめてMercurialを使ってメッセージの意味がわからない…
Rev.1から 2 と 3 を分岐させて(>hg heads で 2と3が出る)、作業ディレクトリが
Rev.3の状態で 2の枝とマージすることを意図して
>C:\Temp\repo>hg merge 2
ってすると(設定しているWinMergeが立ち上がって編集保存すると）
>merging a.txt
>merging a.txt failed!
>1 files updated, 0 files merged, 0 files removed, 1 files unresolved
>There are unresolved merges, you can redo the full merge using:
> hg update -C 3
> hg merge 2
fail とか unresolved とか不吉な単語が見えるけれど、
>hg commit -m "..."
すると、ちゃんと Parentsに 2と3を持つ Rev.4 が出来ている。
編集した a.txt はちゃんと編集後の状態を保ってる。
これって正しい動作なんでしょうか。
392:デフォルトの名無しさん
08/02/16 17:58:43
rms曰く、we should use Bzr
URLﾘﾝｸ(lists.gnu.org)
393:デフォルトの名無しさん
08/02/17 11:10:01
mercurial で、heads と tips の違いがわかりません。だれかおしえて。
394:デフォルトの名無しさん
08/02/17 11:17:55
>>393
URLﾘﾝｸ(www.selenic.com)
395:デフォルトの名無しさん
08/02/17 12:47:28
>>394
ありがとう。とりあえず、tip は heads のうちのひとつ、ということまではわかった。
でも、なんで head が複数できるのかわからない。head は子を持たない changeset ということだが、普通に作業してたら head はひとつしかないように思うんだが。
396:デフォルトの名無しさん
08/02/17 13:30:19
>>395
複数人が編集したらheadが増える
397:デフォルトの名無しさん
08/02/17 19:03:49
>>396
ひとつのリポジトリを複数人で編集・・・するわけはないか。
>>394のページを見ると、他のリポジトリからhg pull したらheadが増えるみたいなんだが、そういう理解であってますか？
398:デフォルトの名無しさん
08/02/17 19:23:02
つまり
>>396
>複数人が編集したらheadが増える
というのは、他人のリポジトリから hg pull したら head が増えるということを意味してますか、という質問です。
399:デフォルトの名無しさん
08/02/17 20:52:17
>>398
一つの changeset に対して複数の commit をすれば head は増える。
$ hg init .
$ echo "line 1" >> test.txt
$ hg add test.txt
$ hg commit -m "init"
$ echo "line 2" >> test.txt
$ hg commit -m "head 1"
$ hg update 0
$ echo "line 3" >> test.txt
$ hg commit -m "head 2"
$ hg heads
$ hg tip
他人のリポジトリには自分のとは違う変更が commit されているだろうから、
それを pull してくれば head は増える。
400:デフォルトの名無しさん
08/02/20 00:51:46
TortoiseHGをインストールすると、Sambaの共有フォルダ一覧が
表示されるのがかなり遅くなってしまいました。
Wiresharkでキャプチャしてみると、\\Samba\.hgなるものを
何度もチェックしているからのようでした。
アンインストールすると元通りの速度になったのですが、この現象を
回避する方法はないのでしょうか？
401:デフォルトの名無しさん
08/02/20 09:36:27
TortoiseSVNには、アイコンオーバーレイのネットワークドライブなどでの除外指定ができるけど、
HGはできないの？
402:デフォルトの名無しさん
08/02/20 11:03:38
/var/logも.hgで埋まるから困る
403:デフォルトの名無しさん
08/02/23 06:58:06
バージョン管理システム管理下のファイルだけを対象にできる「auto-save-buffers-enhanced.el」
URLﾘﾝｸ(d.hatena.ne.jp)
404:デフォルトの名無しさん
08/02/23 07:30:24
＞HGはできないの？
出来る、ドキュメント嫁。
405:デフォルトの名無しさん
08/02/23 11:26:19
>>403
バージョン管理下以外のファイルには自動保存したくないっていう
状況がよく分からないんだけど、なんでだろうね。
auto-save-buffers に慣れきったから自動保存されないことが
怖くてしょうがない。
406:デフォルトの名無しさん
08/02/23 12:06:16
>>405
間違って更新されたら元に戻せなくなる可能性があるからじゃない？
407:デフォルトの名無しさん
08/02/24 06:40:24
xyzzy使いだけど、おれは自動でバックアップファイルを作るのを使っているな。
ただし、セーブしたらバックアップファイルが消えるっていうやつ。
もし落ちても問題なし
408:デフォルトの名無しさん
08/03/01 13:08:03
GitTorrent Protocol -- GTP/0.1
URLﾘﾝｸ(gittorrent.utsl.gen.nz)
409:デフォルトの名無しさん
08/03/06 21:08:19
URLﾘﾝｸ(gihyo.jp)
git の特集だそうです。
410:デフォルトの名無しさん
08/03/06 23:06:08
なんか最近Gitが盛り上がってるなあ。
411:デフォルトの名無しさん
08/03/07 01:07:26
俺的にはTortoiseGitが無いのが糞だな
ところでTortoiseVSSって無いのかな？
412:デフォルトの名無しさん
08/03/07 02:23:30
最近はBazaarがgitとmercurialのいいとこ取りをしてますよーと、結構ドキュメント書いてるなぁ。
ちなみにgitのメインメンテナって日本人っぽいよね?(ハマノさん?)
俺的にはqgitがもうちょい使いやすくなれば嬉しいんだが、最近あんまアクティブでないよな…。
413:デフォルトの名無しさん
08/03/07 14:14:41
>>411
ないだろうし、これからも作られんだろ。
基本的に有償のソフトウェアには有償のサードパーティ・ソフトウェアしかでない。
414:デフォルトの名無しさん
08/03/07 14:44:55
>>413
> 基本的に有償のソフトウェアには有償のサードパーティ・ソフトウェアしかでない。
その理論（理解）はおかしい。
415:デフォルトの名無しさん
08/03/07 16:21:09
Tortoiseほにゃららはどうでもいいんだが
Cygwin環境でのgitの挙動があれで自分はmercurial
いちいち .git/hooks を弄らなきゃいけないのは苦痛だ
416:デフォルトの名無しさん
08/03/09 21:02:44
>>412
よければその記事どこにあるか教えてくれ。
417:デフォルトの名無しさん
08/03/09 21:07:12
しかしまあ、CVS->Subversionと来て次のスタンダードはどこになるんだろうな？
GitとMercurialに決定的な差異がない以上、ハッキリと明暗分かれることは当分ないんだろうが・・・。
ブルーレイvsHD DVDみたくどっちかが撤退という訳にも行かんし、
環境ごとにGit使ったりMercurial使ったりするのは勘弁してほしいなあ。
418:デフォルトの名無しさん
08/03/09 21:55:29
svn, git, hg のリポジトリを透過的に扱える、クライアント専用の第三のツールが出て一人勝ちに一票
419:デフォルトの名無しさん
08/03/09 22:13:33
>>418
スゲー欲しい。
ここは言い出しっぺの法則で作ってくだされ！
しかもWindows用にヨロｗ
420:デフォルトの名無しさん
08/03/09 22:26:23
たぶんEmacsにならすでに有りそうな気がする。
421:デフォルトの名無しさん
08/03/09 23:32:06
Emacs だと vc とか DVC とかかねぇ。
422:番組の途中ですが名無しです
08/03/10 15:30:23
>>418
サーバとクライアントって、分散SCMを否定してるなｗ
あるいは、IETFあたりで、分散SCMプロトコルのRFCとか決めて、なんでも繋がるようにしたら面白いかも。
ところで、Darcs2はどうなってる？
423:デフォルトの名無しさん
08/03/10 15:31:49
別に否定ではないだろ
親と子の関係はあるんだから
424:デフォルトの名無しさん
08/03/10 19:48:50
>>422
＞IETFあたりで、分散SCMプロトコルのRFCとか決めて
「インターネット」が関係ないがな！ｗ
425:デフォルトの名無しさん
08/03/12 12:16:18
TortoiseSVNだけを各々のPCにインストールして
TortoiseSVNでリポジトリを共有サーバに作る
そのリポジトリと各々のTortoiseSVNで使うって使い方は問題ない？
本来ならサーバにSubversionをインストールしてうんぬんかんぬんって
やらないとダメだと思うんだけど
ちょっと今の環境だと難しいんで上記の方法でやろうかなぁと
426:デフォルトの名無しさん
08/03/12 12:23:16
Windowsの場合、Subversionは管理ツールだと思え
必須って訳じゃない
その代わり、file:///でやることになるし、ユーザ名が
Windowsのユーザ名になるし、いくつか制限が出てくる
単純なソース管理しかしないならそれでも十分
427:デフォルトの名無しさん
08/03/12 12:28:58
>>426
おお素早い回答ありがとうございます。
単純なソース管理しかしないのでTortoiseSVNだけでOKってことですね
一先ず運用してみます。
428:デフォルトの名無しさん
08/03/13 00:46:12
Windowsで、一人ないしは少人数で扱うバージョン管理システムなら
Subversion(TortoiseSVN)が現状、最良且つ唯一の選択肢だろうな。
それ以上のことをやろうとするから、いろいろ悩むわけだ。
429:デフォルトの名無しさん
08/03/13 01:40:30
1人ならHgの方が手軽じゃない？
っつっても、Ｔｏｒｔｏｉｓｅがまだまだだからなぁ。
430:デフォルトの名無しさん
08/03/13 06:44:59
すまんですが、普通のバージョン管理システムで一万個ぐらいのファイルを最初にリポジトリに登録しようと思ったら、どのぐらい時間かかるもの？
VSSだと3時間かかっても終わらん･･･orz
431:デフォルトの名無しさん
08/03/14 11:43:24
PCのスペック、各ファイルの容量によって全然変わるし一慨にこうだとは言えない気がするが
うちが管理してたやつは30分もかからずに終わった
（Subversion管理）
432:デフォルトの名無しさん
08/03/15 03:08:26
上の方でgit-svnが話題になってたが、同じように既存のCVSリポジトリとやりとりできるやつある？
git-cvsexportcommit ってのでいいんだろうか。しかし日本語の情報とかさっぱりないな。
別にgitじゃなくてもいいんだが。
433:デフォルトの名無しさん
08/03/15 13:34:58
mercurial
URLﾘﾝｸ(www.selenic.com)
そろそろ来るのかな？
434:デフォルトの名無しさん
08/03/15 15:42:56
URLﾘﾝｸ(www.atmarkit.co.jp)
これは駄目だろ
435:デフォルトの名無しさん
08/03/15 19:58:48
TortoiseHg 0.3 を入れてみた。
日本語ファイルの追加や削除もマウス操作でうまくいったよ！
実験に使ったファイル名： ソース表示.txt
やったことは、インストールした場所にある Mercrial.ini の
[extensions]
hgext.win32mbcs = !
の感嘆符（!）を削除しただけ。
ファイル選択やコミットの画面で日本語ファイル名が化けるけど、そのまま動くよ。
コメントは入力・表示ともに日本語でOKだった。
436:435
08/03/15 20:33:36
↑すまん、環境は WinXP SP2。書き忘れた。
437:デフォルトの名無しさん
08/03/16 01:55:28
そりゃ動くだろうけど、ほとんどの機能が結局ダイアログが出てきてコマンド入力だったような。
438:デフォルトの名無しさん
08/03/16 03:50:20
>>434
1.5.4rc1で起こってたんだな。知らなかった。
教えてくれてありがとう。アンチも役に立つんだな。
439:435
08/03/17 10:50:04
>>437
・現在の Mercuriel の hg はファイル名とコメントに日本語が入っているとエラー停止する
・TortoiseHG 3.0 に付属の hg なら日本語ファイル名が扱える（mbcs エクステンションが入っている）
という事前情報があり、hg（コマンドライン）目当てで TortoiseHG を入れたところ、予期せず GUI でも日本語ファイル名の追加・コミットができたので、報告の意味で書き込んでみました。
440:デフォルトの名無しさん
08/03/18 14:44:55
ああ、そういえばSDのgit特集、今日発売か
441:デフォルトの名無しさん
08/03/18 17:38:51
SD読んだよ。クオリティ高かった。
かなり硬派な内容で、バリバリ使ってる人でも面白く読めると思う。
442:デフォルトの名無しさん
08/03/24 13:24:47
ネットの情報で十分でした
443:デフォルトの名無しさん
08/03/24 15:27:58
gitもhgもやりたいやりたいとは思うんだが、TortoiseSVNになれた身では移行しづらい。
やっぱフロントエンドが充実するにはもうすこし時間が必要かなあ。
444:デフォルトの名無しさん
08/03/24 15:40:01
必要ならお前が作れよ
445:デフォルトの名無しさん
08/03/24 17:40:42
gitはファイル名とログの日本語対応に不安がありすぎるんだが。
446:デフォルトの名無しさん
08/03/24 21:20:53
>>445
問題ない。
447:デフォルトの名無しさん
08/03/24 22:13:59
SD読んだよ
448:デフォルトの名無しさん
08/03/24 23:25:49
>>445
俺もふつうに日本語使えてるけど
449:デフォルトの名無しさん
08/03/24 23:44:07
SVNすら着いて来てくれないのにgitとか無理だお・・・
450:デフォルトの名無しさん
08/03/24 23:54:56
>>449
いつかgit使える日が来るさ。
451:デフォルトの名無しさん
08/03/25 15:32:06
mercurial-1.0.tar.gz 24-Mar-2008
452:デフォルトの名無しさん
08/03/25 19:54:31
コミットログを英語で書く人のためによさげな記事みつけてきた
Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
URLﾘﾝｸ(d.hatena.ne.jp)
453:デフォルトの名無しさん
08/03/25 21:52:39
>>451
釣りかと思ったらマジだったのでage
454:デフォルトの名無しさん
08/03/25 22:47:52
今日のパッケージアップデートで知ったけど、x264がgitに移った模様。
455:デフォルトの名無しさん
08/03/26 03:06:05
>>454
ん～、なんだか大規模プロジェクトはMercurialよりGitに移る傾向があるみたいだね。
Mercurial使ってる有名なオープンソースとかあったっけ？
456:デフォルトの名無しさん
08/03/26 04:42:34
mozillaとかsun回りとかいろいろ。
457:デフォルトの名無しさん
08/03/26 08:50:37
TortoiseGit 作って （はーと）
458:デフォルトの名無しさん
08/03/26 13:44:38
TortoiseSVNの右クリックで表示されるメニューなんだけど
---
SVN更新
SVNコミット
TortoiseSVN
---
の3つなんだけど、ココに「変更のチェック」を加えて
---
変更のチェック
SVN更新
SVNコミット
TortoiseSVN
---
にしたいんだけど方法ないですかね？
459:デフォルトの名無しさん
08/03/26 14:00:53
TortoiseSVN > Settings で Look and Feel
460:デフォルトの名無しさん
08/03/26 14:10:20
>>459
それだとTortoiseSVNの下のメニューを変えるだけです＞＜；
トップのメニューを変える方法は無いのかな
461:デフォルトの名無しさん
08/03/26 14:13:42
>>460
俺は459じゃないけど、説明良く見てないだろ
チェックを外せばトップメニューに表示されるんだよ
462:デフォルトの名無しさん
08/03/26 14:26:59
>>457
みんなTortoiseに依存しまくってるんだな．．．．
SDによるとWindowsの場合CygwinでGit使えるみたいだけど、
GUIじゃないと嫌なの？
463:デフォルトの名無しさん
08/03/26 14:30:39
>>460-461
本当だ！ごめんなさい、ありがとうございます。
464:デフォルトの名無しさん
08/03/26 14:32:52
自分しか使わないならそれで良いんじゃないの
普通の人が触りやすい形態を考えれば分かる事だろ
465:デフォルトの名無しさん
08/03/26 15:17:31
>>462
ここに書き込みするような人たちほど リテラシーがないんですよ。
使い勝手によいＧＵＩがあれば、バージョン管理システムの導入も
してもらいやすい。
「コマンドベースでやってね」 なんて言ったら、誰にも使ってもらえないだろう。
直感的に変更点判るし、ツールとして良くできているしね
466:デフォルトの名無しさん
08/03/26 15:30:20
差分見るのはGUIじゃなきゃやだ
467:デフォルトの名無しさん
08/03/26 15:34:35
ファイラーはどう考えてもGUIのほうが便利だしなあ
468:デフォルトの名無しさん
08/03/26 15:56:43
gitの場合、中身がシェルスクリプトだからTortoiseはちょっと難しそうだな、
と素人目に思った。
469:デフォルトの名無しさん
08/03/26 15:58:22
>>467
そうか?
470:デフォルトの名無しさん
08/03/26 16:03:33
>>464-465
Gitは開発者全員Gitにしないとダメなんてことないよ。
中央をsvnリポジトリにして自分だけGitでも問題なし。俺はそうしてる。
HGは使ったことないから分からないけど、Gitから分かれたモノだから
同じような感じではないかな？
>>466
CUIでもキレイに差分見れるけどね、、、
471:デフォルトの名無しさん
08/03/26 16:56:54
>>455
逆
472:デフォルトの名無しさん
08/03/26 17:04:01
>>457
Git Cheetah
473:デフォルトの名無しさん
08/03/26 17:21:18
Mercurial で リポジトリの一部を消すとか、リポジトリを分割するとかってできますか？
やりたいことは Subversion でいえば
svnadmin dump | svndumpfilter | svnadmin load
のようなことなのですが…。
474:デフォルトの名無しさん
08/03/26 17:39:14
Bazaarバージョンが上がってすごい事になってるみたい
URLﾘﾝｸ(bazaar-vcs.org)
Bazaar vs Git URLﾘﾝｸ(bazaar-vcs.org)
Bazaar vs Mercurial URLﾘﾝｸ(bazaar-vcs.org)
Benchmarks URLﾘﾝｸ(bazaar-vcs.org)
昔と比べて恐ろしいくらい速くなってる。
475:デフォルトの名無しさん
08/03/26 18:56:03
へー、bzr速くなったのか。まー、あまり速さは求めてない。
設定ファイルと自作スクリプトの管理にしか使ってないけど。
不思議なのは、bzrってbazaarの後継？らしいんだけど、
使い勝手が全然違ってどこが後継なのか良く分からない。
hgよりも便利機能が多い（UTF-8ファイル名でおｋ）けど
なぜか、hgの方が情報が多い。
あたりが疑問点かな。
476:デフォルトの名無しさん
08/03/26 19:00:00
>>475
昔Mercurialにうんこと言われるぐらい遅かったからだろ。
477:デフォルトの名無しさん
08/03/26 19:13:55
BazaarNGが本家乗っ取ったんだっけ？
478:デフォルトの名無しさん
08/03/26 19:45:03
>>477
急に速くなってたから驚いたけど
そういう理由があったのか
479:デフォルトの名無しさん
08/03/26 19:53:44
適当なことを言う前に URLﾘﾝｸ(bazaar-vcs.org) でも読んどけ。
480:デフォルトの名無しさん
08/03/26 19:56:27
Bazaar。。。。名前がいまいちなのがなぁ・・・・
481:デフォルトの名無しさん
08/03/26 20:30:04
Bizarreよりは普通だと思う
482:デフォルトの名無しさん
08/03/27 01:17:45
>>480
ゴザールを作るんだ
483:デフォルトの名無しさん
08/03/31 01:30:18
”ファイルのディレクトリ構造”ごと登録して、
その後、バージョン管理システム外で変更された、
”ファイルのディレクトリ構造(多少のファイルの増減あり)”を
チェックアウトなしで、そのままチェックインできるツールって、ありますか？
開発拠点が国内と、海外に数ヶ所と、
バージョン管理システムの導入を徹底できないので、困っております。
484:デフォルトの名無しさん
08/03/31 01:58:11
Subversion
485:デフォルトの名無しさん
08/03/31 08:13:17
svn_load_dir とかいうスクリプトがあったな。
他のツールにそういうのは無いのかな？
486:デフォルトの名無しさん
08/03/31 23:15:55
>>483
質問の内容に合っているかわかりませんが、Mercurialでリポジトリのあるところにファイルを展開して
hg addremove
hg commit
をすると、増えたファイルをリポジトリに追加、なくなったファイルをリポジトリから削除してくれます。
487:デフォルトの名無しさん
08/04/04 18:23:30
話題が途切れたので、ちょいと Mercurial を使った感想を…。
CVS → Subversion と集中リポジトリのリビジョン管理ツールを使ってきましたが、
Mercurial を使ってからというもの、
「サッとリポジトリが作れる」というのがとても気持ちよく、気に入っています。
ローカルの作業ディレクトリは、すぐに hg でリポジトリ化し
修正やコミットをかけた後、完成したらリポジトリ部だけ削除してます。
「作業ディレクトリにリポジトリがくっついている」という発想は
とても便利で面白いと思います。
488:デフォルトの名無しさん
08/04/04 18:29:55
続きです。
いままでしばらく Subversion＋svk を使っていましたが、
いまでは Subversion＋Mercurial という構成で使っています。
Subversion＋svk のときは、svk で自分の手元に持ってきてから
ローカルで開発し、結果を svk smerge で一括送信していましたが、
今は Subversion でチェックアウトした内容をそのまま Mercurial に突っ込み、
Mercurial でさんざん修正・コミットした後、
最後に Subversion でコミットしています。
開発中に Subversion のリポジトリ上に修正が入っていた場合には、
Mercurial のブランチとして取り込んで、Mercurial 上でマージしています。
この方法だと svk みたいに自動化されていませんが、
構成がすっきりして全体の見通しがよく、作業がひとつひとつ理解できるので
安心感があります。
489:デフォルトの名無しさん
08/04/04 18:34:30
Subversion + Mercurial って
それいいな、俺もやってみるか
490:デフォルトの名無しさん
08/04/04 18:43:27
>>488
昔、CVS+Teamwareで俺がやってたのと同じ感じかな・・・と思ったけど逆だ・・・
俺のときは、Teamware側が共用できるやつでCVSがローカル環境・・・・
なんでそんな事したのか思い出した・・・eclipse対応してるかどうかだ・・・
MercurialならMercurialだけでIDE含めて完結できるのが一番楽なんだろうけどねぇ・・・
491:デフォルトの名無しさん
08/04/04 21:18:50
>>488
熱いレポート乙！
参考にさせてもらいます。
492:デフォルトの名無しさん
08/04/05 02:45:13
GitHubって招待制なの？
だれか invite してくれ
493:デフォルトの名無しさん
08/04/05 03:15:59
>>492
そんなのあるんだね、知らなかった
とりあえずsignupしてみたけど、いつになるやら
SourceForgeもGitサポートすればいいのになぁ
494:デフォルトの名無しさん
08/04/05 04:03:16
>>488
ちなみに hgsvn を使用しているのですか？
495:デフォルトの名無しさん
08/04/05 05:58:53
どこをどう読んだらそうなるんだ
496:デフォルトの名無しさん
08/04/05 13:56:25
>>492
なんか知らんがinviteされた（たぶん中の人？）
メアド晒してくれればinviteするよ
497:デフォルトの名無しさん
08/04/05 13:59:02
>>494
hgsvn は使っていません。
いまは Subversion でエクスポート
→ .svn 以外をそのまま新規に Mercurial 管理下に入れる（手作業）
という感じです。
Subversion に戻すときは、Subversion のリポジトリをチェックして
更新されていなかったら、そのまま Subversion でコミット。
更新されていたら、Mercurial のブランチとして取り込んでマージしてから
Subversion でコミット、です。
すべて手作業です。
498:デフォルトの名無しさん
08/04/05 13:59:32
Git と Mercurial の比較ってだれかやってません？
499:デフォルトの名無しさん
08/04/05 16:05:53
>>498
つ URLﾘﾝｸ(www.opensolaris.org)
OpenSolaris が Mercurialを選ぶときに行ったレビュー。
粒度が揃っているとは言えないがまあ参考に。（下の方にあります）
500:デフォルトの名無しさん
08/04/05 21:36:34
URLﾘﾝｸ(weblog.rubyonrails.com)
まー政治的にpythonは選べないだろうなw
501:デフォルトの名無しさん
08/04/05 21:38:53
>>500
でもTrac使ってるぜ。
502:デフォルトの名無しさん
08/04/05 21:55:56
railsではbtsは難しいということですか、分かりません＞＜
503:デフォルトの名無しさん
08/04/05 22:06:23
いまならredmineとかretrospectivaとかに移行してもよさそうなものなのにね>rails
504:デフォルトの名無しさん
08/04/05 22:08:45
データの引っ越しの手間が馬鹿にならないとか?
505:デフォルトの名無しさん
08/04/05 23:05:56
>>500
Ruby界隈はMatzが使っているという理由でGit一択です
506:デフォルトの名無しさん
08/04/06 00:03:18
matzって基本的にオールドタイプだから新しめの道具は使ったことなさそうなイメージ。
cvsからsvnに切り替えるのもかなりもたついてたような。
507:デフォルトの名無しさん
08/04/06 01:04:24
>>506
svnに切り替えるときに、ローカルでの管理用としてgitを導入した。
URLﾘﾝｸ(www.rubyist.net)
508:デフォルトの名無しさん
08/04/06 02:29:54
StGITは、git導入したというのだろうか。
StGITローカルパッチ管理に使ってるが便利だ。
でもドキュメント少ないな
>>507 の記事とかチュートリアルの翻訳くらいしか日本語の記事が無いので
公式見てもチュートリアルの元記事しかなかった…。
509:デフォルトの名無しさん
08/04/06 03:00:10
StGITは「git使ってることを意識しなくて済むツール」なのではなかろうか。
510:デフォルトの名無しさん
08/04/06 12:06:25
当時はgitって本当にバックエンド用のplumbingコマンドしかなかったからね。
今でこそフロントエンド用のporcelainコマンドも充実してるけど。
511:デフォルトの名無しさん
08/04/06 13:15:50
>>501-504
BTS も rails 製の Lighthouse に移行するよ。
って >>500 に書いてあるじゃん。読まずに脊髄反射してんだなｗ
512:デフォルトの名無しさん
08/04/07 15:36:59
Rubyが好きじゃない俺はどうすればいいですか？
513:デフォルトの名無しさん
08/04/07 16:54:05
>>512
自己暗示
514:デフォルトの名無しさん
08/04/07 17:47:12
>>512
ブール代数的に言うと、好きじゃないということは、嫌いじゃないかもしれない。道は残ってるね。
515:デフォルトの名無しさん
08/04/07 21:22:00
>>512
安心しろ、Joel Spolsky も Ruby が嫌いみたいだから。
URLﾘﾝｸ(www.joelonsoftware.com)
っと、これだけだとスレと関係なくなってしまうので。
… Python に走って Mercurial 使えば？
516:デフォルトの名無しさん
08/04/07 21:40:52
>>512
言語の好き嫌いがある内は只の厨房だと自覚するべきだと思うよ。
自分の得意不得意のせいであんまり好きになれない言語があるのはしょうがないとおもうし、結構あるしorz
517:デフォルトの名無しさん
08/04/07 22:03:50
>>497
詳細な説明＆レポートとても助かります。
TortoiseSVN で管理している svnワーキングコピーに、
なんの疑問もいだかずに TortoiseHG で真剣に管理しようとしていた俺は・・・
518:デフォルトの名無しさん
08/04/07 23:27:46
韓国語が嫌いだ
519:デフォルトの名無しさん
08/04/08 00:34:50
>>514
ブール代数的なら「好きじゃない」イコール「嫌い」だろ。
3値で「好きじゃない」なら「嫌い」か「興味ない」。
520:デフォルトの名無しさん
08/04/08 02:47:04
>>512の突っ込みどころは、Ruby好きじゃないのにrails使うのかよってところじゃないのか
521:デフォルトの名無しさん
08/04/08 09:45:07
うむ。直観主義論理だな
522:デフォルトの名無しさん
08/04/08 13:48:01
で、Railsとバージョン管理システムの関係は？(スレ原理主義的に)
523:デフォルトの名無しさん
08/04/09 10:54:11
TortoiseHg 0.4 age！
URLﾘﾝｸ(sourceforge.net)
524:523
08/04/09 10:55:13
0.4 RC版だった
スマソ
525:デフォルトの名無しさん
08/04/09 10:57:36
>>523
おぉ、やっと、新しい版が。
sambaの共有フォルダへのアクセスが遅くなる件、確認してみよう。
526:デフォルトの名無しさん
08/04/09 15:08:04
Mercurial 神だな。
なんだ このお手軽さは！ すんばらし～
527:デフォルトの名無しさん
08/04/09 15:13:51
マーキュリアルってuにアクセントあるのか
528:デフォルトの名無しさん
08/04/09 15:40:54
>>527
本当だ、u にアクセントがある。
URLﾘﾝｸ(dictionary.goo.ne.jp)
「マーキュロ」に似た感じで発音すればいいのかな。
529:デフォルトの名無しさん
08/04/09 16:03:13
メルクリアルだとばっかり
530:デフォルトの名無しさん
08/04/09 20:48:51
Mercurial って、バイナリファイルの保管は効率的でないの？
まぁ svn でも過剰な期待をしているわけではないんですが。
531:デフォルトの名無しさん
08/04/09 20:57:47
マテリアルと同じ感じでマキュリアルかな。
532:デフォルトの名無しさん
08/04/10 01:12:26
>>530
自分の経験では、
MS Access の MDB ファイル(300KB)を修正しながら
6回チェックインしてリポジトリのサイズが 200KB くらいです。
元ファイルより小さいってことは、初期バージョンを
圧縮して格納しているのでしょうか？
533:デフォルトの名無しさん
08/04/10 01:39:42
git 使ってみたけどリビジョンがないのが面倒に思えた。
実際に使ってる人は不便に感じない？
534:デフォルトの名無しさん
08/04/10 09:39:52
>>533
リビジョンの使い道ってどんな時があるでしょうか？
headやhead^,head~2しか使ったこと無いので…
535:デフォルトの名無しさん
08/04/10 11:59:15
533じゃないけど、バージョン番号に入れたとき長いと人が覚えきれないとかw
536:デフォルトの名無しさん
08/04/10 12:45:57
Mercurial を単独で使い始めてみました。
JapaneseTutorialや、有益なサイトの説明を読んでもみました。
お手軽さはぴかいちですね。
ちょこっと修正履歴を残しておきたい場合など、本当にあっという間に環境が整いますね。
まだまだ使い込みが足りませんが、分散システム故の運用の難しさを感じています。
・本流はどれだろう？
・現時点の最新はどこ？
・自分は今どの位置にいるの？
etc・・・
やっぱり中央リポジトリみたいなものは用意されるんでしょうか？
こまめにマージとかもされてるんでしょうか？
ん～
537:デフォルトの名無しさん
08/04/10 13:06:52
>>533
> git 使ってみたけどリビジョンがないのが面倒に思えた。
> 実際に使ってる人は不便に感じない？
うはｗ 俺といっしょｗ
俺もGit使い始めの頃に同じ質問をしたら「リビジョンがあったら何が嬉しいの？」って言われたｗ
たぶん使ってるうちに必要ないなと思うようになると思うよ。
実際気軽にフォークできるから、あんま意味がなくなっちゃうんだよね、番号は。
プロジェクトの公開リポジトリなら自動で番号振っても良いような気もするけど、
まあタグで事足りるんだよなぁ。
どちらかというと「番号が年上かどうか」で知りたかったことは「いま見ているブランチに
どのコミットが含まれている（いない）か」のほうが重要だから、git show-branchを
俺は多用しています。
538:デフォルトの名無しさん
08/04/10 13:38:52
Subversion 使ってて、まっすぐ増えてくリビジョン番号が無いと困りそうなんだが、
要らなくなるもんなのか？
たとえばこんなの。
・バグレポートがいつの時点のものなのか？
・バグ修正がリポジトリ内のどの時点で行われたのか？
・テストを実行しているのはどの時点の実行ファイルなのか？
全部リビジョン番号で示してれば、以前に報告したバグが今回のテストで
修正確認できるかどうか、すぐにわかるんだが。
539:デフォルトの名無しさん
08/04/10 13:47:33
svn使ってるけど、その手の管理でrev番号を必要とした記憶が無い
540:デフォルトの名無しさん
08/04/10 14:06:54
rev XXXXで・・・って表現の仕方はよくするかな
541:デフォルトの名無しさん
08/04/10 14:31:09
>>538
リリースするときバージョンつけないの？
542:デフォルトの名無しさん
08/04/10 14:33:28
短い番号ってのは自分が把握するのにも人に伝えるのにもわかりやすくて便利だと思う
200804101426みたいなタイムスタンプでもいいけど
何かの暗号みたいなハッシュはちょっととっつきにくい感じ･･･
543:デフォルトの名無しさん
08/04/10 14:37:44
>>541
つけないね。開発と同じフロアにテストする人が居て、少なくとも日に一回ってペースで
実行ファイル更新するから、毎回つけるとなるとちょっと面倒。
それに、リリースにバージョンつけても、そのバージョンで特定のバグが直ってるかどうか
すぐに（リビジョン番号の大小ぐらい簡単に）判別はできないんじゃない？
544:デフォルトの名無しさん
08/04/10 14:41:39
それって、その日解決されたレポート番号一覧を出せばいいんじゃないの？
というか、テストチームに対して、dailyで実行ファイルを更新するという環境が想像できないのだが・・・
545:デフォルトの名無しさん
08/04/10 14:44:01
普通は、「この問題は、（マイルストーン名｜タグ名）で解決される」って感じで、
BTSに登録するんじゃないの？
546:デフォルトの名無しさん
08/04/10 14:57:26
bugtraq:*使ってないだろ？
547:デフォルトの名無しさん
08/04/10 17:03:01
つーか、BTS使ってないんじゃね？
548:デフォルトの名無しさん
08/04/10 17:03:50
>>543
リビジョン番号を見てバグが直ってるかどうか判別できるって事のほうがすごいと思うんだが。
毎日テストチームにバイナリリリースするってことはけっこう変更がたて込んでるってことだよね。
俺はSubversionも使ってるけど、リビジョン番号聞いて「あーそれ古い」なんて言えない。
コミットされる度にインクリメントされる番号なんて憶えてられないし印象にも残らない。。。
リリースしてるならバージョンが付くはずだし、その時には変更履歴が付くからそれで分かる、
リリースしてないなら、リビジョン番号があろうと無かろうとログを見て判断するしかないと思う。
549:デフォルトの名無しさん
08/04/10 17:15:48
というか、テスターが勝手にcoなりexportなりして、修正されたバグがないかどうか
調べて、あればそれをテストする、という混沌とした現場なんじゃ。
550:デフォルトの名無しさん
08/04/10 17:17:20
テストチーム（個人？）って、そのときfixされたバグだけを確認してるわけじゃなくて、
リグレッションテストもするはずだから、頻繁にリリースされても困ると思うけど
551:デフォルトの名無しさん
08/04/10 17:28:56
いわゆる「リリース」じゃないんだよ、きっと
552:いろんな現場を体験したことのあるマ
08/04/10 17:45:27
リグレッションテストなんて ここぞ！ という時以外あまりやらないな・・・
細かなバグ対処リリースでは無視無視
運用方法に依るんだけどね・・・
553:デフォルトの名無しさん
08/04/10 17:48:39
プログラマならともかく、テスターがリグレッションテストやらないのは問題だろ・・・
554:デフォルトの名無しさん
08/04/10 19:26:27
リビジョン番号の代わりにタグをうつ事をするようにしたら
修正の順番が分かるようになると思う。
今まで番号でやってきたのが変だった、ということか？
555:デフォルトの名無しさん
08/04/10 20:43:27
>>536
> ・本流はどれだろう？
Mercurial では、すべてのリポジトリが対等で本流です。
…が、どれかを本流にし、全ユーザーがそこから clone すれば
中央リポジトリ的な使い方ができます。
> ・現時点の最新はどこ？
リビジョンに「tip」と表示されるのが、そのリポジトリでの最新です。
hg tip で表示できます。
ブランチが複数あった場合には、それぞれの最新が head と呼ばれ、
hg heads で表示できます。
わからなくなったら hg glog をすると、わかりやすく（？）表示されます。
> ・自分は今どの位置にいるの？
上の hg glog のほか、hg stat -v でリビジョンが表示されます。
hg parents で、現在のワーキングディレクトリの元リビジョンが表示されます。
556:デフォルトの名無しさん
08/04/10 20:48:37
リビジョン番号は前後関係がわかるのでよい。
ハッシュは長すぎて覚えられないし。
monotoneのマニュアルには、補完できるように
シェル弄れみたいなことが書いてあったが、
そんなのめんどくせえよ、と思った。
darcsは半分ズレがあるので却下。
bzrが一番よい。-1とか分かりやすいしシンプル。
557:533
08/04/11 00:56:32
>>537
リリースサイクルが長い開発で使用するとなると公開（メイン）リポジトリでは
定期的にタグを打たないと駄目そうかな
まだ個人使用だし考えていてもしゃあないのでまず使ってみる
>>556
＞ハッシュは長すぎて覚えられないし。
先頭 4 文字から絞ってくれるよ。 4 文字だと重複する可能性は少し高いだろうけど
558:デフォルトの名無しさん
08/04/11 00:57:08
URLﾘﾝｸ(www.moongift.jp)
Git の GUI ツールが紹介されてた
559:538
08/04/11 01:22:41
うわ。なんかダメな子みたいになってる。
何か重要な概念が欠けてるのかもしれないけど、いちおう返答してみる。
>>544
一覧を「出せばいい」じゃなくて、「出さないといけない」ってことにならない？
めんどくさくね？
リビジョン番号で示してればそれは要らないんだ。少なくともそう思ってる。
修正するときは「rXXXX で修正」で、テスト用の実行ファイルを更新するときに
「rXXXX でビルドしたもの」って伝えれば済む。未確認のバグのうち、テスト中の
リビジョン番号より小さい番号で修正を入れた問題の動作を確認してもらう。
>>548
たとえば r100 のテストで見つかった２つの問題に対してそれぞれ r105 と r108 で
修正を入れたとして、次のテストが r107 で行われた場合は前者だけ動作確認して
もらえるってことがわかる。
560:デフォルトの名無しさん
08/04/11 01:31:23
いやだから、テスターに「bugid 78,80を修正したから」って伝えれば済むんじゃねってことなんだが。
テスターがリポジトリの更新履歴でも見て、何が修正されたかいちいち調べるのか？
561:538
08/04/11 01:35:27
>>560
「rXXXX で修正」って BTS に書き込む（そのときにメールも飛ぶ）から、
いちいち別でまとめてバグ ID 伝えたり、リポジトリ見て調べたりしなくていい。
562:デフォルトの名無しさん
08/04/11 01:35:36
>>559
BTS使ってる？
使ってるなら、何使ってる？
プログラマは何人くらいいるの？
テスターは何人くらいいるの？
563:デフォルトの名無しさん
08/04/11 01:35:38
分散vcsだと結構ブランチが気軽に作れちゃう分リビジョンだと混乱しそう。
いいとこ取りのbzrはその辺どうやって解決してるの?
ユーザー間のチェンジセットとかも考慮できるようだが今のところ興味よりもﾏﾝﾄﾞｸｾが勝る。
中央リポジトリばかりで開発するようなスタイルだとそこにリビジョンはあってよいと思う。
564:デフォルトの名無しさん
08/04/11 01:37:19
>>561
だったら、BTSのステータスが「修正済み（未確認）」のものをテストすればいいわけで、
リビジョン番号はおろか、タグも必要ないよね？
565:デフォルトの名無しさん
08/04/11 01:41:15
>>559
そこまで理解してくれるテスターがいる事に嫉妬。
こっちはマにリビジョンxxxで～って言って、
「リビジョンって分からないんですけど？」って後で質問が来る世界だ・・・orz
566:デフォルトの名無しさん
08/04/11 01:43:52
まさかとは思うが、ひょっとして、ビルド済みバイナリをテストチームに渡したりしてないよな？
567:デフォルトの名無しさん
08/04/11 01:49:16
つーか、根本的に破たんしてる気がする。
ひょっとすると、プログラマ一人、テスター一人で、デバッグレベルのテストをやってもらってるのだろうか。
それなら頻繁なテスト依頼が行われるというのも理解できる。
568:538
08/04/11 01:57:20
>>564
>559 の最後の例では、 r108 で修正したバグのステータスは「修正済み」になるけど、
r107 をテストしてるときにそいつの動作確認はまだできないと区別できる。
569:デフォルトの名無しさん
08/04/11 01:57:57
よそで自分の意に沿わない運用がなされたとしても、それがなんだと言うんだろう？
そこではリビジョンさえあればうまくいってると言ってるんだから、外野がごちゃごちゃ
言う必要無いよ。
何がしたいの？やりこめたいの？
570:538
08/04/11 02:02:36
悪いけどテスト環境について議論するつもりはないから、リビジョン番号の有用性に
関すること意外はスルーさせてもらうよ。
「リビジョン番号の無いバージョン管理システムでも、こういうテスト体制なら問題ない」
と紹介してくれるんなら歓迎。
571:デフォルトの名無しさん
08/04/11 02:04:07
何で上から目線なんだ
572:デフォルトの名無しさん
08/04/11 02:05:05
>>570
だーかーらー、解決されたbugid一覧をテスターに渡せばいいじゃんか。
やりたくないの？
573:538
08/04/11 02:07:48
>>572 もちろん。めんどくさいじゃないか。リビジョン番号さえあれば済むんだから。
574:デフォルトの名無しさん
08/04/11 02:08:13
じゃぁ、svnに戻せよ。
アホか
575:デフォルトの名無しさん
08/04/11 02:09:08
BTSに、修正リビジョンを書くことが、なんで破綻してるとかって話になるんだ？
いつ何を修正したか記録するのは当然だと思うんだが…。
576:デフォルトの名無しさん
08/04/11 02:12:11
>>575
いや、破綻してると思ったのは、開発プロセス全体がってことで、BTSに修正した
リビジョンを書くのは問題ない。
プロセスに関しては議論したくないみたいだから、俺は消える。
577:538
08/04/11 02:13:21
>>572
もしかして、リビジョン番号の無いバージョン管理システムでは
リポジトリ内のある時点からある時点までの間に「解決されたbugid一覧」を
作るための機能がついてるの？
そうじゃなけりゃ >572 の言い方は、リビジョン番号がなくなると（538的な意味で）
不便になる点があるってのを言ってくれてることになる。
578:デフォルトの名無しさん
08/04/11 02:14:37
575書いたあとに570とか読んでちょっと馬鹿馬鹿しくなった（´・ω・｀）
>>570
リビジョンのないVCSなら素直にタグ打てば済む話だと思う。
分散VCSの性質上、連続したリビジョンが付けられないのは当然だろう。
579:デフォルトの名無しさん
08/04/11 02:18:01
>>577
だーかーらー、タグ使うか、おまえが一覧作れって。
タグ打つのもいやで、svnでうまく回ってるなら、svnでいいだろうが。
お前は一体何がしたいんだ。
580:538
08/04/11 02:18:50
仮に今回挙げたテスト体制をリビジョン番号の無いシステムに移すとすれば、
テストするバージョンにタグをちゃんと打つこと、タグ間で修正されたバグの一覧は
別で作成すること、が必要になるってことだね。
ひととおり納得したよ。ありがとう。
570 の書き込みは、正直スマンカッタよ。
581:デフォルトの名無しさん
08/04/11 02:21:11
なぁ、各VCSのcook book的なものを一通り読んでから議論しても遅くなかったぞ。
582:デフォルトの名無しさん
08/04/11 07:58:28
これはひどい
583:デフォルトの名無しさん
08/04/11 08:16:08
ゆとりに構ってスレの無駄使いは止めましょう
584:デフォルトの名無しさん
08/04/11 08:51:11
コミットログちゃんと書けば済む話ジャネーノと思った
585:デフォルトの名無しさん
08/04/11 13:51:41
>>557で＞まだ個人使用だし考えていてもしゃあないのでまず使ってみる
って書いてるしそれでいいんじゃないかと思うけどね。うまく説明できないのは少し残念だが。
俺も最初番号が無いのに戸惑ったけど、使ってるうちにリビジョン番号は必要ないなって
思うようになった。
586:デフォルトの名無しさん
08/04/11 19:02:31
538には必要なんだよ
587:デフォルトの名無しさん
08/04/12 02:02:48
Subversionのリビジョン番号は、その時点のリポジトリ全体の状態を決定するけど、
gitやMercurialのハッシュ値はそのチェンジセットを表してるだけなんだな。
この辺の考え方の違いに気づくまでわかりづらかった。
588:デフォルトの名無しさん
08/04/12 10:59:32
全体で一貫したリビジョン番号である svn は、リリース時のバージョン№付与する時に便利だったんだよね
V1.0.2553 とか ３番目をリビジョン番号使ってたんだけど、
Mercurial を使ったとしても、各リポジトリでリビジョン番号は合ってないから無理だな・・・
ハッシュ値は付けられんし・・・、ちょっと考えないといけないな。
589:デフォルトの名無しさん
08/04/12 13:06:40
>>588
つ[日付]
590:デフォルトの名無しさん
08/04/12 13:18:20
適材適所で Subversion 使えばいいじゃん。
ただしリビジョン番号に依存した運用は、
dump → restore したときに番号が変わると破綻する。
591:デフォルトの名無しさん
08/04/12 15:22:59
ほんとタグ付けのが嫌いなやつが多いな。
それとも、そんなに頻繁にリリースるのが流行ってるのか？
一週間に一回なら、手動でリリースタグ打ってもたいしたことないだろ。
デイリーなら日付入りな。
それ以上頻繁なリリースなら・・・知るか。
592:デフォルトの名無しさん
08/04/12 18:09:10
自分はリリースごとにタグ打ってるけど、
それぞれ好きでいいんじゃないだろうか。
593:デフォルトの名無しさん
08/04/14 14:09:29
いや、多分集中レポジトリ使ってると
タグうつ権限とかも運用上集中管理してて大変だというイメージがあるんじゃなかろうか？
やっぱ、運用がごろっと変わると大変なんだろうけど
その辺りの共通認識がここで話をしてる人の間でないから話が食い違うんだろう。
594:デフォルトの名無しさん
08/04/16 23:00:10
いままで CVS をひたすら使ってて、Subversion に移行しつつあったけど、
Mercurial というのを知って、こちらに本格的に移行することにしました。
あとは、Xcode が Mercurial に対応してくれたらなぁ。
595:デフォルトの名無しさん
08/04/18 02:07:37
>>470
kwsk!!
メインがsvnでも、自分のとこ？（というかクライアントマシン？）だけ
分散型でいけるの？
参考になるページとかないですかね
>>591
それこそ、svnならタグ付ってメッチャ早かったとおもうけどｎ・・・
596:デフォルトの名無しさん
08/04/18 09:57:54
>>595
詳しくないけど答えてみる。
svnリポジトリからcoした作業コピーを、ローカルでgitみたいな別のツールで管理する
ことはできるんじゃないか？
svn co ほげ
git init
git add .
git commit -a
編集
以下、リモートとやりとりするときはsvn、ローカルではgitと、使い分ければいいような。
以上、妄想でした。
597:デフォルトの名無しさん
08/04/18 14:34:10
>>595-596
git-svn を使うって話じゃないの?
598:470
08/04/18 15:59:09
>>595
>>597の言うようにgit-svnでやってますえ。
中央のSubversionリポジトリとローカルのGitリポジトリをマージしながら
使うようなイメージ。
けれど中央をsvnしてるぶん、つねにsvnにくっついていかないといけないのが
ちょい面倒に感じるけど、まあ仕方ないかな。
>>596
そんなやり方でも出来そう！って思ったけど、svn upした時に上書きされて泣いたりとか
しそうだな。。。git-svnならsvn upの代わりにrebaseを使うので、いい感じです。
599:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/04/18 17:20:50
ちなみに、開発者にはメールで報告済みだが、連絡・修正はない
601:デフォルトの名無しさん
08/04/20 14:40:35
Mercurial のマージの概念がよくわかりません
同じリポジトリ内の複数リビジョンの間でしかマージできない？
それとも､過去に hg clone して派生したリポジトリ間でしかマージできない？
同一リポジトリ内の tip リビジョンのファイルとコミット前のファイルのマージはできないのでしょうか？
そのとき、ファイル名は指定できませんか？
ファイル構成がほとんど同じだが過去に hg clone では派生していない 2 つのリポジトリ間ではマージできないのでしょうか？
例えば､ディレクトリコピーなどで複製され、それぞれのディレクトリで 1 回目の hg commit を実行した場合など
602:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/04/23 23:32:12
>>602
サンプル付きでありがとー
今度試してみます
じゃあ、ファイル中の一部分を差分比較対象から除くことはできますか？
例えば、RCS/CVS/Subversion のキーワード置換 ($Revision とか) みたいな
内容が異なる可能性があるけど、差分としては検出して欲しくない部分
606:605
08/04/23 23:33:30
そういえば、Subversion でもキーワード置換以外に
ファイル内の一部分を差分比較対象から除く方法を知らない…
607:デフォルトの名無しさん
08/04/24 13:09:57
>>605
KeywordExtension というのがあります。
「どのファイルの」「どんなキーワードを」「何にする」というのを指定できます。
URLﾘﾝｸ(www.selenic.com)
リポジトリ中のファイルにはキーワードが未展開で（$Id$ とか）格納され、
ワーキングディレクトリに取り出すと展開型（$Id: hoge.txt 2008/04/24 moge$ とか）に
なります。
608:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/04/24 21:34:24
駄目なレポートの典型だな。
まず結論を書け
613:608
08/04/25 02:32:56
>>612
すいません。
結論は >>607 に書いたつもりでした。
614:デフォルトの名無しさん
08/04/29 08:17:14
>>612
だめな講評の典型的な例だな
まず本文を読め
615:デフォルトの名無しさん
08/04/29 08:56:10
そういうのいいから
616:デフォルトの名無しさん
08/05/12 03:25:59
MercurialHgでpushするときの方法を書き留めておくテスト
*** http authorization required
URLﾘﾝｸ(user:password@mydomain.org)
617:デフォルトの名無しさん
08/05/16 00:09:53
Mercurial使いたい……
けどHaskellerだからdarcsなんだ。
618:デフォルトの名無しさん
08/05/16 00:46:11
言語に括っても良い事無いよ
619:デフォルトの名無しさん
08/05/16 01:19:09
tracとhg使ってる理由
620:デフォルトの名無しさん
08/05/16 18:55:09
>>617
HaskellerがdarcsではなくMercurialを使いたい理由を詳しく
621:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/05/18 05:28:07
darcsに興味をもっていろいろ読んでみたけど，darcsでは1つのリポジトリに複数のブランチを作れないんだね。
ブランチを作りたかったら，新たにリポジトリを作りなさいとある。
1リポジトリ，1ブランチということらしい。
URLﾘﾝｸ(wiki.darcs.net)
マージ機能が強力そうだからそれで問題ないのかもしれないが，
管理が面倒そうだな。
623:デフォルトの名無しさん
08/05/22 13:32:51
Mercurialのような分散リポジトリでは、作業ディレクトリ
自体が既にリポジトリなわけで、そうするとそれはどんどん
肥大化してしまうのでしょうか？めちゃくちゃ過去の変更
に関してはどっかのリポジトリにあってくれれば良いので、
自分の手元には最近のリビジョンに関する情報だけ
あってくれれば十分なんですが･･
624:デフォルトの名無しさん
08/05/22 13:34:22
バカはうだうだ言うよりまず使ってみた方が良いよ
バカな質問してるのが良く分かるから
625:デフォルトの名無しさん
08/05/22 21:41:19
>>624の方が馬鹿っぽい
626:デフォルトの名無しさん
08/05/22 23:43:59
バカバカ言い合う事に何の意味があろうか。
627:デフォルトの名無しさん
08/05/23 00:24:38
>>623
HGはよく分からないけど、GitだとたまにGCして圧縮したり、
同じファイルシステムにある同じようなリポジトリ（クローン元とか）は
ハードリンク使ったりとかしてるね。
分散リポジトリという仕組み自体、裕福なリソースが無いと実現出来なかったものだと
俺は思ってるんで、あまり気にしなくて良いような気もするけど。
KDEまるごとクローンしたりするとかなり大変らしいが。
628:デフォルトの名無しさん
08/05/23 09:30:52
mercurial-1.0.1.tar.gz
629:デフォルトの名無しさん
08/05/27 19:56:16
WinXPでtortoiseSVN使い始めたですが、
svn+sshなのでコミットするたびにパスワードを入力するのが面倒です。
かといって、SSHクライアント指定してplinkにユーザ、パスワードをベタ書きしたくないので
Roboformみたいに一度マスターパスワードを入力すれば、リポジトリURLをキーとして
ログインパスワードを入力してくれるツールがあるといいなと
思ったのですが、tortoiseSVNで使えそうなツールないですか？
630:デフォルトの名無しさん
08/05/27 20:14:40
>>629
ssh-agent
631:デフォルトの名無しさん
08/05/27 20:16:46
putty では pageant.exe だった
632:デフォルトの名無しさん
08/05/27 22:44:03
win上でhg使ってたら、リポジトリが壊れてがっかりした。
ファイル名の大文字小文字の問題なんだけど
633:デフォルトの名無しさん
08/05/27 23:03:27
>>632
げげっ そうなんだ・・・
お手軽なので重宝してたんだけど、やっぱりもう少し待った方がいいのか？
634:デフォルトの名無しさん
08/05/27 23:07:19
それは、ファイルシステムの問題だろ。
大文字小文字を区別しないと同一名になるファイルを管理してる奴は、
Windows上で使っちゃ駄目。
635:デフォルトの名無しさん
08/05/27 23:23:18
FSの問題ではあるけど、壊れる操作を行えてしまうのはどーかな
636:デフォルトの名無しさん
08/05/27 23:41:45
大文字小文字を区別する環境に依存した物を
大文字小文字を区別しない環境に持っていく奴の脳みそが
どーかなだよまったく
637:デフォルトの名無しさん
08/05/28 00:00:06
すでに、Abcd.cが管理下にあるのに、
うっかり、hg add abcd.cしてコミットしたら、
たぶんおしまい。今手元にwindowsがないので、確認できないけど。
638:デフォルトの名無しさん
08/05/28 00:50:29
>>636
hgって大文字小文字を区別する環境に依存してるの？
pythonで書かれてるとか聞いたんで、環境依存は凄く小さいかと思ってた。
639:デフォルトの名無しさん
08/05/28 01:16:41
pythonがcase sensitiveだから。
というかcase insensitiveな言語は、ほとんど見ないが。
そういう意味では、Windows はかなり特殊な環境だというのを自覚しないといけないな。
NTFSがcase sensitiveなのに、Windows OSが insensitiveなのは最悪。
640:デフォルトの名無しさん
08/05/28 01:25:45
>>590
svndumpでバックアップ取ってんだけど、
バックアップから戻したらリビジョン番号変わっちゃうの？？
641:デフォルトの名無しさん
08/05/28 01:26:41
↓これTortoiseSVNのマニュアルなんだけど、文字化けして見えるのはウチだけ？
URLﾘﾝｸ(nchc.dl.sourceforge.net)
642:デフォルトの名無しさん
08/05/28 01:31:27
ちょっと前にあった、リビジョン番号の議論の結論は、
「やっぱりリビジョン番号便利」と言うことか。
まあ当たり前だよな。
自動で全順序性が保証された識別名が得られるのが便利でないはずがない。
643:デフォルトの名無しさん
08/05/28 01:33:06
>>641
化けてるな。
644:デフォルトの名無しさん
08/05/28 01:33:50
>>639
今は亡きキルドールに文句言って下さい。
Windowsの変な仕様のかなりの部分はCP/Mから来てます。
645:デフォルトの名無しさん
08/05/28 01:46:13
｜
｜
｜
｜
／V＼ ,Ｊ>>642
/◎;;;,;,,,,ヽ
＿ ﾑ::::(;;ﾟДﾟ)::| ｼﾞｰ
ヽﾂ.（ﾉ::::::::::.:::::.:..|）
ヾソ:::::::::::::::::.:ﾉ
｀ ー U'"U'
646:デフォルトの名無しさん
08/05/28 01:55:31
>>644
何時まで過去に縛られてるんだよってな話だ。
OS/2みたいに、FSをcase insensitiveにする選択肢もあったハズだし。
647:デフォルトの名無しさん
08/05/28 02:06:58
過去の資産との互換性を最優先に、それこそ必死になって守ったからこそ
今のシェアがあるんだから
648:デフォルトの名無しさん
08/05/28 02:07:58
俺はファイルシステムはcase insensitiveの方がいいと思っている。
649:デフォルトの名無しさん
08/05/28 03:23:06
>>646
emx 使ってたときに区別したような記憶があるけど気のせい？？？
650:デフォルトの名無しさん
08/05/28 05:49:33
CR/LF も地味に面倒くさい
651:デフォルトの名無しさん
08/05/28 12:35:08
>>648
俺には西洋人の感覚は分からんが、CaseInsensitiveってことは、
おはよう
オハヨウ
おはヨう
オハよう
を同一に扱うってことにあたるんじゃないか？
おはよう、オハヨウはいいとして、他のはどうよ、と思う。
名前ってのは、分かりやすさの為に付けてるんだからそれはないと思う。
ただ、検索インターフェース的にInsensitiveに探すのは付いていてもいいと思う。
名前の格納自体はSensitiveが良いんじゃない？
んでもって、>>638
確かに環境依存は少ないよ。
だけど、この場合、hgはどう扱えば良いと思う？こういう環境にはチェックアウトさせない？
つまりWindowsをサポート対象外にする？Pythonでもどうしようもないと思うな。
全てのファイルを別ディレクトリに分けるとか言う格納ポリシーでないと上手く行かない。
652:648
08/05/28 12:56:33
>>651
俺がいいと思っているのは、今のWindowsの仕様そのもの。
格納自体はSensitiveだが、インターフェース的にInsensitiveな状態。
ABCとabcを同じディレクトリに作れないように規制するということ。
ABCとabcが同じとこにあったら分かり難いので、そういうファイルは
作らないでくださいと運用ルールで規制するよりも、最初から作れない
方がいい。
653:デフォルトの名無しさん
08/05/28 16:18:23
>>630-631
できました！感謝。
pageantの存在は知ってたけど何に使うのか見ただけではさっぱりでした。
手順は↓を参考にしました。
URLﾘﾝｸ(www.naney.org)
そして ~/.ssh/authorized_keysというディレクトリにpubkeyを書いたファイルを置くものと勘違いしてハマってました・・・
654:デフォルトの名無しさん
08/05/28 23:02:57
>>641
それ、どこでビルドしたんだろう?
何とかがんばってビルドしてみるかな……
655:デフォルトの名無しさん
08/05/28 23:45:10
>>654
PDF作った人はちゃんと読めてたんだろうから謎だよね…
656:654
08/05/28 23:50:19
すまん勘違いした。TSVNプロジェクトのところのやつね。
何が原因かはわからないけど化けてしまう。
手元でビルドすると化けないって感じ。
ビルドできたらアップしてみる。
657:デフォルトの名無しさん
08/05/28 23:59:29
しおりの文字は文字化けしてないね。
658:デフォルトの名無しさん
08/05/29 00:04:16
>>651
させない、が正解じゃないか。
Windowsでチェックアウトすることがあるなら、同じディレクトリにそういうファイル名を混ぜないようにすればいい。
659:654
08/05/29 00:29:35
>>657
たしか、本文はフォント埋め込みなんだけど、しおりはそうじゃなかったような気がする。
本家のビルドマシンは当然日本語Windowsじゃないんで、
ms932への変換とかそのあたりで不整合があるのかも。
他にもchmのしおりが化けてたりする。
とりあえず、手元でビルドできたみたいなんで、
URLﾘﾝｸ(www.caldron.jp)
のversion1.4.xのところから持って行ってください。
660:デフォルトの名無しさん
08/05/29 00:30:50
>>658
運用で制限するのは利用者の自由。
ただtoolで制限させる必要は無いし、制限しない以上問題は起こり得る。
8.3のショートネームの環境でも問題出ないように、名前を先頭8文字が同一
のものは認めないなんてバカげてる。
661:デフォルトの名無しさん
08/05/29 00:39:53
いやいや問題のでる環境でやろうとしたときに、ってこと
662:デフォルトの名無しさん
08/05/29 07:59:46
そのOSに対応を謳ってる以上、リポジトリ壊すってのはやはりバグだろう。
その前にエラーで止まってくれれば運用でいくらでも対策できるわけで
663:デフォルトの名無しさん
08/05/29 08:04:36
>>659
ちゃんと読めるようになってます。お世話になります。
664:デフォルトの名無しさん
08/05/29 18:16:59
>>639
この場合言語そのものがcase sensitiveかは全然関係ないだろ
665:デフォルトの名無しさん
08/05/29 18:50:36
hg で複数の（連続した）チェンジセットを
1つのチェンジセットにまとめて伝播させる事ってできないかな？
要はいろいろ試行錯誤した残骸をみせずに
最終的な結果だけ伝播させたいんだけど・・・
666:デフォルトの名無しさん
08/05/29 23:29:53
>>665
URLﾘﾝｸ(www.selenic.com)
667:デフォルトの名無しさん
08/05/30 19:37:55
>>28
いや、Haskellのメモリ効率が悪いのは事実だが、
それよりも遅延評価をうまく使っていないdarcsの実装の方が悪い。
俺ならメモリを節約できるアルゴリズムが書ける。
668:デフォルトの名無しさん
08/05/30 20:17:32
>>667
じゃあいっちょ、よろしく頼む。hgに勝てるように！
669:デフォルトの名無しさん
08/05/31 01:04:21
>>659
ありがとう～
PDF中でテキスト検索できなのが残念だけど使わせていただきます ^^
670:デフォルトの名無しさん
08/05/31 06:37:23
>>634
それはそうだけど、
svn(TortoiseSVN)はちゃんと解決してるよね？
Windowsおいてきぼりはちょっといただけないなあ
>>639
hgの実装言語の言語仕様とファイルシステムの関連性がわからない・・・
671:デフォルトの名無しさん
08/05/31 07:15:04
大文字と小文字を区別するメリットがわからんな
672:デフォルトの名無しさん
08/05/31 10:55:12
>>671
；と：を区別するのにAとaを区別しない方がおかしいと思わないか
673:デフォルトの名無しさん
08/05/31 10:58:20
>>670
SVN でも多少あるみたいよ。「SVN 大文字小文字」でググれば分かる。
674:デフォルトの名無しさん
08/05/31 11:14:04
>>670
Windowsのせいでみんなが迷惑してるんだからWindows村八分したいところだぜ
675:デフォルトの名無しさん
08/05/31 11:20:21
反抗期のガキが作ったシステムが変更できずに今までズルズルときてる訳だからな・・・
676:デフォルトの名無しさん
08/05/31 12:13:20
反抗期のガキのような物言いはよして、前向きに話そうよ。
具体的に CaseInsensitive じゃないと困る場合ってなんでしょう？
単一の単語のCaseをわざわざ区別したがるメジャーなケースって makefile 問題くらいしか知らないです。
とすると、651の例えは微妙に適切じゃなくて、むしろ単語境界をケチるために CamelCase 濫用して区別できなくなるような
ケースくらいじゃないのかな。
・もはやPCユーザ＝プログラマとはいえない
・PCで扱う範囲は増えているので、データファイルの名前に日常言語使いたいと思うのは当然
MBCS, UTF だけじゃなくて CP 違いの依存文字も含め。
CamelCase 濫用して検索難しくしちゃうなんてファイルシステムや VCS 抜きでももう起こってしまう問題なので、
Sensitive じゃないと駄目！って制約自体が、過去のシステムを変更できずにズルズルきてるだけの気がする。
てことで、652 の主張に同意。
677:デフォルトの名無しさん
08/05/31 12:20:48
っつーか、ここプログラム板だろ？
当該部分がどうか知らんけど、ほとんど Python スクリプトなんだから
簡単に直せるんじゃね？
678:デフォルトの名無しさん
08/05/31 12:30:58
>>652のような仕様はシステム的に実装するんじゃなくて、もっとハイレベルで実装すべき。
たとえばファイルマネージャレベルで実装すべき。
679:デフォルトの名無しさん
08/05/31 13:15:35
Macのファイルシステムも昔のは
たしか大文字と小文字の区別に関する問題無かったっけ？
680:デフォルトの名無しさん
08/05/31 13:45:37
>>678
それって最悪の仕様だと思うが。
ローレベルな機能使って制限を無視して作られたファイルには
ファイルマネージャ経由ではアクセスできなくなったりするぞ。
アクセス不可能なファイルの作成を許容しているシステムって
トラブルの元にしかならんと思うが。
681:デフォルトの名無しさん
08/05/31 13:51:19
エクスプローラーがドットで始まるファイル名を作らせてくれなくて困る。
既にあるドットで始まるファイルも名前変更でF2を押したらもう戻れない。最悪。
682:デフォルトの名無しさん
08/05/31 13:52:52
>>679
いまもデフォルトは区別なし
区別ありにもできるけど、Civilization IVが区別なしを期待してる
コーディングだった(全部大文字でファイルパスが埋めてあった)ので
再フォーマットしたぜorz
683:デフォルトの名無しさん
08/05/31 13:54:04
>>680
> ファイルマネージャ経由ではアクセスできなくなったりするぞ。
そんなファイルマネージャがあるんですか？
684:デフォルトの名無しさん
08/05/31 14:08:56
>>681
まー、ドットで始まるファイルは名前を付けて保存で ".emacs" みたく " で
括る必要があるのはメンドイよね。
685:デフォルトの名無しさん
08/05/31 14:47:23
>>680
そのファイルマネージャの仕様的な問題だと思いますが。
686:デフォルトの名無しさん
08/05/31 15:25:57
>>681,684
エクスプローラーからしてみたら、なんで他のOSの仕様に
配慮しなきゃいけないんだよってとこだろうw
687:デフォルトの名無しさん
08/05/31 15:34:53
>>686
ほかのOSの仕様だからじゃなくて、美しくない仕様のOSなのが問題なんだよ。
一貫性の欠如。Windowsは所詮は反抗期のガキが作ったOS。
688:デフォルトの名無しさん
08/05/31 15:40:16
>>686
そもそも、エクスプローラーのそういう挙動の根幹には拡張子を特別扱いするというWindows古来からの伝統を継いでいるだけだろ？
689:デフォルトの名無しさん
08/05/31 15:42:54
はっきり言わせてもらうと、Windowsの方がおかしいんだよ。
自分オリジナルということを主張したいがために"わざと"Unixとは違う、くだらない仕様で売り出したんだからな。
Windowsを作った豚野郎はとっとと糞の中で溺れて死ねばいい
690:デフォルトの名無しさん
08/05/31 15:44:49
そしてくだらないマーケティングと小奇麗なパッケージで素人をだまして糞を蔓延させた罪は万死に値する
691:デフォルトの名無しさん
08/05/31 15:48:17
おまいら、 NTFS の話と エクスプローラの挙動の話を
ごっちゃにして「Windowsは～」って言ってない？
692:デフォルトの名無しさん
08/05/31 19:55:35
>>688
もしかしてパス区切りがバックスラッシュなのもそういう理由だったりするの?
693:692
08/05/31 19:56:20
まちがった。>>689宛。
694:デフォルトの名無しさん
08/05/31 22:04:07
>>692
DOSのときにunixが/だから\にしたという説を聞いたことがあるぞよ
695:デフォルトの名無しさん
08/05/31 22:40:41
>>692
DOSのパス区切りが\なのは、CP/Mとの互換のため。
CP/Mはスイッチキャラクタが/だったので、パス区切り
として/が使えなかった。
DOS 3.1位まではスイッチキャラクタの変更が可能で、
パス区切り文字を/に変更できた。
696:デフォルトの名無しさん
08/05/31 23:09:33
>>695
CP/Mに階層ディレクトリなんてあったか？
パスが無いんだから、区切り文字も無い。
697:デフォルトの名無しさん
08/05/31 23:12:37
誰か言うと思って放っておいたけど、誰も言わないので俺が言う。
さすがにもうスレ違いだろ。
698:デフォルトの名無しさん
08/06/01 00:02:19
696の読解力の低さにワラタ
699:デフォルトの名無しさん
08/06/01 00:47:15
×CP/Mのスイッチキャラクタが/
○Microsoftコマンドのスイッチキャラクタが/
700:デフォルトの名無しさん
08/06/01 01:54:22
699が何を言いたいのか全然わからない。
>>695には
・DOSがCP/M互換にスイッチキャラクタを設定した(1.x)
・DOSにディレクトリの概念が取り入れられたとき(2.x)、既に/は用途が決まっていた
と書いてあるように見えるが、
それだと>>699のような訂正は不要、というか理解できないとしたら頭悪すぎ。
701:デフォルトの名無しさん
08/06/01 02:22:42
>>697が言いたいことが全然分からない(ヤツが多い)
702:デフォルトの名無しさん
08/06/01 10:38:01
CP/Mではslashは特別な意味を持たない。
MicrosoftのCP/M用basic等のswitch charactorがslashなのは、VMSの影響。
CP/MとMS-DOSではコマンド体系が全く異なる。これもVMSの影響を強く受けたからで
互換性は考慮されてない。
703:デフォルトの名無しさん
08/06/03 23:56:18
このスレでのWindowsの扱いが、このスレのmac並みでワロタ
開発者が使うノートPCてなに？ 2台目
ｽﾚﾘﾝｸ(prog板)
704:デフォルトの名無しさん
08/06/04 07:09:20
CP/Mでバージョン管理してる奴は他行け
705:デフォルトの名無しさん
08/06/04 11:36:47
最近、Pythonのpsycoって、知ったんですが
Mercurialでこいつを使うようにはできないですかね？
別に速度にさして不満があるわけでもないんですが・・・
706:デフォルトの名無しさん
08/06/04 18:09:43
>>705
適当なモジュールの先頭に
import psyco; psyco.full()
どれだけ早くなるかは知らん
707:デフォルトの名無しさん
08/06/04 18:17:49
commands.py の頭に突っ込んだら、遅くなっちゃって・・・
やっぱ、psycoの初期化のコストの方が大きいのかなぁ、と。・・・
708:デフォルトの名無しさん
08/06/06 01:34:58
Windowsの大文字小文字といえば…
今FreeBSDのソースをWindowsで見たくてチェックアウトしたら、
CONって名前のファイルがあってエラーで止まってしまう
困ったもんだ
709:デフォルトの名無しさん
08/06/06 11:21:56
時期尚早感はありますが、Mercurial いじり始めました。
これってバイナリファイルの管理はどうなんでしょう？
できるんでしょうか？
710:デフォルトの名無しさん
08/06/06 13:45:20
いや，尚早じゃないし．
すでに乗り遅れてる．
時代は今・・・・
711:デフォルトの名無しさん
08/06/06 15:01:53
成熟しないまま時代遅れ！？
専用スレも立たないみたいだし、気にかけなくていいかな？
712:デフォルトの名無しさん
08/06/06 15:05:34
デレツン乙
713:デフォルトの名無しさん
08/06/06 15:23:09
釣られてみよう
>>711
そうじゃなくて、>>710 は
Mercurialは尚早じゃなくて旬を迎えていますよ、
尚早と思っているあなたは時代に乗り遅れてますよ、すぐにでも試してみては？
という事を言っているんじゃ。
ごく最近のニュースも見ていない？
URLﾘﾝｸ(journal.mycom.co.jp)
714:デフォルトの名無しさん
08/06/06 15:39:39
>>709
バイナリファイルもOKです。
効率に関しては、確かgitとかの比較があったような・・・？
忘れたのでググり直した。
URLﾘﾝｸ(joshcarter.com)
これだったかな・・・？
まぁ、取り立てて良くもなく悪くもなくだったような気が・・・
715:デフォルトの名無しさん
08/06/06 15:53:13
>>714
darcsとも比較してほしかったな。
このテストなら、糞SCMであることが証明されるはず。
716:デフォルトの名無しさん
08/06/06 17:14:55
>>713
まあ、ちょっと釣り目的もなかったと言えばウソだが、
まだまだコマンドが変更されてたりして安定してるとは言い難いのでは？
まだバリバリ CVS を使ってる私の感覚では、Subversion も…いや、
Subversion よりは Mercurial かな。
なんだかんだでクライアントは Windows を使わざるをえない状況で、
Windows での使い勝手をもう少し頑張ってほしいところ。
大手プロジェクト(？)が Mercurial に移行している記事は見たことあります。
うそォな感じでした。
>>714
わざわざどうも。拝見させていただきます。
でもなんだかんだで CVS からの移行先として有力視していますので、
ぼちぼちやっていきます。
717:デフォルトの名無しさん
08/06/06 17:53:48
むー TortoiseHg が CVS 管理なのが変な感じ。
718:デフォルトの名無しさん
08/06/06 22:01:48
>>713
ちょいスレチだが、最近のニュース：
URLﾘﾝｸ(www.freebsd.org)
正直、ぶったまげた。
719:デフォルトの名無しさん
08/06/06 22:20:47
>>718
( ﾟдﾟ)ﾎﾟｶｰﾝ
FreeBSDはCVSからSubversionに移行って。
OS系はgitって勝手に思ってたけど違うんだな。
720:デフォルトの名無しさん
08/06/06 23:02:29
ところで、gitやhgは日本語をちゃんと扱えるようになったのかね？
721:デフォルトの名無しさん
08/06/07 00:25:20
>>720
git-svnでだけど普通に日本語ファイル名で管理できてるけど、なんかおかしいところあるの？
722:692
08/06/07 00:55:03
gitは名前が好かん。
723:デフォルトの名無しさん
08/06/07 00:55:32
む、妙なレス番が残ってた……
724:デフォルトの名無しさん
08/06/07 04:37:13
事情があってhgとsvnで二重管理したいんだけど、
hg add -X .svn .
とかやっても、
svnの管理ファイルが登録されちゃうんだけど、どうしたらいいでしょう？
725:デフォルトの名無しさん
08/06/07 04:45:12
>>724
.hgignore ファイルを作り、その中に
syntax: glob
.svn
と書いておくのはどう？
726:デフォルトの名無しさん
08/06/07 04:46:06
>>715
darcsはSCMではない、パッチベース開発基盤だ。
このスレでも順序性など糞、みたいな話が出てたが、darcsはさらにその上を行ってる。
単なるSCMとは世界もレベルも違うんだよ。…とか言ってみる。
727:デフォルトの名無しさん
08/06/08 01:40:18
>>725
できました！ありがとうございます。
728:デフォルトの名無しさん
08/06/08 03:03:25
>>726
ユーザーにとっては中でどんな処理をしているかなんてどうでもいいんですよ。
気にするの速さと容量と安定性。
729:デフォルトの名無しさん
08/06/08 06:02:50
と知名度と実績と値段
730:デフォルトの名無しさん
08/06/08 08:46:56
>>728
中の処理が (ある程度) 分かってないと、安定性とかが分からなくて
不安になるのが普通。
「どうでもいい」と言いきれるその感覚がある意味うらやましい。
731:デフォルトの名無しさん
08/06/08 10:40:30
>>714
ホームディレクトリの管理用途では
hg > git >> svn
って結論みたいだね。ソース管理はどうなんだろ。
732:デフォルトの名無しさん
08/06/08 13:57:31
上の方でhgに日本語ファイル名で問題あるとかいってるけど
まだその問題存在してるの？
733:デフォルトの名無しさん
08/06/08 15:05:43
>>726
> darcsはSCMではない、パッチベース開発基盤だ。
> このスレでも順序性など糞、みたいな話が出てたが、darcsはさらにその上を行ってる。
でもさ，darcsがパッチベースって言っても，どれだけの人がその特徴を活かしきれているのか疑問。
例えば，パッチベースだからパッチの順序を入れ替えることができるんだぜって言われても，
そんな機能使わねーよって人がほとんどだと思う。
俺は割り切って，darcsをリビジョン管理システムとして使ってる。
darcs changeで問題なくヒストリーが表示されるし，そういう使い方をしていて今のところ不満はない。
あと，darcsのマージ機能がなかなか良いんだけど，確かにこれはパッチベースのおかげかもね。
それ以外の順序性云々はお釣りみたいなもので，とりたてて喧伝する機能ではないと思う。
734:デフォルトの名無しさん
08/06/08 15:42:11
ソ噂浬欺圭構蚕十申貼能表暴予
735:デフォルトの名無しさん
08/06/08 19:05:37
>>707
ずっと動くコマンドじゃないと意味ないね。
736:デフォルトの名無しさん
08/06/09 11:07:14
SVN とか hg って、ネット越しに公開するために Web インターフェイス使うようだけど、
そのためだけにデータサーバーに Apache 入れるの？
なんか CVS からの移行先として決定打がないねぇ。
運用を根本から見直せばいいんだろうけど。
737:デフォルトの名無しさん
08/06/09 11:21:29
>>736
Apache入れなくても
CVSと同じように使えるよ
738:デフォルトの名無しさん
08/06/09 11:37:51
>>736
ん？http でアクセスしたけりゃそうだけど，
ローカルで使うなら svnserve があるし，
WAN ごしに使うにあたってそれじゃ不安というなら
ssh 経由で使えるし．
739:デフォルトの名無しさん
08/06/09 12:40:29
なんと、SVN の方はへちょいサーバープログラムがついてるのは読みましたが、
hg の方はどうすればいいんでしょう。Web 用の CGI がいくつかあるのは見えたんですが。
…と思って $ hg clone --help してみたら、ssh 関連の記述が出ましたね。
user@host:/path の形式でいいのかな？
740:デフォルトの名無しさん
08/06/09 13:32:29
なんでこんな所に釣り師がやってくるのかが理解できない。
741:デフォルトの名無しさん
08/06/09 14:41:25
hg serve
742:デフォルトの名無しさん
08/06/09 14:47:01
スミマセン、大真面目なんですが…。まじめに調べました。
ssh://user@host//path
なんですね。
ここまではわかったのですが、アクセスしたいサーバーが
クライアント → ルーター(PC) → hg サーバー
となっている場合はどうすればいいのでしょうか。
ルーターに hg をインストールするのは極力避けたいのですが。
CVS の場合は、.ssh/config で LocalForward 2401 CVS サーバー:2401
を指定しています。
>>741
ありがとうございます。できることなら上記のように SSH でやりたいと思います。
743:デフォルトの名無しさん
08/06/09 17:45:23
apache入れるのを嫌ってる奴が多いけど、何で？
大した手間じゃないだろ。
744:デフォルトの名無しさん
08/06/09 17:50:11
>>743
apacheって複雑なんだもん
いろんな設定項目があって、そんなに機能はいらねーよ。
設定ファイルが5行程度ならいいんだけどね。
745:デフォルトの名無しさん
08/06/09 17:53:30
>>743
自分で触れない事があるからでは？
それに、それだけの為に入れるには無駄という感じ・・・
746:デフォルトの名無しさん
08/06/09 18:30:57
超適当な私の場合、
1. Subversion を個人的に使い始めた (file:///なローカルリポジトリ)
2. 複数のPCでSubversion、んーと、Apache やってみますか (commitするuserの見分けがつくんだ、へー)
3. ついでに ViewVC (おお、何かカッコイイ)
4. Trac とな？ おー！(ますますカッコイイ)
5. RedMine？ すげー
6. オンラインでない時どうしよう、、、SVK 万歳！
色々世界が広がりました。
747:デフォルトの名無しさん
08/06/09 18:54:24
とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君
こうするとggrksと言われないんですねわかります
748:デフォルトの名無しさん
08/06/09 20:08:36
Subversionは、TortoiseSVNにしてもAPR(apache portable runtime)に依存してるから
Apache入れなくても半分くらいはインストールしてるんだよね。
ただ実行ファイルを入れるのは気持ち悪いとか、APRを二重でインストールしたくない
という気持ちは判らなくもない。
749:デフォルトの名無しさん
08/06/09 20:21:35
>>743
必要ないから。
750:デフォルトの名無しさん
08/06/09 21:17:21
まぁ、そもそも、Subversionの必要パッケージも多すぎると言う話もある。
CVSに比べ劣化している点だね。
751:デフォルトの名無しさん
08/06/10 07:02:38
そこはほとんどの場合問題にならないだろ。
752:デフォルトの名無しさん
08/06/10 09:08:41
>>743
データ用サーバーに余計なもの入れたくないから。
>>750
既存のもので使えるものはそれを使う、というのが Subversion コミュニティの考え方みたいだな。
でもそんな考えでやられちゃ、せっかくの最小構成が台無しになる。かといって Subversion の
サーバー機能はほぼ使い物にならないレベル。
753:デフォルトの名無しさん
08/06/10 10:21:42
だったら自分で作って貢献しろ
754:デフォルトの名無しさん
08/06/10 10:27:56
使わねーよ。
755:デフォルトの名無しさん
08/06/10 10:39:53
>>752
何が言いたいの？
愚痴をこぼすだけで何も行動しないんだったら、はっきり言ってうざいだけの存在なんですけど。
問題点を指摘するならそんな主観的な表現じゃダメだよｗ
756:デフォルトの名無しさん
08/06/10 11:06:41
ssh はダメなの?
757:デフォルトの名無しさん
08/06/10 11:40:46
吠えてんのは Subversion 使いか？
愚痴だけのレスなんてほかにもあるだろ。
758:デフォルトの名無しさん
08/06/10 12:07:00
Subversion はいいかげん Barkley DB への対応を捨ててはどうか．
759:デフォルトの名無しさん
08/06/10 12:27:51
Mercurial でなんでコマンドが hg なのかと思ったら、もしかして水銀のこと？
760:デフォルトの名無しさん
08/06/10 12:30:41
フォー
761:デフォルトの名無しさん
08/06/10 12:31:04
>>758
Ｇｏｏｇｌｅ版のＳｕｂｖｅｒｓｉｏｎはＢｉｇｔａｂｌｅをつかってんだよ。
762:デフォルトの名無しさん
08/06/10 13:52:16
リポジトリの分散というか効率的なミラーリングに対応したSCMはありませんでしょうか？
今は、TortoiseSVN使っているんですが、基本リポジトリ一個だけですよね？
どっかネットワーク越しにリモートにバックアップしておきたいのですが
まるごとバックアップだとかなりでかいくなりそうで・・・
300MBくらいのリポジトリのプロジェクトを見たら1個のファイルで60MBくらいのものもありました。
この辺、何かよい解決策はありますでしょうか？
763:デフォルトの名無しさん
08/06/10 13:55:08
>今は、TortoiseSVN使っているんですが、基本リポジトリ一個だけですよね？
こんな発言する時点で辞めておいた方が良いと思うが
まずSVKから入れば
764:デフォルトの名無しさん
08/06/10 14:01:23
>>762
mercurialつかっとけ
765:デフォルトの名無しさん
08/06/10 15:17:09
>>762
リモートに特に利用制限がないなら、rsync 使って cron で定期的にミラーリングするとか。
766:デフォルトの名無しさん
08/06/10 17:06:48
>>759
お、今日授業でやったのかい？
>>761
Googleはperforce
URLﾘﾝｸ(versioncontrolblog.com)
>>762
zfsのsnapshot&send&receiveがとても便利。
でもまああまり使える環境ないだろうから、mercurial+clone+pull*でどうかと。
一番導入負荷が、少ないからね。
で、レポジトリのファイル自体はPythonつながりでPydumpfsとかでバックアップ。
767:デフォルトの名無しさん
08/06/10 17:10:05
>>766
> Googleはperforce
知らないことを聞いたら否定するんじゃなくて、
なぜ自分の知識と一致しないのか確認すべきだよ。
google codeで使われてるんだよ。
768:デフォルトの名無しさん
08/06/10 17:17:13
>>767
んが、そういうことか。
まあ、Googleのサービスの後ろはだいたいBigTableだもんな。
769:759
08/06/10 18:05:56
書いた後で検索したら >>12 に書いてありましたね…。orz
>>766
> お、今日授業でやったのかい？
元素記号の授業なぞ受けたのはかれこれ20年前だな(やばい、歳がバレる)。
今でも最初の20個なら覚えてるような気がする。
770:デフォルトの名無しさん
08/06/10 22:55:20
Mercurial感動した。
TortoiseHgはかなり使いにくい＆ブランチがわかりくいので
早く改良してくれないかなーと淡い期待
771:デフォルトの名無しさん
08/06/11 00:21:58
Tortoiseシリーズは間違った使い方しそうでこわい。
普通にコンソールでやったほうがいいと思う。
772:デフォルトの名無しさん
08/06/11 00:25:33
NetBeansってMercurial標準サポートしてるのな
ローカルにリポジトリあると手軽さが違うなー
773:762
08/06/11 06:41:35
なんか、俺はsvnの基本がわかってなさそうです orz
・svnの別の使い方
・svk
・mercurial
・cronでrsync
ありがとうございました。いろいろ試してみようと思います。
774:デフォルトの名無しさん
08/06/11 06:48:48
個人用のインストール楽なバージョン管理システムないかな。
リポジトリもSqliteみたく組み込みデータベース使うようなやつ。
つまり、フロントエンドのGUIとバックエンドのデータベース管理システムが
単一のEXEみたいな。
775:デフォルトの名無しさん
08/06/11 09:27:34
>>770
Mercurial ってブランチ作れるんだっけ？
使いにくいのは英語だからじゃなくて？
GUI で設定する前に先行して INI ファイルで設定しておかないといけないのは
不便だねえ。今後の改良に期待したいところ。
複数プラットホームでの連携を頑張ってほしいところ。
ファイル名はともかく、ファイルの中身まで日本語の扱いが難しいとなると
少しきびしい。