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

バージョン管理システムについて語りましょう。

関連スレ
CVS 1.3 [UNIX板]
http://pc11.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://pc11.2ch.net/test/read.cgi/tech/1113141518/
Subversion r7 [プログラム板]
http://pc11.2ch.net/test/read.cgi/tech/1180858500/

Mercurial
http://www.selenic.com/mercurial/wiki/

darcs
http://www.darcs.net/

git
http://git.or.cz/

Bazaar
http://bazaar-vcs.org/

GNU arch
http://www.gnu.org/software/gnu-arch/index.html

ClearCase使うの怖かった
うｐしたらなにかがおきそうで・・・

>>3
VSSより怖いものがこの世の中にあったのかｗｗｗ

このスレのバージョン管理はどうなっているのだ

bzr init .

hg init

これは期待スレ
>>1 GJ

man co

Marcurialのqctとhgkで文字化けしないようにするには、どうしたらいいの?

最近は第何世代か知らないが、分散リポジトリが流行してるな。
それぞれ大体コンバーターがあるけどどれくらいうまく動くんだろ?
cvs/svn/hg/gitあたりが行ければoss回るのに問題ないよな。
しかしmercurialはなんでhgとかいうハードゲイ仕様なんだ。

>>11
知ってて聞いてると思うが mercurial(水銀) の元素記号が Hg
ちなみにmercurital 0.9.5 リリース

VSSしかつかったことねぇ・・・・・

VSSってWin16アプリ臭が残ってるのがなあ。
もう少し垢抜けてほしい。
Office2007ほど前衛的でなくてもいいが…

このスレの出来る１週間以上前にSubversionスレはバージョンアップしているわけだが。

Subversion r8
http://pc11.2ch.net/test/read.cgi/tech/1192864879/l50

>>15
CVSスレに書かれてたテンプレをそのまま使ったんだろｗｗｗ

>>2
GNU arch ってまだ生きてんの?

>>17
そんなに人気がないのかｗｗｗ

VSS一本だったがSubversionに乗り換えた。
ファイルの共有が出来ない点がウンコだが
それ以外はVSSを使いつづけるメリットは皆無だな。

>>19
ちょっとめんどくさいが、サブディレクトリでチェックアウトすれば良い。

Bazaar 0.92 RC1リリース
全体的な速度アップ。特にコミット速度が速くなったらしい。

バザールでゴザールはネーミングが媚びすぎだな

darcsのスケーラビリティは改善したか？
百メガ程度のソースで、２Gでもメモリ不足でコケてどうにもならなくて泣いた。
Haskell勉強中だから応援してはいるが、Haskellユーザ以外で使ってる奴いるのか？

http://better-scm.berlios.de/comparison/comparison.html

各種SCMの比較。これはいい。

>>23
あれはdarcsを位置から作り直さないと直りそうもないんだけどｗｗｗ
そこまでやる気あるのかな

バザールでゴザールは猿だろw

管理システムに限らず、各種比較といえばwikipediaはかなり充実している。
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

自分のクソコミットをもうちっと簡単に編集できるようにならないかな。

>>23
それはdarcsではなくHaskellが悪い。
Haskellでは文字列のメモリ効率が悪すぎるから、あまり大きな文字列は扱えない。

>>28
darcsにも問題がある。
quilt / dpatchと同じようなデータ管理をやっているので
どうしても速度が遅くなる

>>29
kwsk

ファイルの移動に対応しているようなバージョン管理システムってあります?
a.txt -> b.txt としたとき、「a.txt を消して b.txt を新規追加」とかでなくて。

subversionは、b.txtはa.txtのコピーであるという記録が残って、
初代a.txtまで履歴をたどれる。
古い差分を取ってみると、昔のa.txtとの比較になる。

他はしらん。

>>31
新しいやつはほとんど出来る。
CVSは無理。

>>32-33
サンクス

今は CVS を使ってるんだけど、ファイルの移動に限らずいろいろ不満が出てきたので
別のシステムへの移行を考えていたところでした。

ちょっと調べてみたけど、Mercurial が第一候補かなぁ、という感じ。
基本的には自分だけでの管理なので、分散である必要はないんだけど。

>>34
自分だけの管理だったら分散型のほうがいいと思うけど。

Mercurialを使ってみた感想。

* Subversionと違い、Mercurialではリビジョン番号がincrementalに増えていかないので（分散型である以上仕方ない）、リビジョン番号だけでは古いのか新しいのか判断できない。
* Keywordを展開する機能（$Rev$とか$Date$とか）が標準ではなさそう。pluginを導入する必要がある。

気になったのはそのくらい。それ以外では特に不満なし。
特に .hg がトップディレクトリにひとつ作られるだけというのはいい設計だと思った。 .svn が各ディレクトリに作られる Subversion がださく見えてしまう。

TortoiseMercurial みたいな優れたフロントエンドがないと　うちの会社じゃ無理だな・・・
はぁ〜

>>37
TortoiseHg
http://tortoisehg.sourceforge.net/

しかし盛り上がらないスレだな。世間ではバージョン管理をろくにしていないのか
話題にする必要がないくらい定着しまくっているのか。

集中型はもう浸透しただろうな。
今時点で使ってないとこは今後も使わないだろうし。
分散型はOSSでは使われ始めてるけど、まだまだこれから。

Mercurialを使ってみました。

まだ全然使いこんでないけど、ちょっと不満に思ったのは、
・ファイル名を変更して diff したとき、変更前は無視される
(つまり >>32 のようにはならなくて、diff については事実上 >>31)
・コメントなしで commit できない (-m "" とかで可能? 確認するの忘れた)
というところかな。

分散型で一般に言えることなのかどうか分からないけど、>>35 の言う通り、
一人でのみ管理なら Mercurial の方が CVS とかよりラクかも、と思った。
(今、俺の中での Mercurial の理解は、管理ファイルの同期を取れる RCS)

>>41
-m "comment" はあるね。

>(今、俺の中での Mercurial の理解は、管理ファイルの同期を取れる RCS)
おれもそう思った。なんというか、ディレクトリを再帰的に辿ることのできるRCS。

Alienbrain は、うんこ。

Mercurial を使ってる方がいたら質問。
Win クライアント <-> Linux サーバで Mercurial を運用しようと思ってますが、
Win 側で、フォルダ・ファイルに日本語つけても、他の Win クライアントでも日本語はちゃんとしてますか？

>>44
Mecurial 0.9.5 の official と、batteries 両方の hg を試してみたけど、
なんか駄目っぽいな。
たいがい大丈夫だが、日本語のフォルダ名で、片仮名の「ソ」が入っていると、
hg --encoding cp932 add
で、
ソフトウェア does not exist!
と表示されてしまい、add することができなかった。
ちなみに
hg status
とすると「ソ」が入っていてもリストには出てくる。なんじゃらほい。

便乗質問だが、Mecurial の TortoiseHG ってどうやって使うんだ？
Mercurial 0.9.5 batteries インストールして、
c:\>tortoisehg /register
として登録しても何も現れんが・・・

どっかのサイトでソースいじって何とかしてた。どこかは思い出せないけど。
がんばれ。

python.matrix.jp/modules/mercurial.html

>>47
>>48
どもです。ソースからやらないとだめみたいですね。
普段 Cygwin 使わないので、Mercurial のためにインストールするのはなぁ、と思いますが
インストールして試してみます。

>>49
Cygwin を入れてソースからやってみました。
結論からいうと、日本語の一部がだめです。大概の日本語はうまくいくのですが、
「ソ」や「表」のような字が入っていると、もうだめです。

$hg add
abort: No such file or directory: /cygdrive〜

>>48
のソース改編や環境変数 HGENCODING なども試しました。
set HGENCODING=cp932
set HGENCODING=shift_jis
などです。

Windows 日本語環境で Mercurial について解説されているのは、
ttp://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-encoding.html
ttp://python.matrix.jp/modules/mercurial.html
ですが、この方も「表」や「ソ」という文字は試していないみたいですね。

表\
ソ\
申\
能\

「表」と「ソ」が駄目って時点で、原因はわかったも同然だと思うのは、
すでに老人の証なのだろうか？

set HGENCODING=unicode
とかだろ常考

>>52
shift_jis の文字名井に ￥ が入っていて、パス区切りと間違えちゃう件ですね。

>>53
set HGENCODING=unicode
でも、ダメでした。
どういう環境でやってますか？
こちらは、
Windows インストーラの 0.9.5 と
Cygwin + Mercurial 0.9.4 ( Cygwin ダウンロード )
で両方試してみましたが、ダメでした。

ソースファイルの保存時のエンコード
スクリプトファイルの実行時のエンコード指定
ソース中でのコンバートの有無

すべて晒せ
話はそらからだ

>>55
ソースファイルの保存時のエンコード :
ソース中でのコンバートの有無 :
http://www.selenic.com/mercurial/release/mercurial-0.9.5.tar.gz

スクリプトファイルの実行時のエンコード指定 :
cygwin で LANG=ja

追記
http://python.matrix.jp/modules/mercurial.html
の修正をやってみた。

UTF-8 Cygwin 使ったらなんとかならん？

日本語なんか使ってるやつはばかです

>>58
おもしろおかしい

日本語というか他国語対応はリソースで管理すべきであって（ｒｙ

TortoiseHG 使えてる人います？
>TortoiseHG /register
でも使えないよ。

>>58
ばかな奴でも使えるVCSじゃないと、意味が無いんだよ

GitかMercurialのどちらか使ってみようと思うんだけど、
subversion使ってた自分なら、どっちの方が乗り換えやすいかな？

どっちか覚えればどっちもほぼ違和感なく使えるかと。
gitはc、hgはpython。速度差はそんなにはないと思う。

svnスレにあったチートシート載せとく。
http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png
http://www.ivy.fr/mercurial/ref/v1.0/Mercurial-Usage-v1.0-120dpi.png

darcs で特定の時点のソースを取り出すにはどうしたら良いでしょうか

ttp://po3a.blogspot.com/2007/12/subversion.html
リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」
あいかわらずの Linus 節炸裂

大御所なんだから、もうちょっと言葉に気をつければいいのにな。
まあその身軽さがウリなのかもしれんが。

>>67
いゃ~。向こうの大御所は、みんなはっきり言うよ。辛辣なぐらいにね。
ストールマンもすごかったし。

勉強不足でｽﾏﾝが　Python ってインタプリタ？

>>69
いぇｓ

>>69 ともあれスレ違い

技術的なポリシーにもとづいた批評は激しくてもいいよね。
今回のネタだと、マージに気を払ってない管理システムはダメとか。

ただ、ストールマンは意図的に、政治的に過激なことを言ってるわけだけど、
ライナスのほうは天然、って希瓦斯。

天然というか馬鹿なんじゃ。
自分の作ったオモチャがタネンバウムに批判されて
散々フレームしたこと忘れちゃったのかね。
……とうとうライナスもじじい陣営の仲間入りか。

まあでも影響力が大きいのは確かだろうな。
おそらく今後SCMではマージに気を使う動きが出るだろうし。

ん〜
分散型に対するリテラシーが全然足りてないな・・・
TortoiseHG のインストールというか、インストールファイルがどれなのかもよ〜わからん

頼むからwindowsを使うのを止めてくれ。

>>74
ttp://www.selenic.com/mercurial/
こっちのNewsから行った方が早い

>>76
ありがとう。
教えて貰ったところから
Mercurial-feac5b0bf9ba-TortoiseHg-1f161ca182e3.exe
をダウンロード＆インストールしたら、出来た。

し・・しかし、なんかよ〜わかりません。
svnでいうワーキングコピーというものはないの？
いきなりリポジトリ？

いや、すまんです。勉強します。
でも、サックリ　サックリ　動きますなこれ。まだ何もありませんが・・・

>>77
TortoiseHG のインストールがうまくいったら、教えてくれ。

svnとgit/mercrialの違いをまとめてるサイトないかな。

>>78
77じゃ無いけど、とりあえず動いてます。
問題は、cp932でコメント書いてるとマージがコンフリクト解決の手動マージが上手くいかない点です。
UTF8にすればよいんだろうけど、
それは 避けたいので試行錯誤中です。

>>77

分散型だからワーキングコピーもレポジトリ扱いみたい
とりあえず、使ってみたコマンドとsvnっぽい対応付け

checkout . . . . . . . . .: hg clone <src repository> <dest repository>
create . . . . . . . . . . .: hg init
show log . . . . . . . . .: hg log [-v]
破棄(rollback) . . . . : hg revert <--all | <files>>
status . . . . . . . . . . . : hg status
diff . . . . . . . . . . . . . .: hg diff
commit . . . . . . . . . . .: hg commit [-m <description>]
ソースの切り替え . .: .hg pull <src repository>
merge . . . . . . . . . . . .: hg merge

pullで切り替えてマージできるのは良いと思いました。

海の向こうのソフトだから
日本語はいろいろ問題がでる

バージン管理システムは有料のも含めるとどれがお薦めですか？

要件も何も書かずにそれかい

>>83
VCSならとりあえずsubversioin。一番普及してるし、IDEのプラグインなんかも多い。
SCMならgitかmercrial。今流行ってるし、おそらく今後SCMのsubversion的ポジションに着くはずだから。
どっちも無料なんで、自分で試して決めてくれ。

>>83
つ[貞操帯]
いや、それがどんなものかは知りませんが。
つーか、鼬害。

>>85
それで管理できるんかいw

revertできるのがいいよね。

commitしたらrevertできません。

マジレスしちまったorz

>>89
まぁ、成り行きでcommitしちゃうことはよくあるさw
# commitした成果ができたら責任取ってね♥

uncommit すればいいじゃない

mercurialで、localで行ったcommitをremoteに反映させる方法がわからん。

cp932のソースを ui.mergeを弄って、外部マージソフトでマージ確認できました。
(TortoiseMerge、winmerge、kdiff3)
今は、winmergeを採用していますが、
kdiff3で日本語を重ならずに表示する方法があれば、kdiff3に変えたいのですが、
ご存知のかたいらっしゃいませんか？

push すればいいんじゃないかな。
remote 側で pull してもいいけど。

今、mercurial使ってるんですが、gitが気になります。
両方使っている人がいたら、mercurialと比べたときのgitの利点・欠点を教えてください。
mercurial知ってればgitは特に必要ないとか、いやgitはgitで勉強する価値はあるとか、お願いします。

>>95
俺は全く逆のパターンで、Git使ってるんだけどhgがちょい気になる、、、
とはいってもGitでかなり満足してるので「気になる」といいつつ試してないんですが

gitってlinux kernelのバージョン管理のために作られたんでしょ？
mercurialに比べて汎用性がなさそうなんだけど、そこらへんどうなんだろ。

96と同じくgit使ってて、
このスレでmercurialがよく話題に上るから気になったんだけど。

とりあえず、mercurial install してみて、 pythonで書かれているのに気付いて、
微妙に、やる気を失った、俺がいる。

ちなみにgitは C と sh (bash?)

日本語の扱いに問題がある時点でやる気なし

>>98
Mercurial使ってます。
Mercurialは、CとPythonですよ。
殆どがPythonでパフォーマンスに関わる部分がCになってるそうです。
昔の、BASIC＋マシン語を思わせる設計が私の好みです。

その点、C+shellと似てるんでしょうかね？
(gitはCが大半なのかな？)

MercurialはGUIサポートが貧弱だったのが、困りものでしたが
最近は、Netbeansのプラグインでサポートされはじめたり、
TortoiseHgが開発されたり、
OpenJDK、Mozilla,OpenSolarisなどのメジャーなオープンソース系ソフトの
移行がニュースになりつつあり前途が明るくなってきてると思います。
Sunの手がけてるのが多いのは、たぶん、Sunのプロダクトだった
Teamwareにインターフェースが似てるからだと思う。
昔のエンジニアが、そのまま使える感じで移行してる気がする。
Teamwareは、私も昔使ってたので同じ理由で好みにマッチしてる気がします。
さらに、Pythonで殆ど書かれているので、移植性も高いんじゃないかなぁ？

Gitは気にはなってるけどたぶん、手を出さないと思う・・・
でも知識としては知っておきたい。Gitを使ってていいと思う部分があれば知りたいかなぁ。

MercurialはPythonさえ使用可能であれば、レンタルサーバでも気軽に入れられるので重宝してる。

cモジュールがインストールできないとだめじゃね？
昔cgiで使おうとしたときにdiffとかのモジュールがcだったから.pyで書き直したりした

>>97
確かにメール <--> パッチ <--> リポジトリ に便利なコマンドが揃ってて
なるほどなーって感じだけど、汎用性(?)がないってことは無いと思う。

うーん、やっぱMercurial気にはなるんだけど、どうも突撃できない。。。

Gitの前はsvk使ってたんだけど、Gitでこりゃ新しい、と思ったのは、
Indexっていう、ワーキングコピーとリポジトリデータベースの中間みたいなのが
あって、コミットする時にはIndexにいったん格納してからリポジトリに送る、
っていう方式が斬新だなぁ、と思った。
俺の使い方としては、編集して納得したファイルはその時点でどんどんIndexに
追加してしまっておく。Index追加済みのものは通常のdiffコマンドで対象外に
なるので(Index追加済みのものとリポジトリの間の差分を見る場合はdiffに
オプションを付ける)続けて編集し始めたファイルの差分だけまたdiffコマンドで
見ることが出来る。
だからIndexに追加したファイルは仮にコミットしたみたいな感じかな。
これをやると、変更したつもりのないファイルを間違えて変えてたり、
Indexに追加した後でさらに何か変更を加えてたりすると、気づくことになる。
あまりこれやってるとなかなかコミットしなくなるけどw機能的にまとまった
段階でコミットを作ったほうがいいように思う人とか、きれいにdiffを確認する
人なんかはいいと思う。
あとIndexに差分を追加した状態で他のブランチに切り替えてコミットしたりも
出来る。

過去のコミットを修正できちゃったりするのも新しいなぁ、と思った。
そんなことしていいのかよw　とか最初思ったけど、アリだと思うようになった。

ボスが来たモードみたいなのがあって、作業途中の中途半端な状態で急に
他の修正をやらないといけなくなった時に、今の状態をテンポラリ領域みたいな
所に保存しておいてHEADに戻り、急な修正をやっつけ終わってコミットしたら、
以前のやりかけの状態を復元（急な修正の上に）して続きをやる、とか。
例えばノリノリで新機能を追加してる途中で以前のバグを発見したとしたら、
後でじゃなくて今すぐ修正したい（忘れそう）、、、けど新機能とバグ修正の
コミットは分けるべき。。。そんな時に今の状態をいったん保存して元に戻って、
バグ修正をコミットしたら、その上に保存した状態を復元、という感じで使える。

rebaseってのがあって、ある開発版ブランチをベースにして俺コミットで
突き進んでいたとして、ある日その開発版ブランチが安定版ブランチに
統合されて成長が止まってしまったとしたら、俺としてはもう伸びることのない
開発版ブランチを追っかけていてもしょうがないので、いったん俺コミットを
全て無かったことにして、根っこを安定版ブランチの先頭に引越ししてから、
俺コミットを全て適用しなおす、ということが出来る。これ便利。

あとは、、、cherry-pickってのがあって、適当なとあるコミットを指定して
今の状態に適用してみたりできる。
逆に問題のあるコミットを特定したら、履歴からそのコミットだけ除外して
みたり。

分散型で超気軽にブランチが作れるから、気軽にコミットしたり取り消したりとか、
やりたい放題なのが気持ちいいかなぁ。

以上、Gitのチラ裏でした。

>>103-104
GJ
index面白いな。RDBMSのtransactionみたいなものか。insertしたけどcommitしてない状態。

>>103-104
超GJ。過去のコミットを変更できるのは斬新だな。俺もやってみてー。

subversionしか使ったことのない俺の感想なんだが、
VCSではシステムのメインがリポジトリそのものだったのに対して、
mercurialとかgitはコミットによるパッチが重なり合って全体を構成してるように感じる。

svnが木で今までの幹は堅牢で先にどんどん伸びていくとしたら、gitなんかはstackに近いイメージ。
途中で割り込ませたり、積んでたのを隣に移したり、過去のお皿を書き換えたりですごく柔軟性が高い。
このシステムはすごくパッチの仕組みの影響を受けてるんじゃないかなあ。

TortoiseGitでも出たら使おうって気にもなるんだけどな

>104
> 逆に問題のあるコミットを特定したら、履歴からそのコミットだけ除外して
> みたり。

Subversionの逆マージとなにが違うの？

>>106
たしかにstackっぽいかも。Git使い始めはSubversionみたいなバージョン番号が
付かないことにかなり戸惑ったんだけど、使ってるうちにGitではそれが必要ない
んだなと思うようになった。今までのように線形に伸びていくのではなくて、
ソースコードの成長は常にパラレルなもので、好きなようにコミットをいじり回して
いいんだと思うようになった。

>>108
すまん、Subversionの逆マージって分からないんだけど、新しい機能(1.5?)なのかな。

>>104
Gitのサーバを建てる手間はどれくらいですかね？

Linuxに特化してるって話があるんでFreeBSDのレンタルサーバに
入れる手間はどんなもんかなぁ、と。

Mercurial の使い方のチュートリアル
http://www.selenic.com/mercurial/wiki/index.cgi/JapaneseTutorial

今読んでるところなんだけど、
http://hgbook.red-bean.com/hgbookch1.html#x5-200001.6.2
に、Git との比較が書かれてるね。
Mercurial 側からの見解なので、その分は差し引く必要があるかもしれんけど、
参考までに。

なる。
読んで受けた印象としては、Gitはピーキーなイメージ。
Linuxカーネルの開発スタイルに極めて合致してるんだろうね。
多くのユーザがその用途で使ってるわけだし、それ以外の用途の為の変更で
カーネル開発がしにくくなるのは本末転倒なんだな。

んじゃあ、使いやすさはmercurial、パフォーマンスではgitって感じか。

Subversion だとバグ報告に「リビジョン何番で発生した」とか書くのがいいと思うんだけど、
Git だとどうやって特定の状態を指すの？聞いてる限りだとそういうのが無いような感じ
なんだけど。

>>110
＞Gitのサーバを建てる手間はどれくらいですかね？
サーバといってもいろいろなやり方があるんですが、、、
gitプロトコル以外にhttpとかsshとかWebDavとか。
全部やったわけじゃないけど、まあ難しくないです。
とりあえずFreeBSDならportsにGitありますよ。

>>113-114
＞多くのユーザがその用途で使ってるわけだし、それ以外の用途の為の変更で
＞カーネル開発がしにくくなるのは本末転倒なんだな。
俺は普通にGitで不便だと思うことは何にも無いけどなぁ。
Linuxカーネル開発用途以外のものが無いなんてこともないし(俺はカーネル開発
じゃなくてJavaに使ってる)
有名どころだと、xorg、compiz、samba、FedoraあたりがGitを採用してる。
あとGCCもGitが有力らしい。

>>115
タグを付けてあればそれになると思うけど、、、(release_x_xとか)
もっと詳細に特定するならSHA1ハッシュがコミットのユニークなIDになってるので、
それで指定できる。

>>117
何のハッシュ? コミットログのハッシュ?

実物みたほうが速いんじゃない。
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=56f5066d477836a975122f4e5748c0f4fb790175
みたいにコミットとツリーにそれぞれid(tree-ish、commit-ishの識別子)がつく。

ちょうどそのログはgit-cherry-pickな奴だった。
(cherry picked from commit 7caf51d1a5a86ae884e0087795636222c082962c)
はコミットid 7caf51d1a5から拾ってきたっつーことね…。

Learning Git
http://www.simplicidade.org/notes/archives/2007/12/learning_git.html

gitは使いこなすとスゴそうだけど、インタフェースが複雑で最初は大変そう
http://www.jukie.net/~bart/blog/git-vs-hg

Subversoinですらやっとこさ導入してるリーマンドカタ的現場では、とても無理そうだな。
というか、おまえらんとこってどうなん？
お前らって、「あって当たり前のSCMを手配してくれる人」？
「面倒なことを言い出すウザイ奴」的立場？

導入やお守り、簡単な説明はいいけど、手順書一式用意しろ、には参った。

必要ならリポジトリにプロジェクト作るから言ってね、って言われる立場

まだ CVS だけど

学生サークルだが、subversionどころかバージョン管理そのものについてまったく知らないのがほとんど。
お前ら趣味でプログラムしてるのとちゃうのかと小一時間(ry

お前が導入して便利さを知らしめてやればおｋ

>>122
＞gitは使いこなすとスゴそうだけど、インタフェースが複雑で最初は大変そう
確かに最初は覚えるのに苦労するかも知れないなぁ。
ただ俺が思うのは、CVSにしろSubversionにしろ、初めて使う時にはそれなりに
頭を悩ませただろうし、他人に使い方を覚えてもらうなんてのはさらに面倒だった
だろうということ（CVS->Subversionはとても似てるからすんなりかも知れないけど）
特に今現在インフラとして使ってるSCMがある人の場合、抵抗感は大きいと思う。
（viからemacsに乗り換えるようなもので。。。）
だから、Gitは一切SCMを使ったことの無い人のほうが覚えやすいかもしれない。
って、hgもそれは同じだと思うんだけどなぁ。そんなにGit複雑かなぁ。

>>125
導入しただけで済めば苦労はない。
コミットとか管理の概念もないし、理解したかと思っても、
日付毎のディレクトリを掘ってコミットする奴とか、zipに固めたのをコミットする奴とか…。

そもそも理解してないんだよな、VCSの便利さを。
どれだけ便利か本人たちが理解すれば、前向きに勉強してくれると思うんだが・・・。

Gitインストールした。

$ ls /usr/local/bin/git* | wc -l
145

これはないわ。

$ cd /usr/local/bin; ls git*

git git-gui git-relink
git-add git-hash-object git-remote
git-add--interactive git-http-fetch git-repack
git-am git-imap-send git-repo-config
git-annotate git-index-pack git-request-pull
git-apply git-init git-rerere
git-archimport git-init-db git-reset
git-archive git-instaweb git-rev-list
git-bisect git-local-fetch git-rev-parse
git-blame git-log git-revert
git-branch git-lost-found git-rm
git-bundle git-ls-files git-runstatus
git-cat-file git-ls-remote git-send-email
git-check-attr git-ls-tree git-send-pack
git-check-ref-format git-mailinfo git-sh-setup
git-checkout git-mailsplit git-shell
git-checkout-index git-merge git-shortlog
git-cherry git-merge-base git-show
git-cherry-pick git-merge-file git-show-branch
git-citool git-merge-index git-show-index
git-clean git-merge-octopus git-show-ref
git-clone git-merge-one-file git-ssh-fetch
git-commit git-merge-ours git-ssh-pull
git-commit-tree git-merge-recursive git-ssh-push
git-config git-merge-resolve git-ssh-upload

git-convert-objects git-merge-stupid git-stash
git-count-objects git-merge-subtree git-status
git-cvsexportcommit git-merge-tree git-stripspace
git-cvsimport git-mergetool git-submodule
git-cvsserver git-mktag git-svn
git-daemon git-mktree git-svnimport
git-describe git-mv git-symbolic-ref
git-diff git-name-rev git-tag
git-diff-files git-pack-objects git-tar-tree
git-diff-index git-pack-redundant git-unpack-file
git-diff-tree git-pack-refs git-unpack-objects
git-fast-import git-parse-remote git-update-index
git-fetch git-patch-id git-update-ref
git-fetch--tool git-peek-remote git-update-server-info
git-fetch-pack git-prune git-upload-archive
git-filter-branch git-prune-packed git-upload-pack
git-fmt-merge-msg git-pull git-var
git-for-each-ref git-push git-verify-pack
git-format-patch git-quiltimport git-verify-tag
git-fsck git-read-tree git-whatchanged
git-fsck-objects git-rebase git-write-tree
git-gc git-rebase--interactive gitk
git-get-tar-commit-id git-receive-pack
git-grep git-reflog


これはひどい

ふと思った。
-l してみたら実体は１個で、argv[0] で振り分けてたりしそうだと。

ディスクサイズを問題にしているわけじゃない。
gzipとgunzip程度ならそれでもいいけど、こんだけファイルを散らかしているのをなんとも思わないのかな。
たぶんcommand completionしたいがために、sub commandを使わないようにしたんだろうけど。

ちゃんと読もうぜ
We divide git into high level ("porcelain") commands and low level ("plumbing") commands.
http://www.kernel.org/pub/software/scm/git/docs/

まあPorcelainでもその中で通常使うのはいくつかしかない
http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png

>>128

VCSとは?

>>135
Version Control System

SCM のほうが一般的だと思うけどな。

どのぐらい？

hg歴1週間の私が Git 使ってみましたよ。
gitk が面白いね。

で、branch を切り換える、って考え方がすげーしっくりきた。
これで Git に移行する気マンマンになりつつある。

一番気になるのは database の頑健性なんだけど、これはしばらく使ってみないと分からんな。
git-fsck というコマンドが存在する、ということが却って不安を煽るんだが…

>>126
> って、hgもそれは同じだと思うんだけどなぁ。そんなにGit複雑かなぁ。
俺も実際に使う前は、Git てコマンドたくさんあるらしいし、覚えるまでが大変そう、と思ってたけど、
実際に使ってみると基本的な作業は CVS とかと大差ないと思った。
むしろインターフェース的には CVS と Git の方が CVS と hg より近い (ほんのちょっとだけどね)
とすら思った。
ただ、git co とできないのが不満。ln -s git-checkout git-co とかすりゃいいのか? (w

ところで、git commit --help で No manual entry for git-commit とか言われるのは、インストールに
失敗してる?

>>139
＞git-fsck というコマンドが存在する、ということが却って不安を煽るんだが…
どうだろうね、けっこう有名なプロジェクトでガンガン使われてるのが安心を
もたらすと思うんだけどねー。

俺の場合は仕事ではまだSubversionなので、個人的にGitで開発して
中央とのやり取りの時に git-svn で Subversionレポとやり取りしてます。
誰も気づかないよw
コラボしなくても、個人使用だけでずいぶん楽しいですよGit。

＞ただ、git co とできないのが不満。
http://git.or.cz/gitwiki/Aliases
俺は~/.gitconfig をこんな感じにしてます
[alias]
st = status
co = checkout
br = branch

＞ところで、git commit --help で No manual entry for git-commit とか言われるのは、インストールに
失敗してる?
してるかも。。。make install-doc かな？

今はSubversionを使ってて、
GitとMercurialをちょっとかじってみたいなと思ってるんだけど。
作業履歴も含めたバックアップはそれぞれどうやるの?

例えば、ある1つのプロジェクトを自分1人で扱うとして、
元リポジトリをいくつかに複製してそれぞれで個別の作業をして、
時折"リリース版"を作る場合:
1. リリース用リポジトリを1つ作って変更点を集める
2. そのリポジトリのバックアップを取る → 具体的には?
とかなのかな。イメージがいまいち掴めてないかも。

単にリリース用リポジトリ複製して保存しとけばいいと思うけど。

>>134
ごめん、なにがいいたいのかわからん。
high levelとlow levelに分類したところで、コマンドの数が多すぎる理由になるの？

cg cg-commit cg-reset
cg-add cg-diff cg-restore
cg-admin-cat cg-export cg-rm
cg-admin-ls cg-fetch cg-seek
cg-admin-lsobj cg-help cg-status
cg-admin-rewritehist cg-init cg-switch
cg-admin-setuprepo cg-log cg-tag
cg-admin-uncommit cg-merge cg-tag-ls
cg-branch-add cg-mkpatch cg-tag-show
cg-branch-chg cg-mv cg-update
cg-branch-ls cg-object-id cg-version
cg-clean cg-patch cg_annotate
cg-clone cg-push

あ一個変なの入ったけど、cgとかもあるよw　stgitとかも。
git用のもあるbashcompは便利だがメインzshなんだよな。。。
zshcompはまだ使ってないんだがどうなんだろ。スレ違い…

>>143
コマンドの数が多すぎるのが問題なの？

gitってリポジトリの一部だけをcloneとかcheckoutすることって出来る？

>>142
普通のファイル群として保存すればいい(それ以外にない)ってことか。thx。
いや、svnのdump/loadみたいなものはあるんかなと思ってね。

>>146
分かってないだけかもしれないけど、それは無いような希ガス
Gitはファイルとかディレクトリではなくてコンテンツで考えるモノ、らしい

分散型でアクセス権をディレクトリ毎に制御できるものってない？

>>149
subversionではそういうのあったっけ。

svnserveとかWevDAV経由なら出来るんじゃなかったかな。
リポジトリの下のconfにそれっぽいのがあるでそ。

mercurialはrenameの前後でdiffとれない？

OpenJDK が Mercurial を使うことにしたそうだ。

svnはエンコード混在環境でもコミットログを内部utfで処理してくれますが、gitやhgのコミットログのエンコードは何が使われるのでしょうか？

乱暴ないい方するとWindows,ubuntu,旧soralisでs-jis,utf-8,eucなエディタでコミットしたときにログを相互に読めますかって話です　(svnは相互にログは読めました、cvsはダメだった)

>>154
とりあえずGitはデフォでUTF-8だけど、設定ファイルに書いたらできたよ。

この手の質問って、hgとGitどっちにするか評価中ってことなのかな？
それならこんな細かいことじゃなくて、機能の核心が重要なんじゃないかと
思うんだが。まずは使ってみたほうがいいと思うよ。

154にとっては、それが核心機能のひとつなんじゃないかな。
異機種異環境混在環境でも動作するというのは案外大事。

>>156
まああれだ、どうもSubversionの機能をGitやMercurialに当てはめていくような
アプローチをしたがるみたいなんだが、そうじゃなくて頭真っ白にして考えないと
うまくいかないと思うんだおれは。
実際に使ってみれば、ログの文字コードを心配する前に、もっとドラスティックな
ことが起きるはず。

SVNの説明にも必ずCVSではこうだったみたいなのがあるじゃん
最初からHGやGit使うなら良いが既にSVNとかを利用している人からすれば
どうしても機能の当てはめ等は必要
自分は良くても他の人が移行に納得しない

おれsvnからgitに移行したけど、gitはsvnに当てはまらないことばっかだよ。。。

当てはまらない事だらけって事は利用者は使い方を学ばなければならないって事だ
中々覚えようって気にはなってくれないから難しい

Git - SVN Crash Course
http://git.or.cz/course/svn.html
最初はこれ見てやってみたんだけど、やっぱこれでgitが分かるってことはないわけで
Tutorialをやってみるのが近道だった。
中央集権型と分散型なんだから、簡単に移行できないのはしょうがないかもね。

gitかhgに移りたいけど、eclipseのプラグインがでるまで我慢。

俺はWindows Explore連携ができないと、移る気がしない

svkだって亀が使えたらって思うが

まぁ、人口に膾炙するためには、日本語リソースが充実しないとな

gitとかsvnとかhgとかみてたら、2chの略語に見えてきた。
もうさ、2chのVCS/SCMつくろうぜ。

kwsk -> 詳細ログ表示
ktkr -> 取り出し
wktk -> 更新があるかチェック
up -> コミット

gitとhgをcygwin上でTutorialをこなしたけど、
gitは branch と gitkが すごく よいと 思いました。
って 思いつつ、hg リファレンス を読んでたら、branch在るんですね。
Tutorial 見て、cloneでどんどんレポジトリ増やしていくしかないと思ってしまったorz

気づいた差異は、こんな感じ
速度
hg > git
hgは一瞬、gitは一秒程度かかるもの(checkout, commit)がある

commit
hgは、更新ファイルがデフォルトでコミットできる
gitは、更新ファイルもaddを使って追加するかcommit -a をする

マージのコンフリクト時の挙動
gitは衝突部位を両方持ったファイルを作成する
hgは衝突ごとに随時衝突部位を両方持ったファイルをエディタで開いて修正を求める。

あと hgは、狙ったのかホームポジションの隣で両人差し指一打ですむのが楽

>>167
ｈｇといえばやっぱりアレだろ

>>168
どれだよ。

ああ
gitはcommitせずに複数マージできるが抜けてました。

>168
何でしょ?

$ hg foo

gitやhgが流行ってるみたいですが、いまいちsvnとの使い方の差が掴めません。
実際にsvn->git,hgへ移行して、使い方がどう変わったかだれか教えてもらえませんか？

cvsからsvnへ変わったのとは違う
どう変わったか？と言うより、概念そのものが違う

gitに移行しない奴をアホ呼ばわりする奴は何なの？

会社でアホ呼ばわりされたのか？
チラシの裏にでも書いておけ。

>>174
Git信者以外に考えられないのですが・・・・
本人は否定しているのですか？

>>172
大きな違いはローカルコミットができる点じゃないかな？
自分の作業が一段落するまで他の人に影響を与えず手元で変更履歴をとって管理できる。
それができないってのが、昔TeamwareからCVSに移行したとき不便だと思った所なんだけど。

>>176
なるほど、それは使い方が大きく変わりそうですね。

ローカルコミットか・・・
確かに便利そうだ

誰かgitとhgとsvn使っている人、違いをまとめてうpしてくんろ

svnもsvk使えばローカルにコミット出来るけどな

gitはどうかしらないけどhgはCVSとか.svnに相当する.hgディレクトリがルートにしか作られないのがすき。
それ + .hg自体がリポジトリなのでリポジトリの作成が気持ち的に軽い気がする。
なんかのファイルをいじるときにとりあえずhg initってのをよくやるようになった。

↑追記: バージョン管理というよりdiffを簡単に取るためだけど

>>180
gitも同じっすね

>>179
確かにsvkはローカルコミットできるね
俺はsvkからGitに変えたんだけど、外見はけっこう似てるかも知れない。
svkはどこどこのrevいくつまでマージした、っていう情報をもとにsmergeするけど、
Gitは各コミットにハッシュが振られているので、もっとぐちゃぐちゃにマージさせても
けっこう大丈夫。なので、何かしようと思うたびにローカルでブランチ作って、
ひと区切りついたら本線にマージしてそのブランチは廃棄、っていうのを繰り返す、
というのがフローとして使える。
svkも同じような使い方してたんだけど、svkはマージが遅くて辛かった。Gitは鬼速い。
あとsvkのswitchがGitのcheckoutにあたるようなイメージなんだが、svkでswitchしまくる
というのはちょっと気持ちよくないんだけど、Gitはそれが普通なので気持ちいい。
まーあとはGitならでは(hgにもありそう?)のresetとかrebaseとかの、やりたい放題が
気持ちいいかな。過去のコミットを遡って修正なんて、最初はかなり驚いた。

> Gitは各コミットにハッシュが振られているので、
> もっとぐちゃぐちゃにマージさせてもけっこう大丈夫。
svn使いの俺様から見るとコンフリクトしまくりそうなんだが...。

そういう複雑な運用がサポートされてても実際に使えるかどうかは難しいよね

>>162
hgにはある

>>184
行レベルでぶつかればコンフリクトしますな、さすがに。
でも追加した変更が誤解されてばっさり元に戻されたりとかはないし、
共同作業でもきちんと分担が為されてれば、同じファイルの同じ行がぶつかる
ということはそれほど無いはず。

>>185
慣れ、だと思いますよ。

>>103
そういう使い方をしたいなら
darcs、StGit、Mercurial+MQを使うべきだろ。

ここにいるGit使いは、darcsに移ったほうが幸せになれるかもしれない。

darcsって何がいいの？スケールしないって問題はおいといて。
バージョン管理じゃなくて、パッチ管理システムらしいけど、
それって何が違ってどう嬉しいんだ？

もっとわからんのは、darcs-git。
gitにdarcsのコマンドUIを載せたものと理解してるけど、darcsはUIがよいって事？
ってか、自慢のパッチ管理システムは実はどうでもいいのか？

quiltに似てるらしい。＞darcs
quiltって何か知らんけど。

git って、「ぎっと」なの？「じっと」なの？

北森セレ2.6で、ロゴ野郎に買った！
…裏技だけど。

>>192誤爆ｽﾏｿ

>>191
http://www.youtube.com/watch?v=4XpnKHJAok8
linusは「ぎっと」と読んでいる

RapidSVN使ってるけどリポジトリのあるPCの電源を落としたまま
コミットしようとすると更新情報ぶっ壊れて全部とりなおすハメになるのは
他のツール使ってもいっしょですか？

>>195
ウサギはもう開発終わってるからなるべく使わない方がいいよ。
一々挙げないけど、それ以外にもいろいろ不具合あるし。

>>196
そうなんかぁ・・・
他のツールってなんかあんまりなじまなかったんだけど？ｗ
GUIでスタンダードなツールって何？
なんかあんまりブラウザと合体するとか好きじゃない

>>197
俺も昔そう思ってた口で、ウサギオンリーで行こうとしたんだけど、
あまりの使いにくさに断念した。今は亀で妥協中。
どうしても亀が嫌なら、javaのクライアントがあったはずだから試してみたら？
たしかsvnスレの最近100レスぐらいに名前が挙がってたはず。

ウサギと亀w
Rapid と Tortoise にはなんか因縁でもあるんか

>>187
ありがとう。なぜか親近感がわいてきた。

会社のリポジトリは数年前にCVSからSubversionに移行させたんだが、
そのうちオレオレリポジトリみたいな使い方からgitを試してみるかも。

>>191

>ちなみに，'git'は英国俗語由来だそうです，そうであれば発音は'ギット'です
http://www.netfort.gr.jp/~dancer/column/200504-git.html.ja


だって。

俗語ってなんだろう。犬の糞とかかなｗ

>>202
ばかだなあ

これか？
http://en.wikipedia.org/wiki/Git_%28insult%29
> Git is a relatively mild British slang term, used to denote a silly, incompetent, stupid, annoying, or childish person.

リーダーズ英和辞典
git[名] <俗> ろくでなし、ばか者、いやなやつ [get]
get[名] <俗> ばか、とんま

犬の糞という訳をしてもあながち間違いではないような

喪前等m-wを使おうぜ。発音も意味も両方判るんだから。
ttp://www.m-w.com/dictionary/git

どうでもいいが、ci-gitとすると墓碑銘になるからaliasを作るときは要注意だw

>>200
まずsvkを使ってみてはどうか
CVSからSVNへ移行したのと
SVNからGitは敷居が全然違うと思うよ

Rapid


は、ウサギじゃないと思う・・・・

>>200
gitはディレクトリがそのままリポジトリ＆作業コピーになるから、
一人で始めるのはすぐにできますよ。
git-svnでgitからSubversionに直でコミットするのは、俺svnリポジトリで
練習してからのほうが良いと思います（意外にアッサリ実行して
しまうので）

>>208
それも良い手だと思います
俺も未だにSubversion同士のマージはsvk重宝してる

>>209
そのとおりなんだが、RapidSVNのロゴがウサギなんだ。
RapidSVNのサイト見てみ？

以前も言ったように、ユーザーパッチでの開発とかいう文化が存在しない
bsdやsolarisはことごとくmercurial。これは犬臭いのを避けたかったから。
犬臭いといっても、mercurialもgitもどっちもlinuxのバージョン管理システムだった
bitkeeperの代替のために作られた。ただもう一方の作者がカーネル作者だったため、
採用は当然そっちになっただけさ。開発スピードの差はリポジトリ見れば明らかだよ。

>>212
つまりどっちが活発に開発されてるの？

>>211
うぉ！しらなんだ・・・・いつの間に・・・・
昔は無かった・・・よね？

gitはsh依存がなけりゃな...

>>215
無知な質問で恐縮だが、shってシェルのこと？

shというかbashのつもりで書いたけどシェルでもいいよ

>>217
それじゃあzshなんかでは動かないのか？
というか、bashすらないwindowsではどうやって動かすの？cygwinオンリー？

SFU(だっけ?)でも入れるんじゃねーの?

Mercurial も Python 要るよね

gitのwindows版はcygwin or msys(の一部？)環境が必要
mercurialはpy2exeでランタイム同梱だからpythonのインストールは必要ない
どっちも一括パッケージになってるインストールの手間はとくになさそう
でもgitはもしかしてdosプロンプトから普通につかえなさげ？(shに入る必要あり？)

Mercurial死ぬほど重くて、管理システムとしてどうとかいう以前に日常的に使うツールとして使い物になんね。
管理対象のファイルが20個程度のところに glibc と gcc 展開してあったんだけど、
20個分のdiffとるのに数分も待たされたぞ。

それはそれとして、darcsでローカルにrecordしてある状態でpullしてもrebaseしてくれないのだが、
パッチの順番変えるのってどうやるの？

Mercurialは.hgignoreで

syntax: glob
*

しとかないとエライことになる場合があるな。

>>221
msysのやつインストールしてみたらmsysとMinGWとperlといろいろインストールされたよorz
msysのshの中からじゃないと使えないっぽい

>>222
svnとgitの数字もうｐ

>>222
darcsってけっこう使われてるのかな？
俺のまわりでは一人だけ居るけど、「使ってみたけど挫折気味」な感じだった。

>>222
> 管理対象のファイルが20個程度のところに glibc と gcc 展開してあったんだけど、
> 20個分のdiffとるのに数分も待たされたぞ。

管理対象外のディレクトリは直接展開せずシンボリックリンクを張るようにするとどうかな?

>>227
いや、明らかに管理対象のファイルだけスキャンすればいいのに、まるごとdiffとってから必要部分だけ抜き出す
というアホい実装になってるか、最初から死ぬほど遅いかのどっちかだから、もう評価するのやめた

>>225 svnは最初から評価対象外だから知らんが、gitもdarcsもせいぜい数秒だったぞ

>>226 Haskell 使いではほぼデフォじゃないかな？よくシランが
とこれで、やっぱりどうやってもパッチの順序かえたり rebase ができないのだが、識者タノム

だれかgit,hg用のeclipseプラグイン作ってくれねーかな。

>>228は、そんな辛口を言っておきながら、
「べ、べつにHgの為じゃないんだからね」とか言って
今晩にもそのアホい実装を修正するパッチを投稿してくれるに違いない。

俺も欲しい。
>>231 よろしく。

>>231
>>233

http://git.or.cz/gitwiki/EclipsePlugin
> Java GIT/Eclipse GIT (by Shawn Pearce) is a Java GIT library and
> plugin for Eclipse IDE

http://www.vectrace.com/mercurialeclipse/
> Mercurial Eclipse is a plugin for the Eclipse platform to use
> Mercurial version system.

気になったから、やってみたんだけど。

新規repositoryにgcc 4.1.1と4.1.2を順にcommit して、
diffを出力したときのtimeの値

* git
real 0m13.339s
user 0m6.798s
sys 0m1.461s

* hg
real 0m27.871s
user 0m21.249s
sys 0m1.406s

参考になるかわからんけど。

pythonものは、 起動の時間（で通じる？）の遅さが気になる。

特にCUIの場合は、GUIのツールと違って、実行しっ放しで使わないから。

git スレ、たてました。
遊びにきてね。

git スレッド＠ Linux 板
http://pc11.2ch.net/test/read.cgi/linux/1197798039/

>>235
userとrealが二倍以上違うな。

バージョン管理
いろいろ言われてるけどろくなソフトがないなｗ
まともなのはEclipseにくっついてるのとVSSぐらいだなマジで
これ以外むかつくから使わないほうがいいよ

バグったときの動作が最悪
通信途中で切れたときとかなにのにあるっていったり
更新中だからちょっとまってろって、お前、いつまでまたせるつもりかとｗ
いい加減、その操作あきらめてもとの状態に戻しておけよｗ
ってそんなこともできねぇし、ソースコードの履歴と修正には敏感だけど
自己のソフトのバグには鈍感とかありえねぇ動作してんじゃねぇよｗ
作った奴なにかんがえてんねんｗ

>>238
で、どこを縦読みしたらいいんだ？

自
作

ここかな？

>>235 なんでそんなに早いの？折れの環境が悪いのか？

>>238
読む気はしない、が

実際のところ、クラッシュ耐性が
どのくらいあるのか気にはなる。
fsやdbもこういう所が重要だし。

svnはfsfsを時間をかけてやってるけど、
他のは大丈夫なのかな。

mercurialで、ファイルを含んでいるディレクリがあって、ファイルはaddせずにディレクリだけaddすることはできますか。
subversionだと svn add -N dir1 でできるんですが、hg add だとそれっぼいオプションが見つかりませんでした。

>>237
git 、hg両方とも、real - user をしてみるとわかるけど、大体6〜7秒差がある。
端末の描画速度かと。

一応、出力を/dev/nullに向けた値を張ります。
* git
real 0m6.806s
user 0m6.365s
sys 0m0.428s
* hg
real 0m21.640s
user 0m20.819s
sys 0m0.780s

>>241
速いって言われても、何とも言えないけど。
関係ありそうな環境。

CPU Pentium4 2.4c
memory 1G
file system ext3
terminal mlterm
kernel 2.6.22
GNU C Library stable release version 2.6.1
git version 1.5.3.6
GNU bash, version 3.2.17(1)-release
Mercurial Distributed SCM (version 0.9.3)
Python 2.4.4

>>244
実験乙。
>>235の結果と比べると、さらに差が広がってるな。
これは速度的にgitが圧倒的に有利ということでいいのだろうか？

しかし、>>112のMercurial側の主張によると、
> In terms of performance, Git is extremely fast. In several cases,
> it is faster than Mercurial, at least on Linux, while Mercurial performs better on other operations.
> However, on Windows, the performance and general level of support that Git provides is,
> at the time of writing, far behind that of Mercurial.
パフォーマンスの点では、Gitは非常に速いです。
ほかのOS上ではMercurialの方が速いものの、少なくともLinux上ではいくつかの場合Mercurialよりも早いです。
しかしながら、ウィンドウズ上では、Gitのパフォーマンスと提供するサポートの一般水準は(おそらく周辺のソフトウェアのことを指すex:TortoiseHgなど)、
書いている現時点で、Mercurialには遠く及びません。
(厨房レベルの訳スマソ)

・・・らしいので、windows側でも検証せにゃならんということだろうか。

> on other operations

/dev/nullにリダイレクトしてパフォーマンス測れよ・・・

えーと、適当なこと言うけど、windowsでcygwin使ってるならstat劇遅だからな

昔、cygwinが遅いからbcc使ってたなぁ・・・

>>228
diffするとstatusを呼ぶから遅い。

えーっと、つまり Git は Windowsに弱いらしい、ということ？

そもそも日本語をちゃんと使えない時点でダメダメ

使ってない俺が言うのもアレだが、Cygwin依存のツールは使いたくない。
異なるバージョンのcygwin1.dllがいたりすると、他のツールが使えなくなったりしてイライラする。

依存してないけど？

Mercurial を使ってるんだけど
hg view
で出てくる GUI (gitk) ではコミット時の説明文の日本語が文字化けする…

>>254
gitはcygwinで使うのが普通だと思ってたけど、今は違うのか？

>>256
msysgit

>>255
tcl-tkだからUTF-8にすればたぶん読めるはず

>>257
安定していないものは、仕事では使えません

>>259
cygwin の git って msysgit より安定してる？

なんでwin使ってんだw

サーバはともかく、クライアント側はWinで良いと思うが

Mercurialも、日本語ファイル名をどうやってうまく扱えばいいのかわからんです。
Linuxサーバ上で、cgi経由のレポジトリを置いて、
WindowsとMacOSX間で管理しようとしてるんだけど・・・・

>>263
http://www.selenic.com/mercurial/bts/issue849

>However, there is a following error when I want to add file/directory which
>filename contains non-ascii character.

>abort: No such file or directory: c:\hg-repo\test??.txt

>Error also appears when I use ``hg status`` or ``hg log``.

>To reproduce this error, you can try to create a file named 'test中文.txt'
>and add this file to your branch to verify this problem.

これのことだよね。hg status および hg log でも起こる現象で
hg add file/dir でエラーが出ちゃう罠… add status log... であぼーん

使えねー

日本語ファイル名なんて使ってるやつはばかです

% git-status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: 白黒
#
no changes added to commit (use "git add" and/or "git commit -a")

% git-log -p -1
"\347\231\275\351\273\222"
commit 242e3908ecd84cf05f79aa416ad735ce2e6f541f
Author: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Date: Wed Dec 19 11:25:21 2007 +0900

test commit

diff --git "a/\347\231\275\351\273\222" "b/\347\231\275\351\273\222"
index e69de29..f4d9ed8 100644
--- "a/\347\231\275\351\273\222"
+++ "b/\347\231\275\351\273\222"
@@ -0,0 +1 @@
+あああgitって馬鹿だな。


とりあえずgitで日本語(UTF-8)で使ってみたが大丈夫だけど、
ログおよびgit-ls-filesはエスケープ処理される。他はファイル名表示はされるようだが。

>>266
どーい

ソースだけ管理してれば良いけどね
ドキュメントまで管理し始めるとそうはいかない

まあでもSJIS使うのは避けたほうが無難だろう

まあね・・なるべくなら管理したくないんだけどね

つまり、Windowsお断りってことですな

>>264 はファイル名の扱いがコードページ依存 (unicode apiを使ってない)って話じゃないの？
日本語版windowsなら日本語ファイル名でも問題ないし。

別環境でcheckoutしたときにファイル名を適切に扱えるかどうかはそれとは別の問題なわけで

Subversionではファイルパスを内部ではUnicode扱いしてるからうまくいく。
ファイル名をレポジトリの内部管理対象にするときに
ネイティブのパス名からUnicodeに変換してから管理するようにすればいいのに・・・と思う。

合成文字(濁点つきのかな文字とか)が入るとうまくいかないようだ。

Mac OS Xで、
svn add ガチョーン.txt (&commit)

他の環境(Linuxとか)で
svn up
U ガチョーン.txt
touch ガチョーン.txt (作れてしまう)
ls
ガチョーン.txt ガチョーン.txt (「ガ」が同じようで実は違う)
for f in *.txt; do echo -n "$f: "; echo -n $f | wc -c; done
ガチョーン.txt: 22
ガチョーン.txt: 19

svn add ガチョーン.txt (addできてしまう &commit)

Mac OS Xに戻って
svn up
svn: Failed to add file 'ガチョーン.txt': object of the same name already exists

Macのファイルシステム上は合成文字は分解した形に正規化されているが、
そうしない環境のほうが多いよな。

バージョン管理システムを嫌がるアホ
http://pc11.2ch.net/test/read.cgi/software/1198078576/

osxが特殊かと。

>>274
それは、実は大文字小文字混在問題と同じじゃないかなぁ。

GNU archってもう駄目なのかなあGNUウェアではよく使われてるみたいだけど

スレ違いかもしれないけれど…

あるフォルダに対して普段はサブフォルダ作成やファイル削除まで全ての操作を許すけど
いざとなったら任意の時刻のフォルダ状態に戻したいっていうのは
バージョン管理システムを使った運用で可能？
それとももっとスマートなやり方がある？

スレ違いだけど、
Plan9だとそういうのがネイティブで出来そうに見えるんだよね。

スレ違いっぽいけど
fuseとかで簡単に作れたりしないかな

スレ違いなのか…orz

>>279
スレ違いっぽいけど
ttp://fsvs.tigris.org/

スレ違いっぽいけど
>>283 thx

スレ違いっぽいけど、ZFSのスナップショットで戻したい時刻のデータを残しとけばいいような・・・
意識せずにした操作なら駄目だけど。

すれ違いっぽいけど、今日の昼飯なに食った？
俺ちりめんおにぎり1個…

>>279
日単位で巻き戻しならcron+pdumpfs。
任意のタイミングでスナップショットを取りたいならコード弄るしかないかな。

任意のタイミングは駄目なのか

kumaryu.net - (Prog) monotoneを使ってみる
http://www.kumaryu.net/?(Prog)+monotone%A4%F2%BB%C8%A4%C3%A4%C6%A4%DF%A4%EB

*手軽
monotoneのリポジトリは単一ファイルです。
リポジトリはSQLiteのデータベースファイルで、ファイル1つに全部突っ込むことになります。バックアップとかのリポジトリの管理がとても楽です。
また分散型なのでサーバーとか気にせず簡単に試せます。気軽にコミットできます。

*マージが強力
3wayマージで良い感じにマージしてくれます。

*国際化対応
ファイル名、コメント等の国際化対応がされています。
データベースには軒並みUTF-8で入ることになります。

*移植性が高い
SQLite3、Lua、Boostだけあればビルドできます。
どれも移植性が高いです。多分。

これどうかな*国際化対応がされてるという一点に置いて
とても心惹かれるものがあるような…でも余り話題になってないような
もうちょっと調べてみる

SQLiteだとリポジトリがでっかくなったら苦しくならないんだろうか？

>>290
だから人気がないｗｗｗ

> Lua、Boostだけあれば
はいアウト

>>288
pfumpfsの話なら、フォルダを
2007/12/24/
みたいに掘るから
一日に二度以上できないってだけで
2007/12/24_11_17_09
みたいに時間も含めてやれば好きなタイミングでスナップショットを取れるようになるよ。
当然1･2行ソースの修正が必要になるが。

コマンドラインメンドクサス・・・

TortoiseHg安定せんかな・・・
TortoiseSvkでもいいけど

Rakefile書きまくっても、
結局コンソール(Poderosa)立ち上げるのが面倒で、batファイルつくって、
ファイラーから、ポチクリやってしまう

ちゅーか、IDEにターミナルエミュレータついてくれればいいのに・・・

Mercurialは、
バイナリファイルと国際化が弱いようですね。
Subversionはその辺しっかり、してたからなー

あー、あと、空のディレクトリを消すのが解せない・・・

そういえば関係ないけどsvnはdiffの出力も翻訳されちゃうからいつも翻訳無効にしてる
パッチ投げるときに困るんだよね

分散型バージョン管理システムはどれが良い?

http://slashdot.jp/developers/article.pl?sid=08/01/02/2331259

Subversion > Mercurial の移行を考えて
Mercurial使ってるんですが、
Subversionだとhookを使ってできていたコミット通知が欲しいと思って調べています。
対応する操作は、push になるかと思うんですが
push をしたときに、何かをするってのはどうすればいいかアイデアありませんか？

マニュアルに書いてあるのだが……

どうも、最近安易に聞く癖が付いてしまっているようです。
ググレカスり直してみました。
[hooks] の incoming フックで何とかなりそうですね。
ちょっと検索キーワードがまずかったみたいです・・・・
今までマニュアルだと思って見てたのは、チュートリアルだったし。

mercurialについてググろうとしてついhgでググっちまった。

フォーーーーーーーーーー

MercurialにMBCS対応エクステンションがコミットされてたぞ

ファイルやディレクトリのアクセス権を版管理できる
バージョン管理システムは何かあります？
ぐぐってもみつからず。

>>304
そんな超複雑なもん作ってどうする気だｗ

リポジトリ別にしたらいいじゃない

>>305
仕事の政治上の都合が有って
checkout したworking copyの一部のディレクトリを他の
Linux上のログオンユーザに見れないようにしたい。
checkout したあといちいちchmodするのは面倒だし、
し忘れが出るので。reposわけてもこれは解決できんと思います。
subversionにcheckoutのhookがあったらそれでもよかったけど。
やはりないんですかね。

>>306
Linuxのumaskじゃあかんの?

>>304
ないんじゃない? ファイルシステム依存(= 環境依存)な類のものでしょ。
Linuxのアクセス制御と関係するのは、subversionにはsvn:executableしかないかも。

checkout+chmodするスクリプトを作ってお茶を濁すとか。

>>308に一票。

みんなサンクス。

>>307
まるっきりダメじゃないけど、working copy下の他のディレクトリは
関係者に見てもらうことも有るので、umaskで全部マスクするのも
ちょと困る感じです。

>>308, 309
やはり、やるにしてもそれぐらいしかないですね。
あきらめてそうしておきます。

>>310
umaskを変更したユーザアカウントを一つ作っておけばいいんでない?
手間としては>308と変わらなくなる気もするけれど。

Subversionでauthzとか。
ワーキングコピーを共有するなら無理だけど。

よく読んでなかった、ワーキングコピーは共有する前提か。

Linux板行った方がもっといい方法がみつかるかもしれない

ここのスレを大変参考にしつつmercurialの0.9.5を数日試してるんだけど、
過去のレスに補足すべきと思うようなものも見かけるのでかいて美馬s。

>>41,152
名前を変更したファイルのdiffについては、hg diffに--gitオプションをつければ
望み通りにならない? というか、

~/.hgrcに

[diff]
git = True

を加えておいた方がいろいろよさげだと思う。

>>243
そもそもディレクトリを管理しないんだそうだ。

ttp://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-487dc57123d9fcdc96b060d00978b5b8aa527769

自分もsvn add -Nをよくやるので少し不安なんだけど、今考えてみるとディレクトリ
を管理したいことなんてまずないかも。svn add -Nをやる理由ってSubversionの
仕様によるものがほとんどだと思う。

>>315
空のlogディレクトリだけ作られて欲しいこともあるけど（logファイル書けないぜエラーが出る）
まあそういうのはインスコスクリプトなりで対応すべきなんだろうな

> svn add -Nをやる理由ってSubversionの
> 仕様によるものがほとんどだと思う。

それは自分を納得させるための言葉に見える…。
空のディレクトリを管理できるからといって
便利なことはあっても不便なことはない。
ディレクトリもバージョニングできるのが
Subversionの売りのひとつだと思ったけど。
思想の違い。

空のディレクトリに readme.txtを置くだけの簡単な仕事です

>>318 がcoolな解決法だと思う。
シンプルなツールにシンプルな運用。

mercurialで、手元のcloneにいくつかcommitしてあるとして、
そのうち一部はローカルの環境固有の修正なのでpushしたくない、
他はpushしたいというときはどうすればいいのでしょう?

hg push -r REV というのがそれかと思って試してみたのですが、
ローカルで
changeset: 1:cae50e295c29
changeset: 2:af0665dee890
という状態でhg push -r2としたら全部pushされてしまい、
hg push -r1としたら1だけがpushされました。
1のchangesetはpushせず2だけpushしたいのです。

2をexportしてコピー元に送ってimportしてもらい、
その後ローカルでpullとするのでしょうか。

1.pushしたいチェンジセットをexport
2.同じリポジトリを別途clone
3.新たにcloneしたほうで
3-a.exportしたチェンジセットをimport
3-b.おもむろにpush
4.もとのclone側でpull

これでいいのかな。なんか手間だが。

mercurialで不要になったnamed brancheを消したいんだけどどうすればいい？

>>85
> VCSならとりあえずsubversioin。一番普及してるし、IDEのプラグインなんかも多い。
> SCMならgitかmercrial。今流行ってるし、おそらく今後SCMのsubversion的ポジションに着くはずだから。
> どっちも無料なんで、自分で試して決めてくれ。

初歩的な質問ですみませんが、VCSとSCMの違いはなんですか？

VCS(Version Control System)　　　　　 ：バージョン管理システム
SCM(Software Configuration Management)：ソフトウェア構成管理

違いが今ひとつ分かりません。

>>323
VCS→一人用
SCM→まともなバージョン管理システム

>>324の言ってることも間違いじゃないが、>>323の聞きたいことはもっと具体的なことだろ。

違いを一言で言うと、分散型と集中型の違いで、
具体的にどう違うかというと、リポジトリが一つか複数かということ。
VCSは一つのリポジトリにみんなでコミット、マージするけど、
SCMは一人一人がリポジトリを持って、適時リポジトリ間でマージする感じ。

どっちが便利かというと、>>324の言うとおり個人ならVCSで十分だと思う（プラグインもあるし）
グループで開発するとか、ノートPCでネットワークがつながらない場所でもバリバリ開発したいならSCMも有り。
（ただし、svkという手も十分ある）

SCM と VCS ってそんなに意味が明確に定義されている用語?
どちらも意味は同じで、
subversion や git や mercial を含むバージョン管理システムのことを表してない?

>>326
あー、確かに誤解してたかも知れない。
俺の中で、
集中型=VCS
分散型=SCM
だと思ってた。
wikiでもバージョン管理システムの項で分散型も紹介してるし、要は同じってことかも。

Software Configuration Managementは、
リリースサイクルやバグの管理まで含む概念であって、
版管理はその一機能とみなせる。

wikiってどのwikiだよ

pediaしらねーのかよpedia
まったくこいつはとんだゆとりだぜｷﾞｬﾊｰ

>>330
つれますか?

ｐｇｒ

ペギラ

ゴン

Wikipediaをwikiって略す奴は、wikiを知らないんだろうな。

>>328
なるほど。
VCSは版管理のみを提供して、SCMはそれに追加機能があるという訳ですね。
となると、ここで論じられてるCVS、Subversion、Mercurial、git、darcs、Bazaar、arch等々は
それぞれどちらに分類されるのでしょうか？
今までこれらのソフトをVCSの視点でしか見てこなかったので、
この中にSCMがあれば、その活かし方などを教えてもらいたいです。

>>328
何言ってるの？
ここで言ってるSCMはSource Code Managementのことだろｗｗｗ
だれもここでSoftware Configuration Managementの話なんてしてない。

>>337
>>323

というか323の時点で間違ったわけか。

WikipediaではSubversionがSoftware configuration managementに分類されてるな。
なんでだろ
ttp://en.wikipedia.org/wiki/Software_Configuration_Management

不審に思ってPurposesの節を読んだが、やっぱSubversonが入るのは
おかしいかな、ま、Wikipediaは言葉の定義をするとこじゃないから……

……とか思いながら定義を調べたら
http://www.dwheeler.com/essays/scm.html
http://cs.wwc.edu/~aabyan/435/Configuration.html
http://www.cmcrossroads.com/bradapp/acme/scm-defs.html
混用されすぎててワロタ。自信満々の>>337-339が涙目になるくらい。

すまん>>337-339じゃなくて>>328だわな。
要は初期の定義ではCMってのがあって、その後SCMの概念が出てくる。

現在でこそ、定義を全部満たすのがSCMでVCSはその機能の1つっていう
人もいるが、初期のSCMの定義ではCVSはおろかMakeなんかもSCMに含めてて
もうなんなんだという感じ。

そういえば、こんな文章もあったな。
ttp://www.sodan.org/~penny/vc/cvs-ja_1.html#SEC3

そこで、PMS（パッチ管理システム）ですよ。
darcs2はスケーラビリティ改善されるんだろうか。

>>344
darcsは興味あるなぁ
パッチ管理って、もうやりたい放題できそうだな

>>341-343
SCM (Software Configuration Management)の用法は統一されてないようだね
VCSと同義であったり、VCSをさらに多機能化したものとして言及されたり、
文脈によってまちまちみたいだね
ということで、とりあえずこのスレではSCM (Source Code Managementも含めて)もVCSも
バージョン管理システムを指すということでOK？

NMS (Nandemo Management System)

PMSは月経前症候群?
SCMはサプライチェーンマネジメント?
NMSはネットワークマネジメントだな

なます…

GitかHgに移行したいんだが、どうにも勇気が出ない。
TortoiseHgってTortoiseSVNと共存できる？
それとsvnからgitかhgに移行して、どう使い方が変わったとかだれか教えてくりゃれ。

>>350
使い方が変わるわけないだろｗｗｗ

Winの場合、Python3.0が出るまでHgは使いにくいと思う

>>352
何で？

HgってPythonせいだっけ

今のPython2.5は文字列型が2つある。
入出力の部分で文字コード変換すれば問題は無いんだが、
1バイト圏の連中はASCII前提で何もしないから困る。

Python2.5
 str型: 1バイト1文字
 unicode型: 多バイト1文字（UCS-2 or UCS-4）
Python3.0
 str型: 多バイト1文字（UCS-2 or UCS-4）

UTF-8なら今のものでも問題ないと思う。
でもWindowsはShiftJISだから日本語を使うと問題が出るときがある。

Python3.0になるとUnicodeで作ることを強制されるので
たぶん自然に改善されるはず。

>>355
期待ageだな
でも、枯れるまでにはもう少し時間が必要か

Pythonがマジで多カ国語対応されるまでは、
Mercurialはファイル名、ファイルパスはASCIIで使っておけということだな。

これではダメかな?
http://selenic.com/repo/hg/rev/02884e56c217

ちょっと試した限りでは問題ない感じ。

ユニコードファイル名に対応しないと根本的な解決にはならないんじゃないかな

マジレスすると
Pythonは多各語滞欧しているし海栗コードファイル名にも対応している

しかしお前は日本語に対応してないんだな

pythonは対応してるけどhgは対応してない

>>358
バイナリインストールの環境だと使えない

Windowsだけど、Hgインストールすると、
Python入ってるのに、自前でPythonインストールされる気がする。

>>357
そっかー、Pythonの文字列の問題なのか。
悩ましい問題だ。

SVNはその点、楽だったのになあ

>>357
対応してるだろ
適当なことを言うな

>>366
俺としては、基本的な文字列操作をしたらUnicodeで扱うことになったら、という意味だった。
Javaレベルでネイティブロケールを隠蔽してロジックが書ければ、と。

# そりゃ、Unicodeで扱うことによる問題はでるけどさ。
# デフォルトがUnicodeになって欲しい、と。

u'hoge' でいいじゃん

git-svnよいねぇ。
svnで開発するのは無理自慰だし、svkなんか微妙だし(エラーハンドリングが微妙)、git使いやすいから楽だ。

>>364
だがそれがいい。
VBはDLLを要求しやがるから困る。

>>368
その記法はPython3000だとエラーなんだよな〜
これに限らず、いまhgを完全にUnicode化しても、
新たに作業が発生しそうで躊躇する。

Mercurial vs git
ここ分かりやすいな　短いけど
ttp://www.atmarkit.co.jp/flinux/rensai/watch2005/watch06a.html

>>371
2005っていつの記事だよ、と思ったらやっぱり三年前じゃねえか。
こんなの今と相当違ってるぞ？

>>372
メインはsvnだけど　気になる２人なので基本的な情報を集めようとしてるんだけど
やっぱりそうですか。
すんません

>>369
> git-svn
kwsk

手元でgitで、サーバー側のsvnにコミットする手法？

TortoiseHg 0.3 が出たな

>>374
まぁそういうこと。コミットもできるけど、まだしてない。(権限がなす)
BTSにパッチ上げる開発用にローカルでつかってる。
普段のそー言うのは、git-svn cloneのほうでブッコ抜き。
git-svnimportの方はログコンバーターなのでリポジトリをgitに移行するときだけですね。

ブランチをマージしようとしてsvn mergeがフリーズしたので、
代わりにgit-svn で git上でマージできてよかった。

だけど、svn:externals とかgit-svnは扱ってくれないのね。
svn:ignoreはgit-svnで一応扱えるけど、機能が微妙。

【10.1】 「日本語ファイル名を追加できない」
http://python.matrix.jp/modules/mercurial.html

・既出
・ググればすぐ出る
・直リン

直リン？

燃料?
ttp://texagon.blogspot.com/2008/02/use-mercurial-you-git.html

お前初めてかhgは?
力抜けよ

>>381
文章の先頭から大嘘じゃないかｗｗｗ

>>383
ごめん，どこが？

subversion での svn update は、git では git pull でしょうか。
git clone したリポジトリがあって、これを更新したいんだけど、git pull だけでいいのでしょうか。
なんかうまくいってるのかどうか分からなくて。

>>385
それで合ってる
git branch -r でorigin（pullしてくる元）が表示されるはず

git スレッド
http://pc11.2ch.net/test/read.cgi/linux/1197798039/

>>303
使い方がよくわからないんですが、Mercurialを新しくするだけではだめなんでしょうか?

$ hg add
adding クソ.txt
ク・.txt does not exist!

みたいになってしまいます。

sjisファイルネームは通らない。

SVN(TortoiseSVN)だとその辺もやってくれるんだけど、Hgはやってくれないか

>>387
extentionを有効にしてなかったせいでした。
Mercurial.iniの[extensions]に

hgext.win32mbcs =

を足したらちゃんとaddできるようになりました。

はじめて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 はちゃんと編集後の状態を保ってる。

これって正しい動作なんでしょうか。

rms曰く、we should use Bzr
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01212.html

mercurial で、heads と tips の違いがわかりません。だれかおしえて。

>>393
http://www.selenic.com/mercurial/wiki/index.cgi/JapaneseUnderstandingMercurial#head-deea4b2f231c79413f121f4838f789da83fdfd36

>>394
ありがとう。とりあえず、tip は heads のうちのひとつ、ということまではわかった。
でも、なんで head が複数できるのかわからない。head は子を持たない changeset ということだが、普通に作業してたら head はひとつしかないように思うんだが。

>>395
複数人が編集したらheadが増える

>>396
ひとつのリポジトリを複数人で編集・・・するわけはないか。
>>394のページを見ると、他のリポジトリからhg pull したらheadが増えるみたいなんだが、そういう理解であってますか？

つまり
>>396
>複数人が編集したらheadが増える
というのは、他人のリポジトリから hg pull したら head が増えるということを意味してますか、という質問です。

>>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 は増える。

TortoiseHGをインストールすると、Sambaの共有フォルダ一覧が
表示されるのがかなり遅くなってしまいました。
Wiresharkでキャプチャしてみると、\\Samba\.hgなるものを
何度もチェックしているからのようでした。
アンインストールすると元通りの速度になったのですが、この現象を
回避する方法はないのでしょうか？

TortoiseSVNには、アイコンオーバーレイのネットワークドライブなどでの除外指定ができるけど、
HGはできないの？

/var/logも.hgで埋まるから困る

バージョン管理システム管理下のファイルだけを対象にできる「auto-save-buffers-enhanced.el」
http://d.hatena.ne.jp/antipop/20080222/1203688543

＞HGはできないの？

出来る、ドキュメント嫁。

>>403
バージョン管理下以外のファイルには自動保存したくないっていう
状況がよく分からないんだけど、なんでだろうね。

auto-save-buffers に慣れきったから自動保存されないことが
怖くてしょうがない。

>>405
間違って更新されたら元に戻せなくなる可能性があるからじゃない？

xyzzy使いだけど、おれは自動でバックアップファイルを作るのを使っているな。
ただし、セーブしたらバックアップファイルが消えるっていうやつ。
もし落ちても問題なし

GitTorrent Protocol -- GTP/0.1
http://gittorrent.utsl.gen.nz/rfc.html

http://gihyo.jp/magazine/SD/archive/2008/200804
git の特集だそうです。

なんか最近Gitが盛り上がってるなあ。

俺的にはTortoiseGitが無いのが糞だな
ところでTortoiseVSSって無いのかな？

最近はBazaarがgitとmercurialのいいとこ取りをしてますよーと、結構ドキュメント書いてるなぁ。
ちなみにgitのメインメンテナって日本人っぽいよね?(ハマノさん?)
俺的にはqgitがもうちょい使いやすくなれば嬉しいんだが、最近あんまアクティブでないよな…。

>>411
ないだろうし、これからも作られんだろ。
基本的に有償のソフトウェアには有償のサードパーティ・ソフトウェアしかでない。

>>413
> 基本的に有償のソフトウェアには有償のサードパーティ・ソフトウェアしかでない。

その理論（理解）はおかしい。

Tortoiseほにゃららはどうでもいいんだが
Cygwin環境でのgitの挙動があれで自分はmercurial

いちいち .git/hooks を弄らなきゃいけないのは苦痛だ

>>412
よければその記事どこにあるか教えてくれ。

しかしまあ、CVS->Subversionと来て次のスタンダードはどこになるんだろうな？
GitとMercurialに決定的な差異がない以上、ハッキリと明暗分かれることは当分ないんだろうが・・・。
ブルーレイvsHD DVDみたくどっちかが撤退という訳にも行かんし、
環境ごとにGit使ったりMercurial使ったりするのは勘弁してほしいなあ。

svn, git, hg のリポジトリを透過的に扱える、クライアント専用の第三のツールが出て一人勝ちに一票

>>418
スゲー欲しい。
ここは言い出しっぺの法則で作ってくだされ！
しかもWindows用にヨロｗ

たぶんEmacsにならすでに有りそうな気がする。

Emacs だと vc とか DVC とかかねぇ。

>>418
サーバとクライアントって、分散SCMを否定してるなｗ
あるいは、IETFあたりで、分散SCMプロトコルのRFCとか決めて、なんでも繋がるようにしたら面白いかも。


ところで、Darcs2はどうなってる？

別に否定ではないだろ
親と子の関係はあるんだから

>>422
＞IETFあたりで、分散SCMプロトコルのRFCとか決めて
「インターネット」が関係ないがな！ｗ

TortoiseSVNだけを各々のPCにインストールして
TortoiseSVNでリポジトリを共有サーバに作る
そのリポジトリと各々のTortoiseSVNで使うって使い方は問題ない？

本来ならサーバにSubversionをインストールしてうんぬんかんぬんって
やらないとダメだと思うんだけど
ちょっと今の環境だと難しいんで上記の方法でやろうかなぁと

Windowsの場合、Subversionは管理ツールだと思え
必須って訳じゃない
その代わり、file:///でやることになるし、ユーザ名が
Windowsのユーザ名になるし、いくつか制限が出てくる
単純なソース管理しかしないならそれでも十分

>>426
おお素早い回答ありがとうございます。

単純なソース管理しかしないのでTortoiseSVNだけでOKってことですね
一先ず運用してみます。

Windowsで、一人ないしは少人数で扱うバージョン管理システムなら
Subversion(TortoiseSVN)が現状、最良且つ唯一の選択肢だろうな。
それ以上のことをやろうとするから、いろいろ悩むわけだ。

1人ならHgの方が手軽じゃない？
っつっても、Ｔｏｒｔｏｉｓｅがまだまだだからなぁ。

すまんですが、普通のバージョン管理システムで一万個ぐらいのファイルを最初にリポジトリに登録しようと思ったら、どのぐらい時間かかるもの？
VSSだと3時間かかっても終わらん･･･orz

PCのスペック、各ファイルの容量によって全然変わるし一慨にこうだとは言えない気がするが
うちが管理してたやつは30分もかからずに終わった
（Subversion管理）

上の方でgit-svnが話題になってたが、同じように既存のCVSリポジトリとやりとりできるやつある？
git-cvsexportcommit　ってのでいいんだろうか。しかし日本語の情報とかさっぱりないな。
別にgitじゃなくてもいいんだが。

mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/UpcomingReleaseNotes
そろそろ来るのかな？

http://www.atmarkit.co.jp/flinux/rensai/watch2008/watch01a.html
これは駄目だろ

TortoiseHg 0.3 を入れてみた。
日本語ファイルの追加や削除もマウス操作でうまくいったよ！

実験に使ったファイル名： ソース表示.txt

やったことは、インストールした場所にある Mercrial.ini の
[extensions]
hgext.win32mbcs = !
の感嘆符（!）を削除しただけ。

ファイル選択やコミットの画面で日本語ファイル名が化けるけど、そのまま動くよ。
コメントは入力・表示ともに日本語でOKだった。

↑すまん、環境は WinXP SP2。書き忘れた。

そりゃ動くだろうけど、ほとんどの機能が結局ダイアログが出てきてコマンド入力だったような。

>>434
1.5.4rc1で起こってたんだな。知らなかった。
教えてくれてありがとう。アンチも役に立つんだな。

>>437
・現在の Mercuriel の hg はファイル名とコメントに日本語が入っているとエラー停止する
・TortoiseHG 3.0 に付属の hg なら日本語ファイル名が扱える（mbcs エクステンションが入っている）
という事前情報があり、hg（コマンドライン）目当てで TortoiseHG を入れたところ、予期せず GUI でも日本語ファイル名の追加・コミットができたので、報告の意味で書き込んでみました。

ああ、そういえばSDのgit特集、今日発売か

SD読んだよ。クオリティ高かった。
かなり硬派な内容で、バリバリ使ってる人でも面白く読めると思う。

ネットの情報で十分でした

gitもhgもやりたいやりたいとは思うんだが、TortoiseSVNになれた身では移行しづらい。
やっぱフロントエンドが充実するにはもうすこし時間が必要かなあ。

必要ならお前が作れよ

gitはファイル名とログの日本語対応に不安がありすぎるんだが。

>>445
問題ない。

SD読んだよ

>>445
俺もふつうに日本語使えてるけど

SVNすら着いて来てくれないのにgitとか無理だお・・・

>>449
いつかgit使える日が来るさ。

mercurial-1.0.tar.gz 24-Mar-2008

コミットログを英語で書く人のためによさげな記事みつけてきた

Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
http://d.hatena.ne.jp/pyopyopyo/20070920/p1

>>451
釣りかと思ったらマジだったのでage

今日のパッケージアップデートで知ったけど、x264がgitに移った模様。

>>454
ん〜、なんだか大規模プロジェクトはMercurialよりGitに移る傾向があるみたいだね。
Mercurial使ってる有名なオープンソースとかあったっけ？

mozillaとかsun回りとかいろいろ。

TortoiseGit 作って （はーと）

TortoiseSVNの右クリックで表示されるメニューなんだけど
---
SVN更新
SVNコミット
TortoiseSVN
---
の3つなんだけど、ココに「変更のチェック」を加えて
---
変更のチェック
SVN更新
SVNコミット
TortoiseSVN
---
にしたいんだけど方法ないですかね？

TortoiseSVN > Settings で Look and Feel

>>459
それだとTortoiseSVNの下のメニューを変えるだけです＞＜；
トップのメニューを変える方法は無いのかな

>>460
俺は459じゃないけど、説明良く見てないだろ
チェックを外せばトップメニューに表示されるんだよ

>>457
みんなTortoiseに依存しまくってるんだな．．．．
SDによるとWindowsの場合CygwinでGit使えるみたいだけど、
GUIじゃないと嫌なの？

>>460-461
本当だ！ごめんなさい、ありがとうございます。

自分しか使わないならそれで良いんじゃないの
普通の人が触りやすい形態を考えれば分かる事だろ

>>462
ここに書き込みするような人たちほど　リテラシーがないんですよ。
使い勝手によいＧＵＩがあれば、バージョン管理システムの導入も
してもらいやすい。
「コマンドベースでやってね」　なんて言ったら、誰にも使ってもらえないだろう。

直感的に変更点判るし、ツールとして良くできているしね

差分見るのはGUIじゃなきゃやだ

ファイラーはどう考えてもGUIのほうが便利だしなあ

gitの場合、中身がシェルスクリプトだからTortoiseはちょっと難しそうだな、
と素人目に思った。

>>467
そうか?

>>464-465
Gitは開発者全員Gitにしないとダメなんてことないよ。
中央をsvnリポジトリにして自分だけGitでも問題なし。俺はそうしてる。
HGは使ったことないから分からないけど、Gitから分かれたモノだから
同じような感じではないかな？

>>466
CUIでもキレイに差分見れるけどね、、、

>>455
逆

>>457
Git Cheetah

Mercurial で リポジトリの一部を消すとか、リポジトリを分割するとかってできますか？
やりたいことは Subversion でいえば
svnadmin dump | svndumpfilter | svnadmin load
のようなことなのですが…。

Bazaarバージョンが上がってすごい事になってるみたい
http://bazaar-vcs.org/BzrWhy

Bazaar vs Git　http://bazaar-vcs.org/BzrVsGit
Bazaar vs Mercurial　http://bazaar-vcs.org/BzrVsHg
Benchmarks 　http://bazaar-vcs.org/Benchmarks

昔と比べて恐ろしいくらい速くなってる。

へー、bzr速くなったのか。まー、あまり速さは求めてない。
設定ファイルと自作スクリプトの管理にしか使ってないけど。

不思議なのは、bzrってbazaarの後継？らしいんだけど、
使い勝手が全然違ってどこが後継なのか良く分からない。

hgよりも便利機能が多い（UTF-8ファイル名でおｋ）けど
なぜか、hgの方が情報が多い。

あたりが疑問点かな。

>>475
昔Mercurialにうんこと言われるぐらい遅かったからだろ。

BazaarNGが本家乗っ取ったんだっけ？

>>477
急に速くなってたから驚いたけど
そういう理由があったのか

適当なことを言う前に http://bazaar-vcs.org/HistoryOfBazaar でも読んどけ。

Bazaar。。。。名前がいまいちなのがなぁ・・・・

Bizarreよりは普通だと思う

>>480
ゴザールを作るんだ

”ファイルのディレクトリ構造”ごと登録して、
その後、バージョン管理システム外で変更された、
”ファイルのディレクトリ構造(多少のファイルの増減あり)”を
チェックアウトなしで、そのままチェックインできるツールって、ありますか？

開発拠点が国内と、海外に数ヶ所と、
バージョン管理システムの導入を徹底できないので、困っております。

Subversion

svn_load_dir とかいうスクリプトがあったな。
他のツールにそういうのは無いのかな？

>>483
質問の内容に合っているかわかりませんが、Mercurialでリポジトリのあるところにファイルを展開して
hg addremove
hg commit
をすると、増えたファイルをリポジトリに追加、なくなったファイルをリポジトリから削除してくれます。

話題が途切れたので、ちょいと Mercurial を使った感想を…。

CVS → Subversion と集中リポジトリのリビジョン管理ツールを使ってきましたが、
Mercurial を使ってからというもの、
「サッとリポジトリが作れる」というのがとても気持ちよく、気に入っています。

ローカルの作業ディレクトリは、すぐに hg でリポジトリ化し
修正やコミットをかけた後、完成したらリポジトリ部だけ削除してます。

「作業ディレクトリにリポジトリがくっついている」という発想は
とても便利で面白いと思います。

続きです。

いままでしばらく Subversion＋svk を使っていましたが、
いまでは Subversion＋Mercurial という構成で使っています。

Subversion＋svk のときは、svk で自分の手元に持ってきてから
ローカルで開発し、結果を svk smerge で一括送信していましたが、
今は Subversion でチェックアウトした内容をそのまま Mercurial に突っ込み、
Mercurial でさんざん修正・コミットした後、
最後に Subversion でコミットしています。

開発中に Subversion のリポジトリ上に修正が入っていた場合には、
Mercurial のブランチとして取り込んで、Mercurial 上でマージしています。

この方法だと svk みたいに自動化されていませんが、
構成がすっきりして全体の見通しがよく、作業がひとつひとつ理解できるので
安心感があります。

Subversion + Mercurial　って
それいいな、俺もやってみるか

>>488
昔、CVS+Teamwareで俺がやってたのと同じ感じかな・・・と思ったけど逆だ・・・
俺のときは、Teamware側が共用できるやつでCVSがローカル環境・・・・
なんでそんな事したのか思い出した・・・eclipse対応してるかどうかだ・・・

MercurialならMercurialだけでIDE含めて完結できるのが一番楽なんだろうけどねぇ・・・

>>488
熱いレポート乙！
参考にさせてもらいます。

GitHubって招待制なの？
だれか invite してくれ

>>492
そんなのあるんだね、知らなかった
とりあえずsignupしてみたけど、いつになるやら
SourceForgeもGitサポートすればいいのになぁ

>>488
ちなみに hgsvn を使用しているのですか？

どこをどう読んだらそうなるんだ

>>492
なんか知らんがinviteされた（たぶん中の人？）
メアド晒してくれればinviteするよ

>>494
hgsvn は使っていません。
いまは Subversion でエクスポート
→ .svn 以外をそのまま新規に Mercurial 管理下に入れる（手作業）
という感じです。

Subversion に戻すときは、Subversion のリポジトリをチェックして
更新されていなかったら、そのまま Subversion でコミット。
更新されていたら、Mercurial のブランチとして取り込んでマージしてから
Subversion でコミット、です。
すべて手作業です。

Git と Mercurial の比較ってだれかやってません？

>>498
つ http://www.opensolaris.org/os/community/tools/scm/history/
OpenSolaris が Mercurialを選ぶときに行ったレビュー。
粒度が揃っているとは言えないがまあ参考に。（下の方にあります）

http://weblog.rubyonrails.com/2008/4/2/rails-is-moving-from-svn-to-git
まー政治的にpythonは選べないだろうなw

>>500
でもTrac使ってるぜ。

railsではbtsは難しいということですか、分かりません＞＜

いまならredmineとかretrospectivaとかに移行してもよさそうなものなのにね>rails

データの引っ越しの手間が馬鹿にならないとか?

>>500
Ruby界隈はMatzが使っているという理由でGit一択です

matzって基本的にオールドタイプだから新しめの道具は使ったことなさそうなイメージ。
cvsからsvnに切り替えるのもかなりもたついてたような。

>>506
svnに切り替えるときに、ローカルでの管理用としてgitを導入した。
http://www.rubyist.net/~matz/20060919.html

StGITは、git導入したというのだろうか。

StGITローカルパッチ管理に使ってるが便利だ。
でもドキュメント少ないな
>>507 の記事とかチュートリアルの翻訳くらいしか日本語の記事が無いので
公式見てもチュートリアルの元記事しかなかった…。

StGITは「git使ってることを意識しなくて済むツール」なのではなかろうか。

当時はgitって本当にバックエンド用のplumbingコマンドしかなかったからね。
今でこそフロントエンド用のporcelainコマンドも充実してるけど。

>>501-504
BTS も rails 製の Lighthouse に移行するよ。

って >>500 に書いてあるじゃん。読まずに脊髄反射してんだなｗ

Rubyが好きじゃない俺はどうすればいいですか？

>>512
自己暗示

>>512
ブール代数的に言うと、好きじゃないということは、嫌いじゃないかもしれない。道は残ってるね。

>>512
安心しろ、Joel Spolsky も Ruby が嫌いみたいだから。
ttp://www.joelonsoftware.com/items/2006/09/01.html

っと、これだけだとスレと関係なくなってしまうので。
… Python に走って Mercurial 使えば？

>>512
言語の好き嫌いがある内は只の厨房だと自覚するべきだと思うよ。
自分の得意不得意のせいであんまり好きになれない言語があるのはしょうがないとおもうし、結構あるしorz

>>497
詳細な説明＆レポートとても助かります。

TortoiseSVN で管理している svnワーキングコピーに、
なんの疑問もいだかずに TortoiseHG で真剣に管理しようとしていた俺は・・・

韓国語が嫌いだ

>>514
ブール代数的なら「好きじゃない」イコール「嫌い」だろ。
3値で「好きじゃない」なら「嫌い」か「興味ない」。

>>512の突っ込みどころは、Ruby好きじゃないのにrails使うのかよってところじゃないのか

うむ。直観主義論理だな

で、Railsとバージョン管理システムの関係は？(スレ原理主義的に)

TortoiseHg 0.4 age！
ttp://sourceforge.net/project/showfiles.php?group_id=199155

0.4　RC版だった
スマソ

>>523
おぉ、やっと、新しい版が。
sambaの共有フォルダへのアクセスが遅くなる件、確認してみよう。

Mercurial 神だな。
なんだ　このお手軽さは！　すんばらし〜

マーキュリアルってuにアクセントあるのか

>>527
本当だ、u にアクセントがある。
ttp://dictionary.goo.ne.jp/search.php?kind=ej&kwassist=1&mode=0&ej.x=1&ej.y=1&MT=Mercurial

「マーキュロ」に似た感じで発音すればいいのかな。

メルクリアルだとばっかり

Mercurial って、バイナリファイルの保管は効率的でないの？
まぁ svn でも過剰な期待をしているわけではないんですが。

マテリアルと同じ感じでマキュリアルかな。

>>530
自分の経験では、
MS Access の MDB ファイル(300KB)を修正しながら
6回チェックインしてリポジトリのサイズが 200KB くらいです。

元ファイルより小さいってことは、初期バージョンを
圧縮して格納しているのでしょうか？

git 使ってみたけどリビジョンがないのが面倒に思えた。
実際に使ってる人は不便に感じない？

>>533
リビジョンの使い道ってどんな時があるでしょうか？

headやhead^,head~2しか使ったこと無いので…

533じゃないけど、バージョン番号に入れたとき長いと人が覚えきれないとかw

Mercurial を単独で使い始めてみました。
JapaneseTutorialや、有益なサイトの説明を読んでもみました。

お手軽さはぴかいちですね。
ちょこっと修正履歴を残しておきたい場合など、本当にあっという間に環境が整いますね。

まだまだ使い込みが足りませんが、分散システム故の運用の難しさを感じています。
・本流はどれだろう？
・現時点の最新はどこ？
・自分は今どの位置にいるの？
etc・・・

やっぱり中央リポジトリみたいなものは用意されるんでしょうか？
こまめにマージとかもされてるんでしょうか？
ん〜

>>533
> git 使ってみたけどリビジョンがないのが面倒に思えた。
> 実際に使ってる人は不便に感じない？
うはｗ　俺といっしょｗ
俺もGit使い始めの頃に同じ質問をしたら「リビジョンがあったら何が嬉しいの？」って言われたｗ
たぶん使ってるうちに必要ないなと思うようになると思うよ。
実際気軽にフォークできるから、あんま意味がなくなっちゃうんだよね、番号は。
プロジェクトの公開リポジトリなら自動で番号振っても良いような気もするけど、
まあタグで事足りるんだよなぁ。
どちらかというと「番号が年上かどうか」で知りたかったことは「いま見ているブランチに
どのコミットが含まれている（いない）か」のほうが重要だから、git show-branchを
俺は多用しています。

Subversion 使ってて、まっすぐ増えてくリビジョン番号が無いと困りそうなんだが、
要らなくなるもんなのか？

たとえばこんなの。
・バグレポートがいつの時点のものなのか？
・バグ修正がリポジトリ内のどの時点で行われたのか？
・テストを実行しているのはどの時点の実行ファイルなのか？
全部リビジョン番号で示してれば、以前に報告したバグが今回のテストで
修正確認できるかどうか、すぐにわかるんだが。

svn使ってるけど、その手の管理でrev番号を必要とした記憶が無い

rev XXXXで・・・って表現の仕方はよくするかな

>>538
リリースするときバージョンつけないの？

短い番号ってのは自分が把握するのにも人に伝えるのにもわかりやすくて便利だと思う
200804101426みたいなタイムスタンプでもいいけど
何かの暗号みたいなハッシュはちょっととっつきにくい感じ･･･

>>541
つけないね。開発と同じフロアにテストする人が居て、少なくとも日に一回ってペースで
実行ファイル更新するから、毎回つけるとなるとちょっと面倒。

それに、リリースにバージョンつけても、そのバージョンで特定のバグが直ってるかどうか
すぐに（リビジョン番号の大小ぐらい簡単に）判別はできないんじゃない？

それって、その日解決されたレポート番号一覧を出せばいいんじゃないの？
というか、テストチームに対して、dailyで実行ファイルを更新するという環境が想像できないのだが・・・

普通は、「この問題は、（マイルストーン名｜タグ名）で解決される」って感じで、
BTSに登録するんじゃないの？

bugtraq:*使ってないだろ？

つーか、BTS使ってないんじゃね？

>>543
リビジョン番号を見てバグが直ってるかどうか判別できるって事のほうがすごいと思うんだが。
毎日テストチームにバイナリリリースするってことはけっこう変更がたて込んでるってことだよね。
俺はSubversionも使ってるけど、リビジョン番号聞いて「あーそれ古い」なんて言えない。
コミットされる度にインクリメントされる番号なんて憶えてられないし印象にも残らない。。。
リリースしてるならバージョンが付くはずだし、その時には変更履歴が付くからそれで分かる、
リリースしてないなら、リビジョン番号があろうと無かろうとログを見て判断するしかないと思う。

というか、テスターが勝手にcoなりexportなりして、修正されたバグがないかどうか
調べて、あればそれをテストする、という混沌とした現場なんじゃ。

テストチーム（個人？）って、そのときfixされたバグだけを確認してるわけじゃなくて、
リグレッションテストもするはずだから、頻繁にリリースされても困ると思うけど

いわゆる「リリース」じゃないんだよ、きっと

リグレッションテストなんて　ここぞ！　という時以外あまりやらないな・・・
細かなバグ対処リリースでは無視無視

運用方法に依るんだけどね・・・

プログラマならともかく、テスターがリグレッションテストやらないのは問題だろ・・・

リビジョン番号の代わりにタグをうつ事をするようにしたら
修正の順番が分かるようになると思う。

今まで番号でやってきたのが変だった、ということか？

>>536
> ・本流はどれだろう？
Mercurial では、すべてのリポジトリが対等で本流です。
…が、どれかを本流にし、全ユーザーがそこから clone すれば
中央リポジトリ的な使い方ができます。

> ・現時点の最新はどこ？
リビジョンに「tip」と表示されるのが、そのリポジトリでの最新です。
hg tip で表示できます。
ブランチが複数あった場合には、それぞれの最新が head と呼ばれ、
hg heads で表示できます。
わからなくなったら hg glog をすると、わかりやすく（？）表示されます。

> ・自分は今どの位置にいるの？
上の hg glog のほか、hg stat -v でリビジョンが表示されます。
hg parents で、現在のワーキングディレクトリの元リビジョンが表示されます。

リビジョン番号は前後関係がわかるのでよい。
ハッシュは長すぎて覚えられないし。
monotoneのマニュアルには、補完できるように
シェル弄れみたいなことが書いてあったが、
そんなのめんどくせえよ、と思った。
darcsは半分ズレがあるので却下。
bzrが一番よい。-1とか分かりやすいしシンプル。

>>537
リリースサイクルが長い開発で使用するとなると公開（メイン）リポジトリでは
定期的にタグを打たないと駄目そうかな

まだ個人使用だし考えていてもしゃあないのでまず使ってみる

>>556
＞ハッシュは長すぎて覚えられないし。
先頭 4 文字から絞ってくれるよ。 4 文字だと重複する可能性は少し高いだろうけど

http://www.moongift.jp/2008/04/git_gui/

Git の GUI ツールが紹介されてた

うわ。なんかダメな子みたいになってる。
何か重要な概念が欠けてるのかもしれないけど、いちおう返答してみる。

>>544
一覧を「出せばいい」じゃなくて、「出さないといけない」ってことにならない？
めんどくさくね？

リビジョン番号で示してればそれは要らないんだ。少なくともそう思ってる。
修正するときは「rXXXX で修正」で、テスト用の実行ファイルを更新するときに
「rXXXX でビルドしたもの」って伝えれば済む。未確認のバグのうち、テスト中の
リビジョン番号より小さい番号で修正を入れた問題の動作を確認してもらう。

>>548
たとえば r100 のテストで見つかった２つの問題に対してそれぞれ r105 と r108 で
修正を入れたとして、次のテストが r107 で行われた場合は前者だけ動作確認して
もらえるってことがわかる。

いやだから、テスターに「bugid 78,80を修正したから」って伝えれば済むんじゃねってことなんだが。
テスターがリポジトリの更新履歴でも見て、何が修正されたかいちいち調べるのか？

>>560
「rXXXX で修正」って BTS に書き込む（そのときにメールも飛ぶ）から、
いちいち別でまとめてバグ ID 伝えたり、リポジトリ見て調べたりしなくていい。

>>559
BTS使ってる？
使ってるなら、何使ってる？
プログラマは何人くらいいるの？
テスターは何人くらいいるの？

分散vcsだと結構ブランチが気軽に作れちゃう分リビジョンだと混乱しそう。
いいとこ取りのbzrはその辺どうやって解決してるの?
ユーザー間のチェンジセットとかも考慮できるようだが今のところ興味よりもﾏﾝﾄﾞｸｾが勝る。
中央リポジトリばかりで開発するようなスタイルだとそこにリビジョンはあってよいと思う。

>>561
だったら、BTSのステータスが「修正済み（未確認）」のものをテストすればいいわけで、
リビジョン番号はおろか、タグも必要ないよね？

>>559
そこまで理解してくれるテスターがいる事に嫉妬。
こっちはマにリビジョンxxxで〜って言って、
「リビジョンって分からないんですけど？」って後で質問が来る世界だ・・・orz

まさかとは思うが、ひょっとして、ビルド済みバイナリをテストチームに渡したりしてないよな？

つーか、根本的に破たんしてる気がする。
ひょっとすると、プログラマ一人、テスター一人で、デバッグレベルのテストをやってもらってるのだろうか。
それなら頻繁なテスト依頼が行われるというのも理解できる。

>>564
>559 の最後の例では、 r108 で修正したバグのステータスは「修正済み」になるけど、
r107 をテストしてるときにそいつの動作確認はまだできないと区別できる。

よそで自分の意に沿わない運用がなされたとしても、それがなんだと言うんだろう？
そこではリビジョンさえあればうまくいってると言ってるんだから、外野がごちゃごちゃ
言う必要無いよ。
何がしたいの？やりこめたいの？

悪いけどテスト環境について議論するつもりはないから、リビジョン番号の有用性に
関すること意外はスルーさせてもらうよ。

「リビジョン番号の無いバージョン管理システムでも、こういうテスト体制なら問題ない」
と紹介してくれるんなら歓迎。

何で上から目線なんだ

>>570
だーかーらー、解決されたbugid一覧をテスターに渡せばいいじゃんか。
やりたくないの？

>>572 もちろん。めんどくさいじゃないか。リビジョン番号さえあれば済むんだから。

じゃぁ、svnに戻せよ。
アホか

BTSに、修正リビジョンを書くことが、なんで破綻してるとかって話になるんだ？
いつ何を修正したか記録するのは当然だと思うんだが…。

>>575
いや、破綻してると思ったのは、開発プロセス全体がってことで、BTSに修正した
リビジョンを書くのは問題ない。
プロセスに関しては議論したくないみたいだから、俺は消える。

>>572
もしかして、リビジョン番号の無いバージョン管理システムでは
リポジトリ内のある時点からある時点までの間に「解決されたbugid一覧」を
作るための機能がついてるの？

そうじゃなけりゃ >572 の言い方は、リビジョン番号がなくなると（538的な意味で）
不便になる点があるってのを言ってくれてることになる。

575書いたあとに570とか読んでちょっと馬鹿馬鹿しくなった（´・ω・｀）

>>570
リビジョンのないVCSなら素直にタグ打てば済む話だと思う。
分散VCSの性質上、連続したリビジョンが付けられないのは当然だろう。

>>577
だーかーらー、タグ使うか、おまえが一覧作れって。
タグ打つのもいやで、svnでうまく回ってるなら、svnでいいだろうが。
お前は一体何がしたいんだ。

仮に今回挙げたテスト体制をリビジョン番号の無いシステムに移すとすれば、
テストするバージョンにタグをちゃんと打つこと、タグ間で修正されたバグの一覧は
別で作成すること、が必要になるってことだね。

ひととおり納得したよ。ありがとう。

570 の書き込みは、正直スマンカッタよ。

なぁ、各VCSのcook book的なものを一通り読んでから議論しても遅くなかったぞ。

これはひどい

ゆとりに構ってスレの無駄使いは止めましょう

コミットログちゃんと書けば済む話ジャネーノと思った

>>557で＞まだ個人使用だし考えていてもしゃあないのでまず使ってみる
って書いてるしそれでいいんじゃないかと思うけどね。うまく説明できないのは少し残念だが。
俺も最初番号が無いのに戸惑ったけど、使ってるうちにリビジョン番号は必要ないなって
思うようになった。

538には必要なんだよ

Subversionのリビジョン番号は、その時点のリポジトリ全体の状態を決定するけど、
gitやMercurialのハッシュ値はそのチェンジセットを表してるだけなんだな。
この辺の考え方の違いに気づくまでわかりづらかった。

全体で一貫したリビジョン番号である svn は、リリース時のバージョン�ｕt与する時に便利だったんだよね
V1.0.2553 とか　３番目をリビジョン番号使ってたんだけど、
Mercurial を使ったとしても、各リポジトリでリビジョン番号は合ってないから無理だな・・・
ハッシュ値は付けられんし・・・、ちょっと考えないといけないな。

>>588
つ[日付]

適材適所で Subversion 使えばいいじゃん。
ただしリビジョン番号に依存した運用は、
dump → restore したときに番号が変わると破綻する。

ほんとタグ付けのが嫌いなやつが多いな。
それとも、そんなに頻繁にリリースるのが流行ってるのか？
一週間に一回なら、手動でリリースタグ打ってもたいしたことないだろ。
デイリーなら日付入りな。
それ以上頻繁なリリースなら・・・知るか。

自分はリリースごとにタグ打ってるけど、
それぞれ好きでいいんじゃないだろうか。

いや、多分集中レポジトリ使ってると
タグうつ権限とかも運用上集中管理してて大変だというイメージがあるんじゃなかろうか？

やっぱ、運用がごろっと変わると大変なんだろうけど
その辺りの共通認識がここで話をしてる人の間でないから話が食い違うんだろう。

いままで CVS をひたすら使ってて、Subversion に移行しつつあったけど、
Mercurial というのを知って、こちらに本格的に移行することにしました。
あとは、Xcode が Mercurial に対応してくれたらなぁ。

>>470
kwsk!!

メインがsvnでも、自分のとこ？（というかクライアントマシン？）だけ
分散型でいけるの？
参考になるページとかないですかね

>>591
それこそ、svnならタグ付ってメッチャ早かったとおもうけどｎ・・・

>>595
詳しくないけど答えてみる。

svnリポジトリからcoした作業コピーを、ローカルでgitみたいな別のツールで管理する
ことはできるんじゃないか？

svn co ほげ
git init
git add .
git commit -a

編集

以下、リモートとやりとりするときはsvn、ローカルではgitと、使い分ければいいような。

以上、妄想でした。

>>595-596
git-svn を使うって話じゃないの?

>>595
>>597の言うようにgit-svnでやってますえ。
中央のSubversionリポジトリとローカルのGitリポジトリをマージしながら
使うようなイメージ。
けれど中央をsvnしてるぶん、つねにsvnにくっついていかないといけないのが
ちょい面倒に感じるけど、まあ仕方ないかな。

>>596
そんなやり方でも出来そう！って思ったけど、svn upした時に上書きされて泣いたりとか
しそうだな。。。git-svnならsvn upの代わりにrebaseを使うので、いい感じです。

hgsvnにバグがある

aというディレクトリがあって、その中にfoo.txtっていうファイルがある。
aをbという名前でコピーしてコミット。
b/foo.txtをsvn rmで削除して、a/foo.txtをbの下にコピーしてコミット。

こうやって作ったsubversionのリポジトリからhgimportsvnとhgpullsvnを使うと
a/foo.txtが削除された状態(hg stで?が付く)になってしまう

ちなみに、開発者にはメールで報告済みだが、連絡・修正はない

Mercurial のマージの概念がよくわかりません

同じリポジトリ内の複数リビジョンの間でしかマージできない？
それとも､過去に hg clone して派生したリポジトリ間でしかマージできない？

同一リポジトリ内の tip リビジョンのファイルとコミット前のファイルのマージはできないのでしょうか？
そのとき、ファイル名は指定できませんか？

ファイル構成がほとんど同じだが過去に hg clone では派生していない 2 つのリポジトリ間ではマージできないのでしょうか？
例えば､ディレクトリコピーなどで複製され、それぞれのディレクトリで 1 回目の hg commit を実行した場合など

>>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

続く。

続き。

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.

続く。

続き。

ブランチをマージする。
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
でいける。

>>602

サンプル付きでありがとー
今度試してみます

じゃあ、ファイル中の一部分を差分比較対象から除くことはできますか？
例えば、RCS/CVS/Subversion のキーワード置換 ($Revision とか) みたいな
内容が異なる可能性があるけど、差分としては検出して欲しくない部分

そういえば、Subversion でもキーワード置換以外に
ファイル内の一部分を差分比較対象から除く方法を知らない…

>>605
KeywordExtension というのがあります。
「どのファイルの」「どんなキーワードを」「何にする」というのを指定できます。
http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension

リポジトリ中のファイルにはキーワードが未展開で（$Id$ とか）格納され、
ワーキングディレクトリに取り出すと展開型（$Id: hoge.txt 2008/04/24 moge$ とか）に
なります。

>>605
実際にやってみたので、ちょっと長いけど貼ってみる。

まず、リポジトリ repo1 を作成する。
>hg init repo1
>cd repo1

ここで以下の内容で repo1\.hg\hgrc というファイルを作成する。
*.txt でキーワード展開せよ、という指示をしている。

[extensions]
hgext.keyword=

[keyword]
*.txt=

[keywordmaps]

キーワードは最後の [keywordmaps] の後に書き込む。
$Id$ は書かなくてもキーワード登録されているので、
今回はそれを使用する。

続く。

続き。

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 $
テスト。
追加。

続く。

続き。

変更は 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 $
テスト。
追加。

続く。

続き。

前のリビジョンとの差分を取ってみる。やはりキーワードは無視されている。
>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
すいません。
結論は >>607 に書いたつもりでした。

>>612
だめな講評の典型的な例だな
まず本文を読め

そういうのいいから

MercurialHgでpushするときの方法を書き留めておくテスト
*** http authorization required
http://user:[email protected]

Mercurial使いたい……
けどHaskellerだからdarcsなんだ。

言語に括っても良い事無いよ

tracとhg使ってる理由

>>617
HaskellerがdarcsではなくMercurialを使いたい理由を詳しく

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.

こうなってしまうんですがどうすればいいんでしょうか？

darcsに興味をもっていろいろ読んでみたけど，darcsでは1つのリポジトリに複数のブランチを作れないんだね。
ブランチを作りたかったら，新たにリポジトリを作りなさいとある。
1リポジトリ，1ブランチということらしい。
http://wiki.darcs.net/DarcsWiki/BestPractices

マージ機能が強力そうだからそれで問題ないのかもしれないが，
管理が面倒そうだな。

Mercurialのような分散リポジトリでは、作業ディレクトリ
自体が既にリポジトリなわけで、そうするとそれはどんどん
肥大化してしまうのでしょうか？めちゃくちゃ過去の変更
に関してはどっかのリポジトリにあってくれれば良いので、
自分の手元には最近のリビジョンに関する情報だけ
あってくれれば十分なんですが･･

バカはうだうだ言うよりまず使ってみた方が良いよ
バカな質問してるのが良く分かるから

>>624の方が馬鹿っぽい

バカバカ言い合う事に何の意味があろうか。

>>623
HGはよく分からないけど、GitだとたまにGCして圧縮したり、
同じファイルシステムにある同じようなリポジトリ（クローン元とか）は
ハードリンク使ったりとかしてるね。
分散リポジトリという仕組み自体、裕福なリソースが無いと実現出来なかったものだと
俺は思ってるんで、あまり気にしなくて良いような気もするけど。
KDEまるごとクローンしたりするとかなり大変らしいが。

mercurial-1.0.1.tar.gz

WinXPでtortoiseSVN使い始めたですが、
svn+sshなのでコミットするたびにパスワードを入力するのが面倒です。
かといって、SSHクライアント指定してplinkにユーザ、パスワードをベタ書きしたくないので
Roboformみたいに一度マスターパスワードを入力すれば、リポジトリURLをキーとして
ログインパスワードを入力してくれるツールがあるといいなと
思ったのですが、tortoiseSVNで使えそうなツールないですか？

>>629
ssh-agent

putty では pageant.exe だった

win上でhg使ってたら、リポジトリが壊れてがっかりした。
ファイル名の大文字小文字の問題なんだけど

>>632
げげっ　そうなんだ・・・
お手軽なので重宝してたんだけど、やっぱりもう少し待った方がいいのか？

それは、ファイルシステムの問題だろ。
大文字小文字を区別しないと同一名になるファイルを管理してる奴は、
Windows上で使っちゃ駄目。

FSの問題ではあるけど、壊れる操作を行えてしまうのはどーかな

大文字小文字を区別する環境に依存した物を
大文字小文字を区別しない環境に持っていく奴の脳みそが
どーかなだよまったく

すでに、Abcd.cが管理下にあるのに、
うっかり、hg add abcd.cしてコミットしたら、
たぶんおしまい。今手元にwindowsがないので、確認できないけど。

>>636
hgって大文字小文字を区別する環境に依存してるの？
pythonで書かれてるとか聞いたんで、環境依存は凄く小さいかと思ってた。

pythonがcase sensitiveだから。
というかcase insensitiveな言語は、ほとんど見ないが。
そういう意味では、Windows はかなり特殊な環境だというのを自覚しないといけないな。
NTFSがcase sensitiveなのに、Windows OSが insensitiveなのは最悪。

>>590
svndumpでバックアップ取ってんだけど、
バックアップから戻したらリビジョン番号変わっちゃうの？？

↓これTortoiseSVNのマニュアルなんだけど、文字化けして見えるのはウチだけ？
ttp://nchc.dl.sourceforge.net/sourceforge/tortoisesvn/TortoiseSVN-1.4.8-ja.pdf

ちょっと前にあった、リビジョン番号の議論の結論は、
「やっぱりリビジョン番号便利」と言うことか。

まあ当たり前だよな。
自動で全順序性が保証された識別名が得られるのが便利でないはずがない。

>>641
化けてるな。

>>639
今は亡きキルドールに文句言って下さい。
Windowsの変な仕様のかなりの部分はCP/Mから来てます。

　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　｜
　　　　　／V＼　　　　 　 　,Ｊ>>642
　　　　/◎;;;,;,,,,ヽ
　＿　ﾑ::::(;;ﾟДﾟ)::| ｼﾞｰ
ヽﾂ.（ﾉ::::::::::.:::::.:..|）
　 ヾソ:::::::::::::::::.:ﾉ
　　 ｀ ー U'"U'

>>644
何時まで過去に縛られてるんだよってな話だ。
OS/2みたいに、FSをcase insensitiveにする選択肢もあったハズだし。

過去の資産との互換性を最優先に、それこそ必死になって守ったからこそ
今のシェアがあるんだから

俺はファイルシステムはcase insensitiveの方がいいと思っている。

>>646
emx 使ってたときに区別したような記憶があるけど気のせい？？？

CR/LF も地味に面倒くさい

>>648
俺には西洋人の感覚は分からんが、CaseInsensitiveってことは、

おはよう
オハヨウ
おはヨう
オハよう
を同一に扱うってことにあたるんじゃないか？
おはよう、オハヨウはいいとして、他のはどうよ、と思う。

名前ってのは、分かりやすさの為に付けてるんだからそれはないと思う。
ただ、検索インターフェース的にInsensitiveに探すのは付いていてもいいと思う。
名前の格納自体はSensitiveが良いんじゃない？

んでもって、>>638
確かに環境依存は少ないよ。
だけど、この場合、hgはどう扱えば良いと思う？こういう環境にはチェックアウトさせない？
つまりWindowsをサポート対象外にする？Pythonでもどうしようもないと思うな。
全てのファイルを別ディレクトリに分けるとか言う格納ポリシーでないと上手く行かない。

>>651
俺がいいと思っているのは、今のWindowsの仕様そのもの。
格納自体はSensitiveだが、インターフェース的にInsensitiveな状態。
ABCとabcを同じディレクトリに作れないように規制するということ。

ABCとabcが同じとこにあったら分かり難いので、そういうファイルは
作らないでくださいと運用ルールで規制するよりも、最初から作れない
方がいい。

>>630-631
できました！感謝。
pageantの存在は知ってたけど何に使うのか見ただけではさっぱりでした。

手順は↓を参考にしました。
http://www.naney.org/diki/dk/Pageant.html

そして ~/.ssh/authorized_keysというディレクトリにpubkeyを書いたファイルを置くものと勘違いしてハマってました・・・

>>641
それ、どこでビルドしたんだろう?
何とかがんばってビルドしてみるかな……

>>654
PDF作った人はちゃんと読めてたんだろうから謎だよね…

すまん勘違いした。TSVNプロジェクトのところのやつね。
何が原因かはわからないけど化けてしまう。
手元でビルドすると化けないって感じ。
ビルドできたらアップしてみる。

しおりの文字は文字化けしてないね。

>>651
させない、が正解じゃないか。
Windowsでチェックアウトすることがあるなら、同じディレクトリにそういうファイル名を混ぜないようにすればいい。

>>657
たしか、本文はフォント埋め込みなんだけど、しおりはそうじゃなかったような気がする。
本家のビルドマシンは当然日本語Windowsじゃないんで、
ms932への変換とかそのあたりで不整合があるのかも。
他にもchmのしおりが化けてたりする。

とりあえず、手元でビルドできたみたいなんで、
http://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
のversion1.4.xのところから持って行ってください。

>>658
運用で制限するのは利用者の自由。
ただtoolで制限させる必要は無いし、制限しない以上問題は起こり得る。
8.3のショートネームの環境でも問題出ないように、名前を先頭8文字が同一
のものは認めないなんてバカげてる。

いやいや問題のでる環境でやろうとしたときに、ってこと

そのOSに対応を謳ってる以上、リポジトリ壊すってのはやはりバグだろう。
その前にエラーで止まってくれれば運用でいくらでも対策できるわけで

>>659
ちゃんと読めるようになってます。お世話になります。

>>639
この場合言語そのものがcase sensitiveかは全然関係ないだろ

hg で複数の（連続した）チェンジセットを
1つのチェンジセットにまとめて伝播させる事ってできないかな？

要はいろいろ試行錯誤した残骸をみせずに
最終的な結果だけ伝播させたいんだけど・・・

>>665
http://www.selenic.com/mercurial/wiki/index.cgi/ConcatenatingChangesets

>>28
いや、Haskellのメモリ効率が悪いのは事実だが、
それよりも遅延評価をうまく使っていないdarcsの実装の方が悪い。
俺ならメモリを節約できるアルゴリズムが書ける。

>>667
じゃあいっちょ、よろしく頼む。hgに勝てるように！

>>659
ありがとう〜
PDF中でテキスト検索できなのが残念だけど使わせていただきます ^^

>>634
それはそうだけど、
svn(TortoiseSVN)はちゃんと解決してるよね？
Windowsおいてきぼりはちょっといただけないなあ

>>639
hgの実装言語の言語仕様とファイルシステムの関連性がわからない・・・

大文字と小文字を区別するメリットがわからんな

>>671
；と：を区別するのにAとaを区別しない方がおかしいと思わないか

>>670
SVN でも多少あるみたいよ。「SVN 大文字小文字」でググれば分かる。

>>670
Windowsのせいでみんなが迷惑してるんだからWindows村八分したいところだぜ

反抗期のガキが作ったシステムが変更できずに今までズルズルときてる訳だからな・・・

反抗期のガキのような物言いはよして、前向きに話そうよ。

具体的に CaseInsensitive じゃないと困る場合ってなんでしょう？
単一の単語のCaseをわざわざ区別したがるメジャーなケースって makefile 問題くらいしか知らないです。
とすると、651の例えは微妙に適切じゃなくて、むしろ単語境界をケチるために CamelCase 濫用して区別できなくなるような
ケースくらいじゃないのかな。

・もはやPCユーザ＝プログラマとはいえない
・PCで扱う範囲は増えているので、データファイルの名前に日常言語使いたいと思うのは当然
　MBCS, UTF だけじゃなくて CP 違いの依存文字も含め。

CamelCase 濫用して検索難しくしちゃうなんてファイルシステムや VCS 抜きでももう起こってしまう問題なので、
Sensitive じゃないと駄目！って制約自体が、過去のシステムを変更できずにズルズルきてるだけの気がする。

てことで、652 の主張に同意。

っつーか、ここプログラム板だろ？
当該部分がどうか知らんけど、ほとんど Python スクリプトなんだから
簡単に直せるんじゃね？

>>652のような仕様はシステム的に実装するんじゃなくて、もっとハイレベルで実装すべき。
たとえばファイルマネージャレベルで実装すべき。

Macのファイルシステムも昔のは
たしか大文字と小文字の区別に関する問題無かったっけ？

>>678
それって最悪の仕様だと思うが。
ローレベルな機能使って制限を無視して作られたファイルには
ファイルマネージャ経由ではアクセスできなくなったりするぞ。

アクセス不可能なファイルの作成を許容しているシステムって
トラブルの元にしかならんと思うが。

エクスプローラーがドットで始まるファイル名を作らせてくれなくて困る。
既にあるドットで始まるファイルも名前変更でF2を押したらもう戻れない。最悪。

>>679
いまもデフォルトは区別なし

区別ありにもできるけど、Civilization IVが区別なしを期待してる
コーディングだった(全部大文字でファイルパスが埋めてあった)ので
再フォーマットしたぜorz

>>680
> ファイルマネージャ経由ではアクセスできなくなったりするぞ。
そんなファイルマネージャがあるんですか？

>>681
まー、ドットで始まるファイルは名前を付けて保存で ".emacs" みたく " で
括る必要があるのはメンドイよね。

>>680
そのファイルマネージャの仕様的な問題だと思いますが。

>>681,684
エクスプローラーからしてみたら、なんで他のOSの仕様に
配慮しなきゃいけないんだよってとこだろうw

>>686
ほかのOSの仕様だからじゃなくて、美しくない仕様のOSなのが問題なんだよ。
一貫性の欠如。Windowsは所詮は反抗期のガキが作ったOS。

>>686
そもそも、エクスプローラーのそういう挙動の根幹には拡張子を特別扱いするというWindows古来からの伝統を継いでいるだけだろ？

はっきり言わせてもらうと、Windowsの方がおかしいんだよ。
自分オリジナルということを主張したいがために"わざと"Unixとは違う、くだらない仕様で売り出したんだからな。
Windowsを作った豚野郎はとっとと糞の中で溺れて死ねばいい

そしてくだらないマーケティングと小奇麗なパッケージで素人をだまして糞を蔓延させた罪は万死に値する

おまいら、 NTFS の話と エクスプローラの挙動の話を
ごっちゃにして「Windowsは〜」って言ってない？

>>688
もしかしてパス区切りがバックスラッシュなのもそういう理由だったりするの?

まちがった。>>689宛。

>>692
DOSのときにunixが/だから\にしたという説を聞いたことがあるぞよ

>>692
DOSのパス区切りが\なのは、CP/Mとの互換のため。
CP/Mはスイッチキャラクタが/だったので、パス区切り
として/が使えなかった。

DOS 3.1位まではスイッチキャラクタの変更が可能で、
パス区切り文字を/に変更できた。

>>695
CP/Mに階層ディレクトリなんてあったか？
パスが無いんだから、区切り文字も無い。

誰か言うと思って放っておいたけど、誰も言わないので俺が言う。

さすがにもうスレ違いだろ。

696の読解力の低さにワラタ

×CP/Mのスイッチキャラクタが/
○Microsoftコマンドのスイッチキャラクタが/

699が何を言いたいのか全然わからない。
>>695には
・DOSがCP/M互換にスイッチキャラクタを設定した(1.x)
・DOSにディレクトリの概念が取り入れられたとき(2.x)、既に/は用途が決まっていた
と書いてあるように見えるが、
それだと>>699のような訂正は不要、というか理解できないとしたら頭悪すぎ。

>>697が言いたいことが全然分からない(ヤツが多い)

CP/Mではslashは特別な意味を持たない。
MicrosoftのCP/M用basic等のswitch charactorがslashなのは、VMSの影響。
CP/MとMS-DOSではコマンド体系が全く異なる。これもVMSの影響を強く受けたからで
互換性は考慮されてない。

このスレでのWindowsの扱いが、このスレのmac並みでワロタ
開発者が使うノートPCてなに？ 2台目
http://pc11.2ch.net/test/read.cgi/prog/1203399213/

CP/Mでバージョン管理してる奴は他行け

最近、Pythonのpsycoって、知ったんですが
Mercurialでこいつを使うようにはできないですかね？

別に速度にさして不満があるわけでもないんですが・・・

>>705
適当なモジュールの先頭に
import psyco; psyco.full()
どれだけ早くなるかは知らん

commands.py の頭に突っ込んだら、遅くなっちゃって・・・
やっぱ、psycoの初期化のコストの方が大きいのかなぁ、と。・・・

Windowsの大文字小文字といえば…
今FreeBSDのソースをWindowsで見たくてチェックアウトしたら、
CONって名前のファイルがあってエラーで止まってしまう
困ったもんだ

時期尚早感はありますが、Mercurial いじり始めました。
これってバイナリファイルの管理はどうなんでしょう？
できるんでしょうか？

いや，尚早じゃないし．
すでに乗り遅れてる．
時代は今・・・・

成熟しないまま時代遅れ！？
専用スレも立たないみたいだし、気にかけなくていいかな？

デレツン乙

釣られてみよう

>>711
そうじゃなくて、>>710 は
　　Mercurialは尚早じゃなくて旬を迎えていますよ、
　　尚早と思っているあなたは時代に乗り遅れてますよ、すぐにでも試してみては？
という事を言っているんじゃ。

ごく最近のニュースも見ていない？
ttp://journal.mycom.co.jp/news/2008/06/05/032/index.html

>>709
バイナリファイルもOKです。
効率に関しては、確かgitとかの比較があったような・・・？
忘れたのでググり直した。
http://joshcarter.com/productivity/svn_hg_git_for_home_directory
これだったかな・・・？
まぁ、取り立てて良くもなく悪くもなくだったような気が・・・

>>714
darcsとも比較してほしかったな。
このテストなら、糞SCMであることが証明されるはず。

>>713
まあ、ちょっと釣り目的もなかったと言えばウソだが、
まだまだコマンドが変更されてたりして安定してるとは言い難いのでは？
まだバリバリ CVS を使ってる私の感覚では、Subversion も…いや、
Subversion よりは Mercurial かな。
なんだかんだでクライアントは Windows を使わざるをえない状況で、
Windows での使い勝手をもう少し頑張ってほしいところ。
大手プロジェクト(？)が Mercurial に移行している記事は見たことあります。
うそォな感じでした。

>>714
わざわざどうも。拝見させていただきます。

でもなんだかんだで CVS からの移行先として有力視していますので、
ぼちぼちやっていきます。

むー TortoiseHg が CVS 管理なのが変な感じ。

>>713
ちょいスレチだが、最近のニュース：
ttp://www.freebsd.org/news/newsflash.html#event20080603:01

正直、ぶったまげた。

>>718
( ﾟдﾟ)ﾎﾟｶｰﾝ

FreeBSDはCVSからSubversionに移行って。
OS系はgitって勝手に思ってたけど違うんだな。

ところで、gitやhgは日本語をちゃんと扱えるようになったのかね？

>>720
git-svnでだけど普通に日本語ファイル名で管理できてるけど、なんかおかしいところあるの？

gitは名前が好かん。

む、妙なレス番が残ってた……

事情があってhgとsvnで二重管理したいんだけど、
hg add -X .svn .
とかやっても、
svnの管理ファイルが登録されちゃうんだけど、どうしたらいいでしょう？

>>724
.hgignore ファイルを作り、その中に
syntax: glob
.svn
と書いておくのはどう？

>>715
darcsはSCMではない、パッチベース開発基盤だ。
このスレでも順序性など糞、みたいな話が出てたが、darcsはさらにその上を行ってる。
単なるSCMとは世界もレベルも違うんだよ。…とか言ってみる。

>>725
できました！ありがとうございます。

>>726
ユーザーにとっては中でどんな処理をしているかなんてどうでもいいんですよ。
気にするの速さと容量と安定性。

と知名度と実績と値段

>>728
中の処理が (ある程度) 分かってないと、安定性とかが分からなくて
不安になるのが普通。

「どうでもいい」と言いきれるその感覚がある意味うらやましい。

>>714
ホームディレクトリの管理用途では
hg > git >> svn
って結論みたいだね。ソース管理はどうなんだろ。

上の方でhgに日本語ファイル名で問題あるとかいってるけど
まだその問題存在してるの？

>>726
> darcsはSCMではない、パッチベース開発基盤だ。
> このスレでも順序性など糞、みたいな話が出てたが、darcsはさらにその上を行ってる。

でもさ，darcsがパッチベースって言っても，どれだけの人がその特徴を活かしきれているのか疑問。
例えば，パッチベースだからパッチの順序を入れ替えることができるんだぜって言われても，
そんな機能使わねーよって人がほとんどだと思う。

俺は割り切って，darcsをリビジョン管理システムとして使ってる。
darcs changeで問題なくヒストリーが表示されるし，そういう使い方をしていて今のところ不満はない。
あと，darcsのマージ機能がなかなか良いんだけど，確かにこれはパッチベースのおかげかもね。
それ以外の順序性云々はお釣りみたいなもので，とりたてて喧伝する機能ではないと思う。

ソ噂浬欺圭構蚕十申貼能表暴予

>>707
ずっと動くコマンドじゃないと意味ないね。

SVN とか hg って、ネット越しに公開するために Web インターフェイス使うようだけど、
そのためだけにデータサーバーに Apache 入れるの？
なんか CVS からの移行先として決定打がないねぇ。
運用を根本から見直せばいいんだろうけど。

>>736
Apache入れなくても
CVSと同じように使えるよ

>>736
ん？http でアクセスしたけりゃそうだけど，
ローカルで使うなら svnserve があるし，
WAN ごしに使うにあたってそれじゃ不安というなら
ssh 経由で使えるし．

なんと、SVN の方はへちょいサーバープログラムがついてるのは読みましたが、
hg の方はどうすればいいんでしょう。Web 用の CGI がいくつかあるのは見えたんですが。
…と思って $ hg clone --help してみたら、ssh 関連の記述が出ましたね。
user@host:/path の形式でいいのかな？

なんでこんな所に釣り師がやってくるのかが理解できない。

hg serve

スミマセン、大真面目なんですが…。まじめに調べました。

ssh://user@host//path

なんですね。
ここまではわかったのですが、アクセスしたいサーバーが
クライアント → ルーター(PC) → hg サーバー
となっている場合はどうすればいいのでしょうか。
ルーターに hg をインストールするのは極力避けたいのですが。
CVS の場合は、.ssh/config で LocalForward 2401 CVS サーバー:2401
を指定しています。

>>741
ありがとうございます。できることなら上記のように SSH でやりたいと思います。

apache入れるのを嫌ってる奴が多いけど、何で？
大した手間じゃないだろ。

>>743
apacheって複雑なんだもん
いろんな設定項目があって、そんなに機能はいらねーよ。
設定ファイルが5行程度ならいいんだけどね。

>>743
自分で触れない事があるからでは？

それに、それだけの為に入れるには無駄という感じ・・・

超適当な私の場合、
1. Subversion を個人的に使い始めた (file:///なローカルリポジトリ)
2. 複数のPCでSubversion、んーと、Apache やってみますか (commitするuserの見分けがつくんだ、へー)
3. ついでに ViewVC (おお、何かカッコイイ)
4. Trac とな？ おー！(ますますカッコイイ)
5. RedMine？ すげー
6. オンラインでない時どうしよう、、、SVK 万歳！
色々世界が広がりました。

とりあえずDISる
↓
少し釣れる
↓
ツンデレ教えて君

こうするとggrksと言われないんですねわかります

Subversionは、TortoiseSVNにしてもAPR(apache portable runtime)に依存してるから
Apache入れなくても半分くらいはインストールしてるんだよね。
ただ実行ファイルを入れるのは気持ち悪いとか、APRを二重でインストールしたくない
という気持ちは判らなくもない。

>>743
必要ないから。

まぁ、そもそも、Subversionの必要パッケージも多すぎると言う話もある。
CVSに比べ劣化している点だね。

そこはほとんどの場合問題にならないだろ。

>>743
データ用サーバーに余計なもの入れたくないから。

>>750
既存のもので使えるものはそれを使う、というのが Subversion コミュニティの考え方みたいだな。
でもそんな考えでやられちゃ、せっかくの最小構成が台無しになる。かといって Subversion の
サーバー機能はほぼ使い物にならないレベル。

だったら自分で作って貢献しろ

使わねーよ。

>>752
何が言いたいの？
愚痴をこぼすだけで何も行動しないんだったら、はっきり言ってうざいだけの存在なんですけど。
問題点を指摘するならそんな主観的な表現じゃダメだよｗ

ssh はダメなの?

吠えてんのは Subversion 使いか？
愚痴だけのレスなんてほかにもあるだろ。

Subversion はいいかげん Barkley DB への対応を捨ててはどうか．

Mercurial でなんでコマンドが hg なのかと思ったら、もしかして水銀のこと？

フォー

>>758
Ｇｏｏｇｌｅ版のＳｕｂｖｅｒｓｉｏｎはＢｉｇｔａｂｌｅをつかってんだよ。

リポジトリの分散というか効率的なミラーリングに対応したSCMはありませんでしょうか？
今は、TortoiseSVN使っているんですが、基本リポジトリ一個だけですよね？

どっかネットワーク越しにリモートにバックアップしておきたいのですが
まるごとバックアップだとかなりでかいくなりそうで・・・
300MBくらいのリポジトリのプロジェクトを見たら1個のファイルで60MBくらいのものもありました。

この辺、何かよい解決策はありますでしょうか？

>今は、TortoiseSVN使っているんですが、基本リポジトリ一個だけですよね？
こんな発言する時点で辞めておいた方が良いと思うが
まずSVKから入れば

>>762
mercurialつかっとけ

>>762
リモートに特に利用制限がないなら、rsync 使って cron で定期的にミラーリングするとか。

>>759
お、今日授業でやったのかい？
>>761
Googleはperforce
http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/
>>762
zfsのsnapshot&send&receiveがとても便利。
でもまああまり使える環境ないだろうから、mercurial+clone+pull*でどうかと。
一番導入負荷が、少ないからね。
で、レポジトリのファイル自体はPythonつながりでPydumpfsとかでバックアップ。

>>766
> Googleはperforce
知らないことを聞いたら否定するんじゃなくて、
なぜ自分の知識と一致しないのか確認すべきだよ。
google codeで使われてるんだよ。

>>767
んが、そういうことか。
まあ、Googleのサービスの後ろはだいたいBigTableだもんな。

書いた後で検索したら >>12 に書いてありましたね…。orz

>>766
> お、今日授業でやったのかい？

元素記号の授業なぞ受けたのはかれこれ20年前だな(やばい、歳がバレる)。
今でも最初の20個なら覚えてるような気がする。

Mercurial感動した。
TortoiseHgはかなり使いにくい＆ブランチがわかりくいので
早く改良してくれないかなーと淡い期待

Tortoiseシリーズは間違った使い方しそうでこわい。
普通にコンソールでやったほうがいいと思う。

NetBeansってMercurial標準サポートしてるのな
ローカルにリポジトリあると手軽さが違うなー

なんか、俺はsvnの基本がわかってなさそうです orz

・svnの別の使い方
・svk
・mercurial
・cronでrsync
ありがとうございました。いろいろ試してみようと思います。

個人用のインストール楽なバージョン管理システムないかな。
リポジトリもSqliteみたく組み込みデータベース使うようなやつ。
つまり、フロントエンドのGUIとバックエンドのデータベース管理システムが
単一のEXEみたいな。

>>770
Mercurial ってブランチ作れるんだっけ？

使いにくいのは英語だからじゃなくて？
GUI で設定する前に先行して INI ファイルで設定しておかないといけないのは
不便だねえ。今後の改良に期待したいところ。

複数プラットホームでの連携を頑張ってほしいところ。
ファイル名はともかく、ファイルの中身まで日本語の扱いが難しいとなると
少しきびしい。

Greenbear Laboratory - SVKを使ってみよう
http://mono.kmc.gr.jp/~yhara/w/?SvkTutorial

SVKをレポジトリミラーシステムとして使うノウハウ
http://dkiroku.com/2005-08-24-5.html

いくつかサイト見てましたが、
ミラーリングに関してはsvkでできそうです。
手がかりになりました。ありがとうございました。

>>774
WindowsならTortoiseSVN楽ですよ。
ローカルのリポジトリも作れるし。インスコして設定するだけですぐに使えて、完結する

>>776
>WindowsならTortoiseSVN楽ですよ。
>ローカルのリポジトリも作れるし。インスコして設定するだけですぐに使えて、完結する
ありがとうございます。ちょっと調べてみます。

>>774
個人でちょっとファイルを取っとくときはRCS使ってる
リポジトリとか関係なく取っておける

PeggyProっていうWindowsのエディタ(統合環境)を使ってて
そいつがRCS,CVS,VSSと統合されてるので便利

Mercurial って、先頭 1KB に 0 があるかどうかでバイナリファイルを識別してるみたいだけど、
add した時点ではたまたま 0 がなかったけど、管理はバイナリ扱いにして欲しいとかいう場合は
どうすればいいの？そもそもそういう情報は持ってない？

>>779
> 先頭 1KB に 0 があるかどうか
Mercurialってそうなってるんだ・・・
もっと良い方法ってあるのかな？

>>780
diffでも使ってる方法らしいし、
http://www.selenic.com/mercurial/wiki/index.cgi/BinaryFiles

とりあえずいい方法はない、と結論して割り切っているようだ。
あと、binaryだとdetectされたとき、abortする処理があるらしい。
別にNUL文字があっても動くライブラリならいいんじゃないかね？
manとか見ても単に表示上の問題を気にしているようだし・・・

>>780
ヘッダー解析

>>782
独自規格のバイナリだったら？

>>780
俺は旧来のように、必要ならユーザーに指定させるのがいいと思うけど。

>>783
利用者が定義すればいい

>>775
作れるよ
というかブランチがあってさらに分散なところが強みだと思ってる。

で、TortoiseHgが使いにくい理由は、メニューとhg xxxのｘｘｘが一致してないから

pullしてupdateするために、Syncronizeを選んでからPullして
下に出てくるUpdate to tipをクリックしたり
今のブランチがどこか確認するのに、ViewChangeLogでChangeSet覚えてから
Update to RevisionでUpdateしたりと
コマンドラインならすんなりいくところがメニュー何回も開かないといけなくてめんどくさい
一度ウィンドウ開いたらそこで全部解決してくれるとうれしいんだけどね

日本語対応については、プロジェクトを全部WideCharで作り直すのが一番早いと
日本人は思うんだけどねー。
むしろオープンソースなんだから、日本語対応版Exportしろってことか

mercurial派が多いようだから、一応gitを持ち上げておくかw
Windows上でのSCMについて検討を重ねてきたが、結論はgitになった
いろいろ特殊事情が絡むので万人に勧められないが・・・

当方普段UNIX使いなので、WindowでもCygwinで過ごす場合が多い
CygwinをUTF8 dllで使ってると、localeの問題は、ほぼ全て解決する。
変えた所は、PAGERをlvにした位。gitkも問題無い。
不満なのは、他の環境と比べて Cygwin 上のgitが遅いこ%

なんとなく、
・Mercurial - 使いやすい
・Git - 多機能
って印象だな。

>>787
それMercuralのサイトでも言及してるね＞Cygwin 上のgitが遅い

原因はなんなんだろう。git自体のパフォーマンスは悪くないんだから、移植したヤツがミスったとしか・・・。

git公式サイトでもwindows版はいろいろ書いてありますね。
使ってみようと思ったけど、かなり不安になるよｗ

cygwinはファイルがらみはおそいな
statとか

>>790
gitにファイルシステムに依存する部分があって、その部分がperlで置き換え
られてるからじゃないかな？

エミュレーションしているから仕方ないけど、随分遅いね。

誰か、>>742 Help...
一段階の SSH でのアクセスはありますが、ルーター(PC)越しにアクセスする
いい方法が思いつかない…。ルータ　PC は、今後ディスクを CF に変更して
もっと小さくする予定なんで、リポジトリ置くにはちょっと…。

ネットワーク内に帰った時に push すればいい、そのための分散リポジトリだとは思いますが、
念のため遠隔からアクセスできるようにしておきたいと思います。

現段階の Mercurial では Windown アプリの管理は厳しそうですね。
まずは日本語使えないことが多いハードウェア関連の設計に使っていこうかな。

>>795
外からhg serverが見えるようにrouterにport forwardさせる。
sshなら22 httpなら80 httpsなら443をrouterの適当なportに割り付ける。
外からはrouterのそのportに対してアクセスする。
routerの中と外でシームレスに運用するには、DNS proxyを用意しないといけないので、
今は手を出さないほうが無難。

なんでルーターの設定方法なんて基本事項をこのスレで説明しないといけないんだ？ｗ
帰れnoob

>>795
SSHでポート転送するとか


■WindowsユーザのためのSSHポートフォワード
http://www.fuji-climb.org/pf/JP/

■CygwinによるWindows環境でのSSHサーバ構築手順
http://www.uhero.info/techinfo/CygwinSSH_setup/
http://kinshachi.ddo.jp/blog/comp/archives/000290.html

>>795 ssh://user@localhost:2401//path de ii n ja ne?

レスありがとうございます。
はじめに >>797
ルーターの設定というか、Marcurial 特有の方法があるのか聞きたかったのです。
やはりポート転送しかないようですね。

ちなみに、
>>796
> routerの中と外でシームレスに運用するには、DNS proxyを用意しないといけないので、
> 今は手を出さないほうが無難。

POSTROUTING の設定で内外シームレスに DDNS のドメイン名でアクセスというのは
Web サーバーでやったんですが、これの応用ではダメでしょうかね。

>>799
なぜ pserver のポートに…？

とりあえず今度は iptables と格闘します…。

ルーターは関係ないだろ、女子高生

>>801
女子高生！
ぜひぼくと結婚してください。

>>802
10年後にはおはばんです。

svn update --revision {20080613}

男の子スイッチと乙女コードは永遠らしいよ

svn+ssh でアクセスした時に実行されるコマンドがsvnserve -tにハードコード
されてるとこ、修正される予定はないのかね。

なにか問題でも?

ClearCaseは今まで使った中で一番使いにくい

TortoiseHg 使ったけど
Samba 経由で .hg を含んだ大量のファイルがあるディレクトリを見ると
エクスプローラが固まってひどいことになるね

>809
Tortoise は SVN, Hg 併用組だけど、
ファイル増えるとアイコンオーバレイ切らないとローカルでも十分重い。
切ってみれば？

TortoiseHg ではマージできんのかえ？コマンドがディセーブルになっとるが…。
しょうがないからコマンドラインでやってる。

コミットメッセージに日本語使うのは問題なくなってきてるみたいね。

失礼、中途半端にマージしたつもりになってたみたい。
ビジュアルマージツールオフにして、従来のように <<<<<<< で示してくれた方がありがたいんだけど、
どうやればいいんだろう。設定の 3-way Merge Tool は　<unspecified> にしてあるんだけど。

Subversion 1.5.0 Released
ttp://subversion.tigris.org/servlets/NewsItemView?newsItemID=2130
ttp://svn.collab.net/repos/svn/tags/1.5.0/CHANGES

>>811
俺も4.xxバージョンで確認した。これでやっとメインに使えるぜ。

Debian sarge のマシンに Mercurial 入れてみました。
パッケージが使えないのでソースからインストールしたんですが、最後のチェックで

$ hg debuginstall
Checking encoding (EUC-JP)...
unknown encoding: EUC-JP, please check your locale settings
(check that your locale is properly set)
Checking extensions...
Checking templates...
Checking patch...
Checking commit editor...
Checking username...
1 problems detected, please check your install!

なんて言われてしまいます。
このまま EUC で運用してたリポジトリを clone しようとしても、同様に
unknown encoding とか言われます。
HGENCODING に UTF-8 を設定すると、debuginstall はパスしますが、
リポジトリを clone するとコミットメッセージが化けてます(当然ですけど)。
dpkg-reconfigure locales で見てみてもシステムのロケールは EUC になってます。
なんか Python だけが勘違いしてるような感じです。
どうすればいいんでしょう？

>>811
TortoiseSVN もファイル数が増えるととんでもなく重いの？

>>816
何度も数千単位のコミットをしてるけど、ウィンドウが出るまで時間がかかってもフリーズしたことは一度もない。
この辺のプログラムは非常に安定していて、こちらも安心して使えてる。

>>816
重いね。
一度、写真を全部管理しようとしてたんだけど
レポジトリのあるディレクトリのアイコンがExplorerで見えたとき
ディスクアクセスがかかってぐっと遅くなる。
今は、MacなんでiPhoto+定期バックアップに切り替えた。
レポジトリにはバージョン管理しなきゃ駄目な奴だけ
入れるのが得策だと気付かせてくれた出来事です。

でも、それでも使う人は、
普段のExplorer使用で、SVNのディレクトリが見えないように
ちょっと深い場所に置くと幸せになれるかもしれません。
実際に使う時は、ブックマークとかそういうのでアクセスする感じで。

>>818
追記
重くなるけど、それは初回アクセスだけ。
何か、Javaアプレットが起動するときと気分は似ている

>>815
etch にアップグレードする

そう簡単にアップグレードできないから困ってる。

>>821
etch出て1年以上経ってsargeはメンテ期間も終わってるんだ。重い腰を上げて
アップグレードしたほうが良い

ところで、python2.3-japanese-codecsを入れても動かないのか?

VC++のソリューションファイル(*.sln)ってバージョン管理に含めない方がいいの？
教えてください

>>823
*.sln は svn:eol-style に CRLF を設定して突っ込んでる。
でも *.suo は「そんなもんコミットすんな、ヴォケ!」としてる。

>>824
AnkhSVNはたしかslnを追加してたんじゃないかな。

TortoiseSVN のダウンロード繋がらん

> etch出て1年以上経ってsargeはメンテ期間も終わってるんだ。重い腰を上げて
> アップグレードしたほうが良い

いや、そうは思ってるんですがね、クリーンインスコの方が何かと問題ないだろうからと思ってると、
サーバー系はなかなか。構築用に一台調達してからでないとできないし。

> ところで、python2.3-japanese-codecsを入れても動かないのか?

動きました。すばらしい。Python はいっぱいありすぎて何入れたらいいものやらわからんのですよね。

>>823
以下のファイル以外は全部突っ込め。

ソース コード管理システムから除外すべきローカル ファイル
http://www.microsoft.com/japan/msdn/vs_previous/visualc/techmat/feature/teamwork/#Sourcecodecontrol

git push
と
git push origin master
の違いが分かりません。
なんで git push じゃだめで git push origin master としなきゃいけないか、教えてください。

MySQLがBazaarを採用したらしいのだが
Subversion、git、Mercurialと比べてどの辺に特徴があるの？

バザールでゴザール

Mercurialではじめる分散構成管理
http://gihyo.jp/dev/feature/01/mercurial

>>832
なんで技術評論社のサイトは印刷用のスタイルシート無いかなぁ。
あとで読もうと思う文書は印刷してストック、
外出時に持ち出し、読んだら紙ごみとして捨てる、
っていう激しく環境にやさしくない購読スタイルの俺。

まぁ情報漏えいに気をつけた上で裏紙は使うけどね。

>>832
一応読んでるけど、本人のサイトで事足りるジャン。
記事の中でもリンク張って端折ってたりするし。

>>830
GNU

Mercurial で、あちこちにリポジトリが散らばってる場合、うまいステータスチェックの
方法はないだろうか。
CVS なら、ディレクトリごとに管理情報があるので、チェックしたいディレクトリに
シンボリックリンク張ったりショートカット作ったりしてまとめておいて、
選択して update で一発だったんだけど。
clone はあくまで .hg の単位だよねえ。

gitで、あるコミットの内容を見るにはどうしたらいいでしょうか。
たとえば git log をみて気になるコミットがあった場合、
そのコミットで何が行われたか詳細を見たいんです。

大人しくTortoiseSVN使えば良いじゃん

>>838
linuxカーネルのレポジトリがそれで
みられるのか？

837のような質問するバカがLinuxのカーネル見て何するの(　´,_ゝ｀)

>>840
お前白痴？
個人のレポジトリなら自分で好きなもの選択できるけど
他人のつくったsvn以外レポジトリを
亀svnでみろっての？
お前白痴？

837のような質問するバカがLinuxのカーネル見て何するの(　´,_ゝ｀)

Gitの基本中の基本を質問して答えを聞かないと分かりもしない人間が
Linuxのカーネル見て何をするなんだ(　´,_ゝ｀)

バカ発見晒しage

>>829
git pushでいけないってことは、remote.<name>.pushが無くて明示しなきゃいけない状態なんじゃ
ないだろうか
http://www.kernel.org/pub/software/scm/git/docs/git-push.html

Mercurial は、マージツール設定してないと旧来通りファイルにコンフリクト情報を書き出してくれるけど、
その状態でコミットできてしまうのは困りものだねえ。

Wikipediaにあるバージョン管理システムの比較表を見て
こんなに種類多いのかよやってられねーよ！と思い
最終的にソフトウェア名の好みで決めてしまったのは、きっと俺だけじゃないはず

真面目な話、みんなどうやって使うシステム決めてるんだ？
「学校や企業ですでに○○使ってる」という場合はともかくとして
自分用にバージョン管理使うときに、何を基準に選んでいるのか知りたい

使い勝手の良いGUIフロントエンドが用意されている。自分が使うライブラリの開発元が採用しているとなお良い。
で、俺の場合はtortoiseSVNにしてみた。

Pythonistaなのでhgにしますた

>>849
同じ理由で hg 使ってる

逆にPythonが肌に合わないという理由で git

まだちゃんとつかってないけど、理解のし易さでhg > git
svnはディレクトリも管理する点が仇となって
意図に反するマージがされるので乗り換え検討中。

おまいらvssのことも忘れないでください。。。


cvs,svnときて今の現場はvssなんだがめっちゃ使いにくいわ！！

つ Rational ClearCase

>>853
MS自信が存在を否定したというのにVSS使ってる企業って脳ミソ腐ってるとしか思えんな・・・

こうやって聞いてると、hgやgit使ってる人はいてもbazzar使ってる人はほとんどいないな。
アレはhgとgitのいいとこ取りしてるって海外の記事であったけど、ホントの所はどうなんだろう・・・。

MySQLはBazaarにしたらしいね

しかし
＞MySQLはこれまでのRCSから、webで関連しているLaunchpadと一緒にBazaarに切り替えた事をアナウンスしました。
今までマジでRCSだったの？　信じがたいんだが。

>>855
なんせ「MS公式です」っていうと安心する企業なんで…。
バージョン管理システムじゃないけど、こないだサードパーティ製を提案したら
「それが既存システムとコンフリクト、あるいは悪影響を及ぼさないと
　君が絶対的な保証してくれるんだね？」と言われて諦めた。

>>858
その上司は実証データがほしいと言ってるんだよ。
何も実証データがないなら、次に考えるのは、安全だと保証してくれる信用できる個人あるいは組織。

hgとgitの二択なら名前だけでgitは大幅評価ダウンにつきhg採用になるんだが、
他の分散型も試してみないとなぁ。

ウチは二重派遣先だから、vssの撤廃なんて進言できん・・・

二重派遣って…(´･ω･｀)

> gitは大幅評価ダウンにつき

詳しく。

＞名前だけでgitは大幅評価ダウン
git 【名】ばか者、愚か者、あほ、間抜け
ってことなんじゃね？
俺はhgはまだ使ったことないけど、Linus好きだからGit使ってみてすごく気に入ったので使用中。
hgはGitからフォークしたっていう話だから基本はそう違わないかなと思ってるんだけど。

>>858
まあいざというときに信用できる企業のサポートを受けられないと駄目だろうね
その点 Subversion は枯れてるけど Mercurial とかはきついだろうなあ

>>860
> hgとgitの二択なら名前だけでgitは大幅評価ダウンにつきhg採用になるんだが、

Mercurial は水銀党に馬鹿受けということか

むしろ HG が団体さんでやってくる。

名前といえば、subversionは「転覆」だけど、これって船がひっくりかえる
んじゃなくて、国家転覆のほうなんだな。

ちなみにgitは>>864の通り「馬鹿でも使える」ってところから。

>>869
由来のことを言ってるなら、「馬鹿でも使える」じゃなくて、Git自身のことを
「インテリジェンスではなくて単純」という意味でGitだと思ったけど。

>>868
つまり Subclipse (Eclipse + Subversion) 使ってる人間は
反逆者思考が多いと言うことか

Eclipse も Sun Microsystems への反逆心を表してるしね

Subversionって「破壊」じゃないの？

subvertする対象は物理的なものではないので破壊じゃない

>>865

>まあいざというときに信用できる企業のサポートを受けられないと駄目だろうね

これってよく聴くはなしだけど
仮に VSS だったら MS が何をしてくれるんだろう

とりあえず文句と責任押しつける対象が必要なんだろ、お偉いさんには。

>>874
何もしてくれなかったよ。

monotoneの使い方についての質問です。

最近monotoneをWindows環境（XP）で使い始めたのですが
日本語でコミットログを書く方法がわからず、困っています。
どのようにして入力すればいいのでしょうか？

ちなみに今まで、-mや--message-fileオプションを試してみたのですが
SJISでもUTF-8でもうまく変換してくれないようです。
（エラー：failed to convert string from ASCII to UTF-8）

CHARSET環境変数をutf-8とかに設定しておけばいい
cp932とかすればSJISでも入ったが、混ぜて使うとよくわからないことになるのでどちらか決めてつかって

怒らないでマジレスして欲しいんだけど、
なんでこんな時間に書き込みできるわけ？
普通の人なら今日学校や会社があるはずなんだけど
このこと知った親は悲しむぞ？
現実見ようぜ

よーし、じゃあマジレスしてやろう。

1日中 PC で作業する仕事なんて珍しくないだろ。
特に技術(開発)職は、作業してるふりさえしてれば何も言われないところがほとんどだろう。
技術情報などでは、2ch は結構勉強になってるぞ。

ところで、そういう君はなんでこんな時間にカキコできるんだ？

WinでMercurialを試してみたいんだけど、TortoiseHgみたいに
エクスプローラに統合するのではなく、スタンドアロンで動く
GUIフロントエンドってないですか？

Pythonのプロジェクトなのにgitを使ってるのに吹いたｗ
http://mathema.tician.de/software/pycuda

>>882
C++のプロジェクトにhgを使うのは吹かないの？

>>883
Ｃ：標準
Ｃ＋＋：準標準
Python：マイナー

utf-8のソースを管理していて VCもサポートすることにしたんですが
GCCで通るBOMなしutf-8が VCだとエラーになるんですよね
BOMありにすると今度はGCCがエラーになるし困った
ソースをバラバラに管理したくはないし…

>>882
RubyForgeなのにPython使ってたりもするし。まあいいんじゃないか。

>>885
BOM有りでエラーになるのは困ったものだけど、BOMが無いとエラーってのも珍妙だね。
MakeでBOM取ってからビルドするようにするってのはどうだろ。
無理やりこのスレ的にするなら、BOM有りブランチを常にマージして使うとかいうヘンテコな方法に
なるかな。

>>879
昼休みの時間でカキコしてる>>877より、
午後で仕事真っ最中に書き込んでる>>879の方がよっぽど心配なんだが・・・。

てーか、コピペ

バージョン管理の対象はファイルなら何でもOKってのが、
バージョン管理システムの良い所じゃないか。
>>882みたいな意見を見ると悲しい

>>889
何か勘違いしているようだが、
PythonやHaskellやRubyといったマイナー言語ではその言語の宣伝のためか、
その言語で作られたツールを使うのが慣習となっているわけだが、
PythonのプロジェクトなのにPython製VMSのMercurialを使わないと言うことはよっぽどひどい出来なんじゃないか、
と思わせるので吹いたわけです。

Subvertionでディレクトリ管理されるのがウザイってのは
毎回、大量のファイルが追加削除されてコミットが面倒ってことなのかな？
状況がよく判らないな。


VSSやらにはファイル共有があるらしいが、これは便利そうだね。VSSやSVN以上に高機能な
ツールで無料のやつってあるのかな？

>>891
単なるディレクトリやファイルとして見た場合、余計なゴミがすべてのディレクトリに入っているのはウザイわけです。

>>891
何を高機能と定義するかにもよるが
最近の後発ツールはだいたいSVNと同程度か、それ以上に使いやすいと思うよ
VSSは使ったこと無いから知らん

ディレクトリが管理されるのとディレクトリごとに管理データがあるのじゃ
まったく意味が違うわけだが

>>892
それは判るけど、CVSみたいにソースの中身書き換えてくるようなモンよりははるかに良いかと。

>>893
SVNから乗り換えるくらいのものってあるのかな？
まあ、1度試せってことなんだろうけど。

>>894
言葉の定義の問題なんだろうけど、言ってるのは結構前のレスでワシではないんで。

>>895
hgやgitはsvnより出来が良いと思うが。

>>878
ありがとうございます！　ちゃんと入力できるようになりました

>>895
とりあえず分散型どれかやってみたら？　面白いと思うよ。俺はもうsvnやsvkには戻りたくない。
CVSはもう使い方忘れたので戻れない。

リポジトリに上げるまでもないような
ちょっとしたテキストの変更するときはrcsで保存してる
Peggy Proは便利だ

>>899
Mercurialを使用し始めてから、rcsの出番は無くなった。

Trac + Subversion 信者に Mercurial の素晴らしさを説明してほしいんだけど
どんなのがあるだろ？

Subversion は Windows GUI の周辺ツールが圧倒的だからなあ…

WindowsだとCUIを使う気になれない
LinuxだとGUIを使う気になれない
不思議

確かに俺もそんな感じだな。
同じsvn使うのでも
linuxではsvnコマンド使うし
winではTortoiseSVN使う。逆はやりたくないw

>>890
そんなこと考えるのはRuby使いくらいだから

MySQLの管理はphpMyAdminなのに、何故かPostgreSQLはCLIでpsql使ってる俺参上。

Windowsはシェルが腐ってるし、UNIX系はCLIで一通りできないと仕事にならんからね..

Windows上でもCygwinでCUI使うな
SVNもGitも
TortoiseSVNとかは痒いところに手が届かないというか
もちろん、それは戦略的に情報を絞っているからでUIとして正しい
方向性だし、他人にはそっちを使うことを勧めてるが

>>891
> VSSやらにはファイル共有があるらしいが

これは確かに便利。
しかしVSS は分離したファイルのマージが激しく面倒。もっともこれは「6」での話で、
最新版は使い始めたばかりなんでどうなってるかまだわからんが。

CVS が捨てがたいのは、modules ファイルを駆使することで似たようなことができるから。

ところで Mercurial でリネームしたときって、しっかり履歴は失われてしまうのね…。

> CVS が捨てがたいのは、modules ファイルを駆使することで似たようなことができるから。

ファイル共有の話ね。

>>901
hg server でスタンドアロンサーバになる。
wikiは付いてないけどな。

標準で付いてくる hgweb.cgi もそこそこの完成度なので
Web 上でログ・ファイルの閲覧 + pull push でリポジトリの更新まで楽勝

>>901
信者って言われるとあれなんだけど
説明を受ける人からすれば、
現機能で十分って思いがある

一言で言えばめんどくさい

>>901
俺も Mercurial 試用中だが、そこまで素晴らしいとは思わないけど。
一番面倒に感じるのは、やっぱり commit, push/pull, merge の煩雑さかな。
今後この辺がうまくまとまらないかと期待しているんだけど。
スクリプト書く手もあるんだけど、Tourtoise だとそうもいかず、めんどい。

あと、例えばプログラム本体とライブラリが別リポジトリの場合、
それぞれのリポジトリで操作する必要がある。

>>881
ないんじゃない？
少なくとも俺は WinCvs 以降見たことない。

TortoiseHg も、Mercurial の性質上、シェル拡張じゃない方が使いやすい
と思うんだが、Tortoise シリーズの伝統(意地？)なのかねえ。

>>907
> ところで Mercurial でリネームしたときって、しっかり履歴は失われてしまうのね…。

darcsならリネームしても履歴は残るよ。
ディレクトリをリネームしてもディレクトリ内の履歴も問題なくたどれる。
試しに3回リネームしてみたけど，ファイル，ディレクトリとも問題なく履歴が表示された。

>>892
必要なのだけaddすれば？

>907
履歴は消えないような？
hg rename file1 file2
hg commit
したときに，
hg log file2
でfile1の履歴まで表示されない，ということ？
であれば，hg log -f file2 で変更前の分まで追跡して表示できますよ

>>907
そこで、bzr(bazaar)ですよ！ちゃんとmvしても履歴が残る。

>>914
ああ、darcsもディレクトリをaddしてたね。
bzrもしてるっぽい。git と hg は駄目だった気がする。