1001コメント314KB

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

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2008/12/04(木) 14:02:52

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

関連スレ
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 r10 [プログラム板]
http://pc11.2ch.net/test/read.cgi/tech/1215565366/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
Bazaarでバージョン管理【bzr>git,svn,cvs】 [プログラム板]
http://pc11.2ch.net/test/read.cgi/tech/1218083381/

前スレ
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
前前スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/

0002デフォルトの名無しさん

2008/12/04(木) 14:05:13

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

0003デフォルトの名無しさん

2008/12/04(木) 14:06:15

CVS
http://ximbiot.com/cvs/cvshome/

Subversion
http://subversion.tigris.org/

monotone
http://www.monotone.ca/

Visual SourceSafe
http://www.microsoft.com/japan/msdn/ssafe/

0004デフォルトの名無しさん

2008/12/04(木) 14:13:45

Git入門
http://www8.atwiki.jp/git_jp/

Subversionによるバージョン管理(日本語訳)
http://subversion.bluegate.org/

0005デフォルトの名無しさん

2008/12/04(木) 14:25:58

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

Bazaar Documentation Overview (英語)
http://bazaar-vcs.org/Documentation

0006デフォルトの名無しさん

2008/12/04(木) 15:00:45

もうSubversionスレに統合でよくね？
他のは使い物にならないし

0007デフォルトの名無しさん

2008/12/04(木) 15:02:43

分散型としてなら有用なスレでございます

0008デフォルトの名無しさん

2008/12/04(木) 15:06:04

>>6
リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」
ttp://po3a.blogspot.com/2007/12/subversion.html

>Subversion のマージもひどいもんだ。Subversion の中の人たちもそのことをちょっとは認めてるようで、新しいプランがあるようだけど、このプランがまたひどい。
>彼らのアホさ加減はもう信じがたいほどだ。ずっとまちがった問題を見てるんだ。ブランチが問題なんじゃない。マージが問題なんだ。

0009デフォルトの名無しさん

2008/12/04(木) 15:53:52

>ソースコード管理（SCM）が使えるための条件は、
>分散型であること
>パフォーマンスがいいこと
>SCM に突っ込んだコードが完全に同じ形で取り出せることが約束されていること

とりあえずgitはマルチバイトなファイル名を何とかすべき。

>SCM に突っ込んだコードが完全に同じ形で取り出せることが約束されていること

が満たされないじゃないか。

0010デフォルトの名無しさん

2008/12/04(木) 15:54:27

Mercurial 使ってるけど、ノート PC とか持ち歩いてるわけじゃないので

家で作業：中央から pull、作業、コミット、中央に push
職場で作業：中央から pull、作業、コミット、中央に push
家で作業：中央から（ｒｙ

分散型のメリットが全然生きてねぇ。('A`)

0011デフォルトの名無しさん

2008/12/04(木) 15:57:44

>>10
ネットに繋がっていない状態ならメリットあるんじゃね？

ところで git status の出力をもっとコンパクトにしたものってありませんでしょうか。
svn status -q ぐらいのコンパクトさを希望します。

0012デフォルトの名無しさん

2008/12/04(木) 16:12:53

Linuxの開発モデルに近いようなことしてる人って少ないから、リーナスの話は
参考になるんだかならないんだかって感じだな。

Subversionにネット切断時用のユーティリティが何か付いたら、もう分散型は要らないって
人も少なくないだろうし。MercurialのMQみたいなの？
svkがもうちょっとしっかりしてくれれば。

0013デフォルトの名無しさん

2008/12/04(木) 16:17:31

>>12
>ネット切断時用のユーティリティ
svnにはlocal-commitが既にあるけど、それでも分散型が必要とされているわけで。

>svkがもうちょっとしっかりしてくれれば
bzr-svnやgit-svnはどう?

0014デフォルトの名無しさん

2008/12/04(木) 16:22:15

>>1 乙

0015デフォルトの名無しさん

2008/12/04(木) 16:41:21

>>13のsvnにローカルコミットが既にあるというのは勘違いだった、スマソ。
ローカルコミットがあるのはbzrだった。中央集中型としてbzr coで取ってきたときでもbzr ci --localができる。
だったら最初から分散型としてbzr branchで取ってくれば良くね? とも思うが、bzrは良く分からん。

0016デフォルトの名無しさん

2008/12/04(木) 17:31:57

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 __
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　, ィﾆﾆ丶｀丶
　　　　　　　　　　　　　　　　　　　　　　　　　　　　〃/__/l_ ﾊ　ﾊ
　　　　　　　　　　　　　　　　　　　　　　　　　　ﾙ「､　 ,.｀｀| 　l }ノ)　　　こ、これは>>1乙じゃのうてオオヌサじゃからな！勘違いするでないぞ！
　　　　　　　　　　　　　　　　　　　　　　　　　　　´ｲ|Tl　 T7 厶/｛´
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 '. '　　　 r人.ﾊ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　＞’ ィ {z==ﾐ ',
　　　　　　　　　　　　　　　　　　　　 r､__　　　　　八ﾘゝﾘ/　　｀,ﾊ
　　　　　　　　　　　　　　　　　　　┌ﾆ` ,_｀ - ､_ 　　/　/{｛_ｌﾉ　　,r　}ﾑ
　　　　　　　　　　　　　　　　　｀乏r‐ヘr､_　｀ヾ　 | |V/　　/__ノ::ﾊ
　　　　　　　　　　　　　　　　　　　　　r‐ﾆ′｀ｰ-＜l_,iノ　ｲ::::::::';:::::',
　　　　　　　　　　　　　　　　　　　　´.孑_r‐￢- ...__　　,.ｲ/ﾊ:::::::::､::ﾑ
　　　　　　　　　　　　　　　　　　　　　　　　´　　　　　 | 丁[　|l }:i:::::::::｀;:::ﾊ
　　　　　　　　　　　,､＿__,.　　　　　　　　　　　　　{/l|│ ﾊﾘ:l:::::::::::::;_:ハ
　　　　　　　　　　　｀フ／　　　　　　　　　　　　　　　　ヾ! N/V;ノ匸丁　 l　｝
　　　　　　　　　　（_（＿ﾉ>　　　　　　　　　　　　　　　　　くく_　,. イ　　/　ﾊ
　　　　　　　　 /_|:|ﾊ､　　　　　　　　　　　　　　　　／　く_　　　 .:　/:..|
───────/77|:|」ﾍ>───────‐､　　／　　　　｀才:ｲ__/￣
　　　　　　　　　___>/;;|:|戈z__,　　　　　　　　　ﾞ､ , ´ 　　 _　‐'´／
　　　　　　　　 __/7;;;;|」;;<ヘ`＾　　　　　　　　　ﾞ{　　　f:´　 _r"
:　　.　　:　　.　／‐┘　　　｀ゞﾞ　　　.　　　:　　　. 　ﾞ､　　ﾞ,　　｀丶
:　.　:　.　:　.　:　.　:　:　:　:　:　:　:　.　:　.　:　.　:　.　:　ﾞ,.　　ト､　　　＼

0017デフォルトの名無しさん

2008/12/04(木) 18:56:29

スレ立て>>1だね、乙だね

0018デフォルトの名無しさん

2008/12/04(木) 19:40:54

Python3000がとうとう出たぜ。

これで、Mercurialのファイル名文字コード問題も
収束できるか？！

0019デフォルトの名無しさん

2008/12/04(木) 19:53:02

hgってファイル名もそうだけど、テキストファイルの中身も変換しないんでしょ？
svnやbzrが文字コードの変換を実装してるのに、なんでhgはしないんだろう。
余計な機能つけてバグが出るのを避けるため？

0020デフォルトの名無しさん

2008/12/04(木) 20:03:10

Mercurial でちょっと長い日本語ファイル名を付けると
ファイルの名前の長さ制限を簡単に越えちゃわない?

0021デフォルトの名無しさん

2008/12/04(木) 21:22:36

>>9
完全に同じじゃん

……バイト列として

0022デフォルトの名無しさん

2008/12/04(木) 21:26:35

>>19
中身はどのSCMでも変換しないよ。

つか、それのおかげでhgに乗り換えようと思ってたけどbzrにした。

0023デフォルトの名無しさん

2008/12/04(木) 21:28:12

>>18
2.xと3.xでソースコードの互換性ないから（移行ツールはあるけど）
移植するのにひと手間掛かると思われ。

hgとbzrでどっちが先に対応するか見物だな。

0024デフォルトの名無しさん

2008/12/04(木) 22:48:55

>>23
何が起こるか分からないし、どっちも当分3への移行はなさそうだがｗ

0025デフォルトの名無しさん

2008/12/04(木) 22:52:58

>>19 >>22
Subversinは改行コードは変換出来るな。
ファイル名の件も含めてマルチプラットフォームなプロジェクトだと助かる。
Mercurial, gitは変換なし？　他はどうなんだろ。

改行コードもそうだが、Subversionの属性に当たる機能って他のVCSだとどうなってるのかね。
個人的には改行コードとバイナリの扱いだけ出来れば十分だけど。

0026デフォルトの名無しさん

2008/12/05(金) 01:52:21

属性は微妙

0027デフォルトの名無しさん

2008/12/05(金) 07:56:08

これ面白いな。

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

で、それに対する Mercurial側の回答
http://www.selenic.com/mercurial/wiki/index.cgi/BzrVsHg

Mercurial 0.9.5の頃の奴だから、現状だと違うとこがあるかもしれないけど。

0028デフォルトの名無しさん

2008/12/05(金) 12:03:58

hg update がエラーになります。

$ hg update
abort: crosses branches (use 'hg merge' or 'hg update -C' to discard changes)

メッセージどおりに hg merge すると、これもエラーになります。

$ hg merge
abort: outstanding uncommitted changes

どうしたらいいでしょうか。

0029デフォルトの名無しさん

2008/12/05(金) 13:02:21

git help
ではすべてのコマンドが表示されないようですが、
git のすべてのコマンドを一覧表示する方法はありますか。

0030デフォルトの名無しさん

2008/12/05(金) 13:33:44

man gitではだめ？確かに助長ではあるけど・・・

0031デフォルトの名無しさん

2008/12/05(金) 13:35:02

× 助長
○ 冗長

0032デフォルトの名無しさん

2008/12/05(金) 13:44:07

他のコマンドは‘普通‘使わないでいい、内部向けコマンドが多いよね。
どういう時に使えたら便利なんだろうか…。

0033デフォルトの名無しさん

2008/12/05(金) 15:02:34

>>32
開発途中にコマンド入れたけど意外と使えなかったとか、なんかのコマンドが内部で使ってるとかじゃないの？
ムリに使うようなもんでもないと思うが。

0034デフォルトの名無しさん

2008/12/05(金) 16:58:19

>>28

コミットしていない修正があるのでは？
hg commit でその修正を一度コミットしてから，
hg merge して，もう1度マージ内容を hg commit
でいいかと．

0035デフォルトの名無しさん

2008/12/05(金) 21:08:59

>>33
We divide git into high level ("porcelain") commands and low level ("plumbing") commands.
だそうで。
porcelainは内部でplumbingを使ったりしてるらしい。

0036デフォルトの名無しさん

2008/12/05(金) 21:43:33

>>34
hg clone myrepo myrepo-tmp
cd myrepo-tmp
hg merge
hg commit
hg push
cd ..
rm -rf myrepo-tmp
cd myrepo
hg update

0037デフォルトの名無しさん

2008/12/06(土) 01:04:15

mercurialの日本語書籍ってまだ出てない？

0038デフォルトの名無しさん

2008/12/06(土) 01:53:44

ない

0039デフォルトの名無しさん

2008/12/06(土) 02:12:38

IronRubyがGithubに移行
http://www.infoq.com/jp/news/2008/12/ironruby-movesto-github
これは意外な…。

0040デフォルトの名無しさん

2008/12/06(土) 02:19:48

>>36
ありがとうございます。
月曜日に試してみます。

0041デフォルトの名無しさん

2008/12/06(土) 03:50:43

>39
そういや、MicrosoftのTeam Foundation Server使ってる人って居ないの？

俺は時々Microsoftのセミナー行くけど、そこじゃTeam Foundation Serverの
名前すら出てきた事無いな。Visual SourceSafeの話も一切聞かないけど。

0042デフォルトの名無しさん

2008/12/06(土) 06:46:34

>>20
mercuria 1.1が出たけど、そのchangeログに制限を改善したとか
かいてある。試してないので本当か分からんが。
はやく1.1版のTortoiseHgが欲しいところ。

0043デフォルトの名無しさん

2008/12/06(土) 13:01:40

分散型のメリットってサーバーの負荷軽減だけ？

0044デフォルトの名無しさん

2008/12/06(土) 13:07:38

ネットワークに繋がってなくても大丈夫

0045デフォルトの名無しさん

2008/12/06(土) 13:12:12

>>43
マージがしやすい

0046デフォルトの名無しさん

2008/12/06(土) 13:13:35

>>45
それは分散型だからマージがしやすいんじゃなく、
ちゃんとしたマージを積んでないと分散型として成立しないってだけなんじゃ……

0047デフォルトの名無しさん

2008/12/06(土) 13:13:56

>>43
ログや過去のリビジョンとの差分を見るのが早い

0048デフォルトの名無しさん

2008/12/06(土) 13:15:41

>>43
他人のブランチから簡単にforkできる

0049デフォルトの名無しさん

2008/12/06(土) 13:37:08

最近SVNを導入した初心者ですが、
ひとつのファイルに対して複数の箇所を修正後、それらを別物としてコミットするにはどうすればよいですか？

0050デフォルトの名無しさん

2008/12/06(土) 13:56:51

>>49
厳密に言うとないです。gitでも同様。
いったんパッチを保存して分割、ファイルをrevertして分割したパッチを一つずつ当ててcommit、てところか。

0051デフォルトの名無しさん

2008/12/06(土) 14:20:46

>>50
なるほど、やはりそうでしたか。

0052デフォルトの名無しさん

2008/12/06(土) 15:19:17

質問です。

主要なバージョン管理システムのうち、一番リポジトリ容量が少なくて済むのは何ですか？

0053デフォルトの名無しさん

2008/12/06(土) 15:56:50

>>49
Gitならできます。
git add -i file.txt
とすると、変更箇所ごとに、コミットするかどうかを聞いてくるので、yまたはnで答えてやると、
yと答えた変更箇所だけがコミット対象になります。

同じ機能がMercurialでも欲しいんですけど、だれかしりませんか。

0054デフォルトの名無しさん

2008/12/06(土) 16:04:45

>>52
たぶんSubversionじゃないかな。
Subversionはどのファイルでも差分をとって管理する。
Gitは差分をとらず、Mercurialは画像ファイルのようなバイナリは差分をとらない。
だから5Mぐらいの画像ファイルがあって、それをちょこっとだけ修正した場合、Subversion以外だとどんどんリポジトリサイズが増えるそうだ。

0055デフォルトの名無しさん

2008/12/06(土) 17:34:26

>>54
hgもバイナリの差分をとるよ。
ネガティブキャンペーンはよくないな。

0056デフォルトの名無しさん

2008/12/06(土) 17:55:58

>>55
まあまあ、gitやhg,bzrはどんどんバージョンアップしてるから
仕様が変わって知らなかったんじゃない？

0057デフォルトの名無しさん

2008/12/06(土) 18:00:52

てか用途、プロジェクトの規模なんかも書かずに
漠然とリポジトリのサイズが最小のツールを聞くって何がしたいんだ。
ただの興味本位か？

0058デフォルトの名無しさん

2008/12/06(土) 18:02:44

以前海外のページでgit・hg・bzrの比較があったけど、
だれかあれの日本語版作ってくれないかなあ？

0059デフォルトの名無しさん

2008/12/06(土) 18:03:19

あれ、古いからなぁ。

0060デフォルトの名無しさん

2008/12/06(土) 18:08:15

>>57
鉛筆を転がすかわりじゃなかろうか。

0061デフォルトの名無しさん

2008/12/06(土) 19:53:08

なにもバージョン管理システムはプロジェクトのソースコード管理にだけ使われるものでもあるまい
空間効率を聞くのにプロジェクトの規模とか関係ないだろ

0062デフォルトの名無しさん

2008/12/06(土) 20:08:19

>>53
hg record file.txt

0063デフォルトの名無しさん

2008/12/07(日) 00:01:23

>58
それ、>27の事？

0064デフォルトの名無しさん

2008/12/07(日) 15:18:11

ＩＢＭのＣｌｅａｒＣａｓｅは糞中の糞ソフト
ＩＢＭ社員でもあんなの使ってないだろうな

0065デフォルトの名無しさん

2008/12/07(日) 15:46:41

だって、Rationarl買収したらついてきちゃったんですもの。

0066デフォルトの名無しさん

2008/12/07(日) 19:50:06

>>63
いや、俺が以前見たのはこっち。
http://www.infoq.com/articles/dvcs-guide

0067デフォルトの名無しさん

2008/12/07(日) 21:19:56

ClearCase採用してる企業ってあんのかな？
商用ソフトかぶれのところだけなんだろうけどな。
ＶＳＳが異常に普及してるように・・・・

0068デフォルトの名無しさん

2008/12/07(日) 21:25:45

VSSはサポートを買ってるのだ
何度言えばわかるんだよ

0069デフォルトの名無しさん

2008/12/07(日) 21:34:38

その買ったサポートがいざというときに役に立った企業がどんだけあるんだか

0070デフォルトの名無しさん

2008/12/07(日) 21:39:53

>>69は無職

0071デフォルトの名無しさん

2008/12/07(日) 21:51:10

>>69
>その買ったサポートがいざというときに役に立った企業がどんだけあるんだか
禿同
いざというときのためのサポートのはずなのに、いざというときにまるで役に立たない

0072デフォルトの名無しさん

2008/12/07(日) 21:53:38

金出して買ってサポートも頼んだがどうにも駄目だった、というのが有償製品の活用法だろ

0073デフォルトの名無しさん

2008/12/07(日) 22:02:53

>>72
一瞬、激しく同意したが、「それでもなんとかしろ」と言われるケースを思い出して鬱になった。

0074デフォルトの名無しさん

2008/12/07(日) 22:04:03

CleraCaseもサポートは糞だろうか？

0075デフォルトの名無しさん

2008/12/08(月) 01:26:03

今はVSSじゃなくて、Team Foundation Serverの時代だって。

0076デフォルトの名無しさん

2008/12/08(月) 02:30:08

git branch hoge
とすると、新しいブランチがローカルリポジトリに作成されますが、
これをリモートブランチに反映させるのはどうしたらいいのでしょうか。
つまり、
git branch -r
とした結果に origin/hoge が出てくるようにしたいです。

0077デフォルトの名無しさん

2008/12/08(月) 03:35:48

git push origin hoge

0078デフォルトの名無しさん

2008/12/10(水) 11:52:53

>>29
>git のすべてのコマンドを一覧表示する方法はありますか。

git help --all
git help -a
でいけました。

0079デフォルトの名無しさん

2008/12/11(木) 15:09:09

ローカルマシン　winxp
バージョン管理マシン　linux 1 (subversion)
共有フォルダマシン　linux 2 (samba)
ローカルマシンバージョン管理ソフトTortoiseSVN 1.4.8

ローカルマシンにチェックアウトしたファイルやフォルダには緑のビックリマークとか付きますが、
共有フォルダにチェックアウトするとビックリマークが表示されません
共有フォルダにもビックリマークを表示させる方法はありますか？

0080デフォルトの名無しさん

2008/12/11(木) 20:47:06

>>79
試してないけど、TortoiseSVNの設定→アイコンオーバーレイ→ドライブの種類、の
「ネットワークドライブ」にチェックを付ければいいのでは。

あと、その話題はたぶんこっちのスレの方が向いてる
ttp://pc11.2ch.net/test/read.cgi/tech/1215565366/l50

0081デフォルトの名無しさん

2008/12/11(木) 22:56:44

MercurialからBazaarに変換する一番良い方法はなんですか？
環境はWinXP+Cygwin+WinネイティブMercurial+WinネイティブBazaarです。
fastimportをCygwinのpythonから使おうとしましたが、Winネイティブmercurial
しかインストールしていないせいかno module named mercurialエラーが出てしまいます。
かといって今更Cygwin+Mercurialは、Winネイティブとの衝突
ttp://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-install.html
が怖くて使えません。

もう一つ。Mercurialで、過去のコミットログのuserを変更するにはどうしたらいいんでしょうか？

よろしくお願いします。

0082デフォルトの名無しさん

2008/12/12(金) 00:44:09

>>81
俺は bzr fastimport を使って Hg -> Bazaar やった。
hgのexporter の使い方が若干判りにくいけど、変換自体はすごい楽ちん。

0083デフォルトの名無しさん

2008/12/12(金) 09:50:25

>>81
僕も bzr fastimport を使ったねぇ。
なんか、exporter が sh と py な拡張子の2つあるけど、
どっちかしか動かなかった。
ただ、Windows 上ではやらず、linuxで変換しました。

0084デフォルトの名無しさん

2008/12/12(金) 10:33:08

続々と Mercurial を捨てる人が出てきたねぇ。ｗ

今のところファイル名の件はそう大きな問題じゃないから、まだしばらく使うけど、
このことに理解を示さない開発側の姿勢は問題だと思うんで、いずれ移行しよううかとは
思ってるけど。

0085デフォルトの名無しさん

2008/12/12(金) 11:09:12

Git でリモートブランチを消す方法を教えてください。
git branch -r -d origin/hogehoge
とすればリモートブランチが消えると思ったのですが、
git fetch
すると復活します。つまり、リモートブランチは本当は消えてないということですよね。
ほんとのほんとにリモートリポジトリ上のブランチを消す方法があれば教えてください。

008683

2008/12/12(金) 11:28:31

>>84
乗り換えた理由は、
1. bzr-svnの完成度がhgsvnより高い
なんかhgsvnは開発が止まっているっぽい
bzr-svnの作者のbugへのレスポンスの早さは異常だったw
2. bzr1.9のWinインストーラが必要十分だった
paramikoも入ったし、Pageant連携も設定なしでできるし。
hgのときはMeadowのeshellモードからのみの利用で、
bzrではcmd.exeからの利用が主です。
bzrはeshellからうまく動かないのが謎ですが、あまり困ってません。

というところですかね。

0087デフォルトの名無しさん

2008/12/12(金) 11:30:16

>>83
>ただ、Windows 上ではやらず、linuxで変換しました。
これって、BazaarのリポジトリはOS非依存ってこと？
おしえてえらいひと。

008883

2008/12/12(金) 11:52:42

>>87
linux/Windows間のリポジトリのやりとりは、
bzr push/pull sftp://example.com/
みたいにしてます。少なくとも、上記のやりとりで
Win/linux間のinteroperativityに問題はないですね。

実は、bzr pushする際の先のサーバに
bzrがインストールされている必要がないことを考えると、
(つまりファイルをコピーしているだけのはず)
.bzr以下のファイルを固めてWin/linux間にコピーするだけでも
動くはずではあります(試してません)。

0089デフォルトの名無しさん

2008/12/12(金) 12:38:55

>>88
なるほど。hg → bzr はlinux上で行って、linux→windowsはbzr→bzrでやったというわけですね。
なんて賢い。

>実は、bzr pushする際の先のサーバに
>bzrがインストールされている必要がないことを考えると、
まじっすか? Bazaarすげー!

009083

2008/12/12(金) 13:00:33

>>89
あ、sftpを使ったときの話です。
もちろん bzr://example.com/ とか bzr+ssh://example.com/ とかはだめです。

あと、sftpを使ったときのhgとの細かな違いは、hgは$HOMEをベースにしますが、
bzrは/をベースにする、といったところですかね。
hg xxx ssh://example.com/abc
bzr xxx sftp://example.com/%7E/abc
みたいになるはずです。

009183

2008/12/12(金) 13:21:31

追記
sftpだけでなくftp, http(WebDAV)ならサーバにインストールされてなくてもいいはずですね。
KLABのDSAS開発者がまとめた記事がわかりやすいですかね。
http://dsas.blog.klab.org/archives/51344422.htm

0092デフォルトの名無しさん

2008/12/12(金) 17:29:08

うおーだれか>>85たすけてください
>ほんとのほんとにリモートリポジトリ上のブランチを消す方法があれば教えてください。

0093デフォルトの名無しさん

2008/12/12(金) 18:12:46

俺まったくGitさわったことないけど、
http://www.kernel.org/pub/software/scm/git/docs/git-remote.html
上のページの”git remote rm”オプションじゃだめ？

話変わるけど、ホント一気に風が変わったよね。今までgitかhgしか話題にならなかったのに。

0094デフォルトの名無しさん

2008/12/12(金) 18:22:39

fdoがcgitの新しいのになったな。
微妙にかっこいい。

009579

2008/12/12(金) 18:25:50

>>80
ありがとうございますアイコンが表示されました

0096デフォルトの名無しさん

2008/12/13(土) 03:35:02

bzrって重すぎない？
うちのVIAマシン(C7 1GHz)だと、どのサブコマンドも確実に2秒以上
ターンアラウンドにかかるよ。

% time bzr version
Bazaar (bzr) 1.6.1
Python interpreter: /usr/bin/python 2.5.2
Python standard library: /usr/lib/python2.5
（中略）
bzr version 2.39s user 0.08s system 99% cpu 2.480 total

ちなみに、同じマシン上のMercurialはこんな感じ。
hg version 0.11s user 0.02s system 99% cpu 0.129 total

009781

2008/12/13(土) 03:47:40

>>82,83
とりあえずリベンジでCygwin版BazaarとMercurial入れてみました。
再度fastimport試してみました。
そうしたら、ファイル名と内容に日本語使ってるせいか、exporterがSJISで吐きだしてくれちゃった
データをbzr fast-importがUTF-8でデコードしようとしてこけちゃいました。
日本語入ってないので試したらぱっと見はできてたんですがね。
手元にlinux環境が無いんでまだしばらくはhgとbzr併用でいきます。
ありがとうございました。

0098デフォルトの名無しさん

2008/12/13(土) 07:38:56

m% time bzr version
Bazaar (bzr) 1.10
bzr version 0.21s user 0.07s system 84% cpu 0.331 total

% time hg version
Mercurial Distributed SCM (version 1.0.2)
hg version 0.40s user 0.11s system 96% cpu 0.529 total

0099デフォルトの名無しさん

2008/12/13(土) 10:22:36

>>97
や、Cygwin使ってる時点で、日本語ファイル名とか無いから。
せめてUTF-8 Cygwinか、Cygwin 1.7(+UTF-8使用設定)で試せ。

0100デフォルトの名無しさん

2008/12/13(土) 11:43:27

>>96
俺もそれでhgを使ってたんだが、1.7, 1.8 と確実に速くなっていて、bzr に乗り換えた。
1.10で試してみて。

0101デフォルトの名無しさん

2008/12/13(土) 11:57:31

>>85
git push origin :hogehoge

cf. git push --help

0102デフォルトの名無しさん

2008/12/13(土) 18:03:40

>100
bzr 1.10に上げてみたが、大して速くなってないなぁ。
システムが低速SSD上に有るのが良くないのか？

↓1ファイル置いてない、しょぼリポジトリで試した結果。
bzr version 2.02s user 0.07s system 99% cpu 2.110 total
bzr diff 2.93s user 0.09s system 99% cpu 3.044 total
bzr stat 2.94s user 0.10s system 99% cpu 3.064 total
bzr hogehoge 1.90s user 0.04s system 99% cpu 1.947 total

0103デフォルトの名無しさん

2008/12/13(土) 18:09:10

俺も試してみた。
$ time hg --version
Mercurial Distributed SCM (version 1.0.1)
[snip]
real 0m0.206s
user 0m0.140s
sys 0m0.048s

$ time bzr --version
Bazaar (bzr) 1.10
[snip]
real 0m0.177s
user 0m0.128s
sys 0m0.024s

0104デフォルトの名無しさん

2008/12/13(土) 18:59:07

% time git --version
git version 1.5.4.3
git --version 0.00s user 0.00s system 50% cpu 0.008 total

0105デフォルトの名無しさん

2008/12/13(土) 19:42:05

>>103-104
何が言いたいの？

0106デフォルトの名無しさん

2008/12/13(土) 22:33:58

マシンスペックもかかずに・・・参考に並んだろ

010781

2008/12/13(土) 22:48:26

>>99
駄目でした。同じようになります。

0108デフォルトの名無しさん

2008/12/13(土) 22:57:28

本命はバザーですか

0109デフォルトの名無しさん

2008/12/13(土) 23:03:56

いいえケフィアです

0110デフォルトの名無しさん

2008/12/14(日) 00:03:12

Bzrはtortoiseが使い物になるまで待ち

0111デフォルトの名無しさん

2008/12/14(日) 00:51:22

Announce: TortoiseGit 0.1 preview version
http://marc.info/?l=git&m=122915721426191&w=2

0112デフォルトの名無しさん

2008/12/14(日) 07:05:11

>>111
知らせてくれてありがとう。現時点ではメニューに表示されるだけで
動かない機能が多いようだ。気長に待つことにしよう。

0113デフォルトの名無しさん

2008/12/14(日) 08:28:53

>>108
最近、bazaarが流行ってるなー。

0114110

2008/12/14(日) 09:41:20

>>111
使い物にならないというのは、>>112 のことね。
あと、日本語フォルダ上でレポジトリを作れないとか、
完成度がまだ低すぎる。小数点のバージョンでは無理もないが。

0115デフォルトの名無しさん

2008/12/14(日) 09:45:49

Opteron152, FreeBSD7.0でやってみた
$ time bzr version > /dev/null
0.24 real 0.09 user 0.00 sys
$ time hg version > /dev/null
0.06 real 0.02 user 0.00 sys
$ time git version > /dev/null
0.00 real 0.00 user 0.00 sys

0116デフォルトの名無しさん

2008/12/14(日) 10:50:59

>>114
これってgitの実行ファイルも同梱してるの？
というか、そもそもwinでまともに実行できるgitはなかったような・・・。

0117デフォルトの名無しさん

2008/12/14(日) 11:26:25

win環境であえてgitを使おうとは思わないが

0118デフォルトの名無しさん

2008/12/14(日) 15:32:57

>>115
それで速度テストしてる気になってるの？
あんたアホですか？w

0119デフォルトの名無しさん

2008/12/14(日) 16:44:55

「無意味な煽り乙」っと思ったら、>>118のいう通りじゃねーか
そんな実験バイナリとpythonの速度差しかわからんぞ？

0120デフォルトの名無しさん

2008/12/14(日) 19:59:53

>>117
じゃTortoiseGitの作者に「ムダなので今すぐやめてください」って抗議しる

0121デフォルトの名無しさん

2008/12/14(日) 20:21:34

あーあ、120 を泣かしたー

0122デフォルトの名無しさん

2008/12/15(月) 00:08:59

あらら

0123102

2008/12/15(月) 05:46:25

>119
うちじゃ、その速度差が激しいのだが。
bzr version > /dev/null 2.02s user 0.06s system 99% cpu 2.092 total
hg version > /dev/null 0.11s user 0.02s system 99% cpu 0.128 total

何が原因なんだ？

0124デフォルトの名無しさん

2008/12/15(月) 08:09:11

>>123
しらんがな

0125デフォルトの名無しさん

2008/12/15(月) 08:58:47

>>123
1.10 にあげてみたつもりで1.6動かしてない？

0126デフォルトの名無しさん

2008/12/15(月) 11:00:38

>>123
hgとbzrはどっちもpythonだから、そんなに速度差があるわけないんだがなあ。

0127デフォルトの名無しさん

2008/12/15(月) 14:45:03

monotoneに関しての質問です。

データベースファイル（*.mtn）だけを、メインPCから他のPCに移して
その中のブランチをcheckoutしようとしたのですが、
中に含まれている最初のファイルの時点で
次のようなメッセージが出て、なぜか失敗してしまいます。

mtn: 誤り: 名称変更ターゲット 'testdir/first_file.txt' は既に存在しています

checkout先のディレクトリを見てみると
_MTN ディレクトリと testdir/first_file.txt だけが作られていました。
このエラーはなぜ発生するのか、原因のわかる方がいましたら教えてもらえないでしょうか？
なお、monotoneのバージョンは0.41で、Windows XP環境です。

0128127

2008/12/15(月) 14:54:10

書き込んでからいろいろ試していると、
mtn genkeyしただけで落ちることに気がつきました・・・

もしかすると、monotoneのこのバージョン（0.41）に問題があるのかもしれません。
後ほどメインPCでもう一度確認してみます。

0129デフォルトの名無しさん

2008/12/15(月) 15:01:49

>>123 はアホだから、
bzr -> バイトコンパイル前に実行
hg -> バイトコンパイル後に実行

こんな感じで実行してたんだろ。

0130127

2008/12/16(火) 07:01:17

やっぱり上手くいきませんでした。
monotone 0.40を使えば、genkeyで落ちることは無くなったのですが
checkoutは同じエラーで落ちてしまいます。

メインPCでのcheckoutは平気で出来るのに、サブPCでのcheckoutは失敗するなんて
いったいどうなってるのコレ
潔くmonotoneを使うのを止めろってことなの

0131123

2008/12/16(火) 21:53:58

えー、結論から言いますと、>129が正解でした。それでもhgよりは遅いけど。
bzr version > /dev/null 0.41s user 0.06s system 99% cpu 0.471 total

pythonって、バイトコンパイルしないとあんなに遅いのか。
インスコする時に、ずらずらっと表示されてたんでコンパイルしてるのか思ってた。
Mandriva 2009.0のパッケージで入れた奴もコンパイルされてなかったんだな。

0132デフォルトの名無しさん

2008/12/17(水) 02:09:59

hgでcommitlogを書き直す方法を教えて。
そもそもcommitlogもリビジョン管理できたらいいのに。

0133デフォルトの名無しさん

2008/12/17(水) 08:42:33

>>130
うちでは普通に動いてるな
同じファイル名が大文字小文字違いで入ってたりはしないよな

0134デフォルトの名無しさん

2008/12/17(水) 11:44:59

>>131
Ruby や Perl に比べると、バイトコンパイルできるからロードが早いんだけどな。
Cに比べるともちろん負ける。

ロードが0.5秒を切ったら、ロード時間よりもリポジトリやファイルを操作する時間の方が
大事になってくる。

0135デフォルトの名無しさん

2008/12/17(水) 20:25:00

>>134
脱線するけど、Rubyも1.9からYARVとかいうのでバイトコンパイルできるようになったらしいよ？
俺メインpythonだからよく知らんけども。

0136デフォルトの名無しさん

2008/12/17(水) 21:44:42

>>135
結果を*.pycのようなファイルに落とすところまでは、まだ至ってない。

0137デフォルトの名無しさん

2008/12/19(金) 13:24:08

今、所謂cherry-picking（他所branchのchangesetをつまみ食い）について
調べてるんだけど、現状はこんな感じで間違いない？

Mercurialでは、下のURLの"import/export"の章に書いてあるように、
patchファイルを作って適用するとマージ元ログがそのまま入るけど
IDが元と変わってしまうし、メタ情報(どっから持ってきたかとか)が
失われるので二重マージも防げない。
http://www.selenic.com/mercurial/wiki/index.cgi/CommunicatingChanges

transplant拡張を使うと二重マージは防げるようになるけど、
メタ情報はtransplant専用ファイルに記録されてるだけで、
Mercurial公式のfirst-classメタデータとは言えない。IDも元と変わってしまう。

com.selenic.mercurialで紹介されてるmerge+backout("cherry-winnowing")の
方法を使うと、IDは保存されるし二重マージも防げるけど、ややこしくて、
ログを見ると流れが複雑すぎて頭が混乱してくる。

Bazaarでは下のURLに書いてある通り簡単に操作出来るけど、メタ情報の無い
普通のコミットと同じ扱いになるので、二重マージを防いだりマージ元ログを
引用させたり出来ない。
http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#pseudo-merging

darcsだとうまくいくらしい？

0138デフォルトの名無しさん

2008/12/19(金) 13:28:06

launchpad使っている人いないですか？
Register a branch画面で Project名がInvalid valueと言われてしまい困っています。
どんな名前だったらよいのでしょうか？アルファベット12文字くらいでもはねられる・・・

https://code.launchpad.net/

0139デフォルトの名無しさん

2008/12/19(金) 13:36:20

>>137
>普通のコミットと同じ扱い
そんな事無いよ。サブリビジョン?の概念があるから。

>>138
先にプロジェクトを登録しないとダメ。登録は以下から。
https://launchpad.net/projects/+new
またプロジェクト無しでもブランチを作れる。その場合は"bzr push lp:~ユーザー名/+junk/ブランチ名"でおk。

0140デフォルトの名無しさん

2008/12/19(金) 14:00:14

>139
そのサブリビジョン?って何？　bzr log -v --show-ids でも出てこないみたいだけど。
bzr mergeすると黙って二重マージされちゃうし、何の役に立ってるの？

0141デフォルトの名無しさん

2008/12/19(金) 14:07:49

>>140
>bzr mergeすると黙って二重マージされちゃうし
Nothing to do.って言われてマージされないよ?

0142デフォルトの名無しさん

2008/12/19(金) 14:25:35

>141
今確認してみたけど、やっぱ二重マージされるような……。

ちなみに、141の環境では、logコマンドのparent行みたいに、cherry-picking元のIDを
後から確認出来るの？

0143141

2008/12/19(金) 14:54:23

ごめん、飛び飛びの場合のトラッキングはサポートされてないようだ。
http://bazaar-vcs.org/MergeTracking
マージの時に--merge3や--weaveでコンフリクトを抑えるしかないみたい。

0144デフォルトの名無しさん

2008/12/19(金) 16:37:45

git便利そうなんだけどwindowsも使うんだよなあ

0145138

2008/12/19(金) 16:51:05

>>139
サンクス。先に登録しないとだめなのね
やってみるっす。

0146デフォルトの名無しさん

2008/12/19(金) 16:57:24

>>144
cygwinでUTF-8ならWindowsでも使えるよ

0147デフォルトの名無しさん

2008/12/19(金) 18:54:48

>>137
MQ使うかdarcs使え。
それ以外は無理。

0148デフォルトの名無しさん

2008/12/19(金) 23:03:41

なんでdarcsだと二重マージを防げるの？
各パッチに固有のIDを割り振ってるのかな？

0149デフォルトの名無しさん

2008/12/19(金) 23:57:45

darcsは、パッチ管理ソフトだから。

0150デフォルトの名無しさん

2008/12/20(土) 03:50:28

状態記録パラダイムのソフト(Mercurial, Bazaar)で、パッチ集積パラダイム(darcs)の
機能を実現しようとするから、複雑になったり泥縄的になったりするんじゃないかな。

0151デフォルトの名無しさん

2008/12/20(土) 03:54:32

泥縄は泥臭いという意味じゃないよ

0152デフォルトの名無しさん

2008/12/20(土) 09:46:16

アホな俺に教えてくれ。
>>149
修正，削除のない，追加だけのパッチでも二重マージって防げるものなの？
>>150
状態記録といっても，hgやgitは差分で内容を保存してるんでしょ。
差分てパッチと同じような気がするんだけど，どう違うの？

0153デフォルトの名無しさん

2008/12/20(土) 13:01:56

>>152
Gitは差分じゃないよ。hgはたしか差分。

0154デフォルトの名無しさん

2008/12/21(日) 12:22:34

>>150
>状態記録パラダイムのソフト(Mercurial, Bazaar)で、パッチ集積パラダイム(darcs)の
>機能を実現しようとするから、複雑になったり泥縄的になったりするんじゃないかな。

これ、もっと詳しく知りたい。教えてえらいひと！

0155デフォルトの名無しさん

2008/12/21(日) 14:17:34

mercurial 1.1.1 release

0156デフォルトの名無しさん

2008/12/23(火) 00:19:48

>>154
version1 = version0 + 機能1
version2 = version1 + 機能2
version3 = version2 + 機能3
と考えたときに、機能1がいらなくなったとしよう。
そのときパッチ集積パラダイム(チェンジセット指向)だと
version4 = version0 + 機能2 + 機能3
ということができる。
hg,bzrみたいなスナップショット指向は
versionXしか扱えないからダメ。
MQでもこういう事はできるけどMQはローカルでのパッチ管理なので
みんなでパッチを共有することはできない。
hgがたとえ内部で差分管理していても
その差分に名前が付けられていないからユーザは手が出せない。

0157デフォルトの名無しさん

2008/12/23(火) 02:05:52

Mercurialの公式wikiの翻訳って今どうなってるの？
誰かやりかけてるの有る？　hgbookは誰かやってるんだっけ？

0158デフォルトの名無しさん

2008/12/23(火) 10:37:21

>>156
サンクス。
ただ、これだと「機能1の機能を消すパッチ」を当てればいいだけだと思うんだけど、どうでしょうか？
機能1 をrevertするようなパッチを作成する機能ってたしかgitとかhgにあったと思います。

あと、>>150はもともと>>148の
>なんでdarcsだと二重マージを防げるの？
という質問への返答なので、なぜdarcsだと二重マージを防げるかを、パッチ集積パラダイムの点から説明していただけると、スレ的にはうれしい。

0159デフォルトの名無しさん

2008/12/24(水) 01:00:57

>>75
基本的な動作はいい感じだけど、やっぱり物足りない部分が多いかな

boostぶち込んでもレスポンスいいのはなかなか

0160デフォルトの名無しさん

2008/12/25(木) 21:41:44

git branch
すると
* (no branch)
というのがでてこまってます。どうやったらこれを消せるんでしょうか。
git branch -d '(no branch)
ではだめでした。
たすけてください！

0161デフォルトの名無しさん

2008/12/25(木) 21:58:15

>>160
rm -rf .git

0162デフォルトの名無しさん

2008/12/25(木) 22:13:22

>>160
一時的な無名ブランチなので、他をチェックアウトすれば消える。

0163デフォルトの名無しさん

2008/12/26(金) 02:45:27

git push したらこんなエラーが出た。

$ git push
Counting objects: 116, done.
Compressing objects: 100% (85/85), done.
Writing objects: 100% (112/112), 40.38 KiB, done.
Total 112 (delta 32), reused 54 (delta 0)
To [email protected]:username/project-name.git
8644ee0..dccb472 master -> master
! [rejected] experiment -> experiment (non-fast forward)
error: failed to push some refs to '[email protected]:username/project-name.git'

experiment ブランチでなにかエラーになっているようだけど、さっぱりわからん。
おしえてえらいひと。

0164デフォルトの名無しさん

2008/12/26(金) 14:12:20

そもそもマージは人間がやるべきだよ。
バージョン管理システムは構文は見ないわけだし。

0165デフォルトの名無しさん

2008/12/26(金) 19:41:07

>>163
fast forward出来ないってことは、誰かがあなたより先にそのブランチにpushした
ってことだと思う。
git fetch とか git rebase で真っ直ぐにする必要があると思う。
しかしgithubで誰かとブランチ共用してるのか。まあそういうやり方もありか。

0166デフォルトの名無しさん

2008/12/26(金) 22:48:11

自動のマージに任せるととんでもないことになるから、
必ず手動でマージしてから自動のマージを走らせて、
変わった所をチェックしてるわ。

0167デフォルトの名無しさん

2008/12/27(土) 13:37:26

>157の件だけど、誰もやりかけてるのはないって事でいいのかな？
この休み中に少しだけでも翻訳しようかなって感じなんだけど。
hgbookは、一度どっかに訳があがってたけど、今は無いみたい(?)

ちなみに、公式FAQの足りない所や英語版と食い違ってるところを訳そうかなぁと
思ってる。

0168デフォルトの名無しさん

2008/12/27(土) 13:53:04

gitって名前がダサイ。

0169デフォルトの名無しさん

2008/12/27(土) 13:54:44

>>166
svn以前のマージって確かにひどい。ゴミだったな、ありゃ。

0170デフォルトの名無しさん

2008/12/28(日) 13:18:44

>>169
CVSのマージで困ったことはないけど最近はもっと便利になってるの?

0171デフォルトの名無しさん

2008/12/29(月) 05:13:58

なってる。

0172デフォルトの名無しさん

2008/12/29(月) 10:48:16

具体的にはどう便利に？

0173デフォルトの名無しさん

2008/12/29(月) 11:40:02

git blame -M/-Cってすごいなぁとおもって
ソースみてみたけどロジックがわからんかった orz
ほかのvcにはないよねこういうの

0174デフォルトの名無しさん

2008/12/30(火) 19:56:59

>>173
いらないwww

0175デフォルトの名無しさん

2008/12/31(水) 16:04:33

Gitでコミットの順番をいれかえるのってどうしたらいいの？
なんかGitではそういうことができると聞いたんだけど。

0176デフォルトの名無しさん

2009/01/01(木) 15:03:39

Mercurial 1.1.2 release

0177デフォルトの名無しさん

2009/01/01(木) 15:14:46

>>175
大体こんな感じ。
git reset HEAD^
git stash save
git reset HEAD^
git stash save
git stash apply stash@{1}

でもこれで入れ替えられるのは多分、diffの範囲が十分に離れている場合だけ。
近すぎるとコンフリクトすると思う。

0178デフォルトの名無しさん

2009/01/01(木) 16:28:22

>>177
えー、むちゃむちゃ手作業じゃないですか。そういうものですか。
あとこの方法だと、ログメッセージも手作業で指定することになりますよね。

だまされたのかな。Git には、パッチの順番を入れ替える直接的な機能はないということでFA?

0179デフォルトの名無しさん

2009/01/01(木) 16:43:46

$ git rebase -i HEAD~2
で $EDITOR が起動する. 説明は書いてあるのでそのようにすればいい.
簡単にいえば行毎にコミットがかいてあるのでそれを入れ換えばいい.

0180デフォルトの名無しさん

2009/01/05(月) 11:07:46

TortoiseHGでアイコンオーバーレイは、TortoiseSVNが入ってないと使えなかったりする？

0181デフォルトの名無しさん

2009/01/05(月) 18:54:32

>>180
アイコンオーバーレイだけインストールできるよ。Hgは試したことないけどTortoiseBzrではうまくいった。
http://tortoisesvn.tigris.org/source/browse/tortoisesvn/TortoiseOverlays/

0182デフォルトの名無しさん

2009/01/05(月) 23:00:05

>>181
サンクス。明日会社でやってみる。

0183デフォルトの名無しさん

2009/01/05(月) 23:21:19

TortoiseHgはオーバーレイでるよ。
インスコ後OS再起動していないとか

0184デフォルトの名無しさん

2009/01/07(水) 11:12:45

git では $HOME/.gitconfig に alias が設定できます。
しかしたとえば commit の alias として ci を登録すると、zsh の補完が効かなくなります。
つまり、git commit なら効く補完が、git ci だと効かないわけです。
あたりまえといえば当たり前なんですけど、git commit での補完が git ci でも効くようにするにはどうしたらいいでしょうか。

0185デフォルトの名無しさん

2009/01/07(水) 11:22:45

zshのドキュメントを読めばいいんじゃない？

0186デフォルトの名無しさん

2009/01/07(水) 11:55:54

gitのページがかわいくなったw

0187デフォルトの名無しさん

2009/01/07(水) 14:40:33

どーもくんみたいのがバナーにいるな

0188デフォルトの名無しさん

2009/01/07(水) 14:41:18

Git - Fast Version Control System
http://git-scm.com/

0189デフォルトの名無しさん

2009/01/07(水) 15:00:40

ほんとだドーモくんに似てるｗ

0190デフォルトの名無しさん

2009/01/07(水) 21:18:57

なんできのこの山（抹茶味）食べてるん？

0191デフォルトの名無しさん

2009/01/07(水) 21:38:12

>>190
うまいからじゃね？

0192デフォルトの名無しさん

2009/01/07(水) 23:21:37

ドーモくんもGPLだったんだな。

0193デフォルトの名無しさん

2009/01/08(木) 03:28:19

どう見てもドーモくんです。

0194デフォルトの名無しさん

2009/01/08(木) 10:28:05

食べすぎて太ってるな

0195デフォルトの名無しさん

2009/01/09(金) 16:04:13

普段gitである程度まとまったらsf.netのsvnにgitの結果をなげるとかできる？

0196デフォルトの名無しさん

2009/01/09(金) 16:24:03

mercurialでaddを取り消すことはできない？
addまではできるが、ファイル名の関係でcommiit出来ないからaddを取り消したいんだが…。

0197196

2009/01/09(金) 16:29:01

申し訳ない。調査が足りなかった。
反省してる。

0198デフォルトの名無しさん

2009/01/09(金) 18:09:01

>>157
hgbookは ttp://freehg.org/u/honeyplanet/hgbook/ に作業中のが。

0199デフォルトの名無しさん

2009/01/09(金) 19:39:31

>>195
git-svnで出来るよ。
sf.jpなら直でGitいける。

0200デフォルトの名無しさん

2009/01/10(土) 02:14:40

>198
そのURL、公式wikiの日本語版トップページからリンクしとけばいいんじゃない？
存在を知らない人が二重に訳し始めたら無駄だし。

0201デフォルトの名無しさん

2009/01/10(土) 12:17:54

>>195
こんな感じかな

svn からごっそりclone
$ git svn clone rep_url -T trunk -b branches -t tags

svn の branch を確認して
$ git branch -r
svn の branch を git の branch に紐付けして checkout
$ git checkout -b git_branch svn_branch

git の local branch を作ってゴソゴソ作業
$ git branch local_branch

まとまったら、紐付けされた branch に戻って merge
$ git checkout git_branch
$ git merge local_branch --no-ff

svn に送る
$ git svn dcommit

0202デフォルトの名無しさん

2009/01/11(日) 18:47:34

一つ質問させてください。

今までmonotoneを使っていて、最近新しくgitを使い始めたのですが
monotoneでのcheckoutや、subversionでのexportのように
「ローカルレポジトリの内容を展開する」ことが可能なコマンドは無いでしょうか？

たとえば、カレントディレクトリに .git だけがあって、その他には何もファイルが無いとき

git export

と実行すれば、その位置にレポジトリの内容が展開される……
というような事がやりたいのですが、その方法が分からずに悩んでいます。

0203デフォルトの名無しさん

2009/01/11(日) 19:27:29

git checkout .

0204デフォルトの名無しさん

2009/01/11(日) 20:42:44

>>203
checkoutするとファイル一覧は表示されるのですが、実際に展開が行われている様子はありません

D　　file1
D　　file2
D
...

0205デフォルトの名無しさん

2009/01/11(日) 20:45:43

>>204
`.`

0206204

2009/01/11(日) 21:04:14

>>205
すみません、ピリオドを見落としていました。ありがとうございます！

0207デフォルトの名無しさん

2009/01/15(木) 06:43:22

http://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_1.html
間違いだらけで笑えるwww

0208デフォルトの名無しさん

2009/01/15(木) 08:00:33

分散型童貞の俺にどこが間違っているのかkwsk

0209デフォルトの名無しさん

2009/01/15(木) 09:13:46

そもそも中央リポジトリがなくてもいいのが分散型の意義じゃねーの？

0210デフォルトの名無しさん

2009/01/15(木) 09:32:15

>209
それ、ちゃんと記事に書いてあるじゃん。
で、どこが間違ってるの？

0211デフォルトの名無しさん

2009/01/15(木) 14:16:53

>>207
うーむ、TortoiseBzr のところで、いつのまにか Mercurial になってたのは笑ったけど、
個人的な見解含めて特におかしな記事だとは思えんがなあ。

0212デフォルトの名無しさん

2009/01/15(木) 17:13:31

>>207
文字コードの話はろくに設定もしないで言いがかりに近いんじゃないかね。

0213デフォルトの名無しさん

2009/01/15(木) 18:24:43

>>207
自分で使い込んでる感じがしないよね。どうしてもSVN中心に考えている感じ

0214デフォルトの名無しさん

2009/01/15(木) 18:38:04

HGの綴り間違えてるし相当適当じゃないかその記事

0215デフォルトの名無しさん

2009/01/15(木) 19:57:22

>>213
結論がSVNを中央リポジトリにしてクライアントを分散型にするのがいいとか言ってるやつだぜwww

0216デフォルトの名無しさん

2009/01/15(木) 22:40:59

間違いだらけ、とまでは行かないが使い込んでない感はあるなぁ。

結論だけは、・・・・・無いな。これは馬鹿。
道具を増やしたら、複雑になるだけだろうが・・・

0217デフォルトの名無しさん

2009/01/16(金) 00:50:27

git stash すると、一時的なコミットが作成されますよね？
連続してgit stashしてから、その順番を入れ替えてもとに戻したいんですけど、できますか？
git stash # 1 回目（小さめ）
git stash # 2 回目（小さめ）
git stash # 3回目（けっこう大きい）
git pop # ここで1回目と2回目のを先に戻してcommitしたい

こんな説明で伝わるかわかりませんが、もしご存知の方がおられましたらお願いします。

0218デフォルトの名無しさん

2009/01/16(金) 06:47:04

git stash list
git stash apply stash@{1}
git stash apply stash@{2}
git stash apply stash@{0}
みたいな感じか?

ただしindexが違うから確実にマージされるとは限らないので、
コンフリクトが出たら手動でマージする必要があると思う。

最近この辺のインデックスとかの挙動がようやく分かってきたが、まだまだ曖昧だな。

0219デフォルトの名無しさん

2009/01/16(金) 08:47:22

>>216
無理して話に加わらなくていいよ

0220デフォルトの名無しさん

2009/01/16(金) 12:26:56

>>218
サンクスコ
そうやって名前を指定できるのね。
git stash applyのかわりに、git stash popで名前を指定できるのかな。
試してみる。

0221デフォルトの名無しさん

2009/01/16(金) 14:22:38

manualを読めばちゃんと書いてあるのに。

0222デフォルトの名無しさん

2009/01/16(金) 19:01:30

TortoiseHgで指定のmergeツールを使う方法がよくわからないのですが、
教えていただけないでしょうか・
p4mergeを指定しているのですが、なぜか kdiff？とかいうのが立ち上がります

Mercurial.ini には、
[ui]
username = alpaca
merge = p4merge

[tortoisehg]
vdiff = p4merge

[extdiff]
cmd.p4merge = c:\soft\Perforce\\p4merge.exe

というような設定をしています。

vdiffの方は無事にp4mergeが立ち上がりようです。
（とはいえこちらも複数ファイル(3つ以上？)ある場合にまともに起動しなくて困ってます。
多くのエンコーディングに対応した複数ファイルを開けるvdiffツールあればオススメ教えてください）

0223222

2009/01/16(金) 19:53:45

TortoiseHgのmergeツールの件うまくいきました！
検索で引っかかったマニュアルしっかりよんだら理解できました

MergeToolConfiguration - Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/MergeToolConfiguration

どうもデフォルトの設定(hg showconfigで確認)ではレジストリからパス？を読むようになってまして、
以前のOSでインストールしたものをそのままこぴぺでつかってたため、おきたようです。
とりあえず、Mercurial.ini に以下を突っ込んだところ無事立ち上がりました。

[merge-tools]
p4merge.executable=c:\soft\Perforce\\p4merge.exe

ありがとうございました。

0224デフォルトの名無しさん

2009/01/16(金) 22:46:05

>>223
＞ありがとうございました。
何に？ｗ

0225デフォルトの名無しさん

2009/01/17(土) 03:48:35

まぁ人に説明してると解決するって事もよくある

0226222

2009/01/17(土) 16:37:38

> [merge-tools]
> p4merge.executable=c:\soft\Perforce\\p4merge.exe

p4merge.executable=c:\soft\Perforce\p4merge.exe

の間違いです。関係ないと思いますが、一応訂正

0227デフォルトの名無しさん

2009/01/17(土) 16:46:45

Mercurialの質問よろしいでしょうか？

特定のリビジョン間のパッチを取る簡単な方法（コマンド）はないでしょうか？
cloneして特定リビジョンにupdateして、双方でdiffとるしかないですかね？

0228227

2009/01/17(土) 17:01:13

TortoiseHgでいけました。
View changelog を開いて
特定リビジョンをクリックして選択、diffりたいリビジョンを右クリック→diff or visual diff
で特定リビジョン間の差分を見られました。

お手をわずらわせ失礼しました。

0229デフォルトの名無しさん

2009/01/17(土) 17:08:13

>>227
cloneは必要ないのでは？
リビジョン指定してupdateとdiffするだけでしょ。

0230デフォルトの名無しさん

2009/01/17(土) 21:21:14

>>229
updateもいらない。
hg diff -r REV1 -r REV2

0231デフォルトの名無しさん

2009/01/18(日) 13:28:52

GNOME DVCS Survey results
http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/

0232デフォルトの名無しさん

2009/01/18(日) 17:45:24

ありがたいことに日本語訳もある
ttp://tt25.org/blog/20090106/gnome-dvcs-survey

0233デフォルトの名無しさん

2009/01/18(日) 19:39:03

2009-01-18 TortoiseHg 0.6 (with Mercurial 1.1.2) released!

誰か試してみて。

0234196

2009/01/18(日) 19:47:16

>>233
試してみる。
結果は教えられない。

0235227

2009/01/19(月) 02:48:47

>>229-230
サンクス！diffでリビジョン指定できたのね。

0236デフォルトの名無しさん

2009/01/19(月) 05:30:45

hg で.hgignoreに追加する前に追加されたと思わしきファイルがあります。
（.hgignoreで一致しているパターンなのに、hg stででてくる）
そのファイルを後から無視することはできないのでしょうか？

一旦削除するしかないのでしょうか？

0237デフォルトの名無しさん

2009/01/19(月) 06:09:23

>236
hg remove --after でいけたはず。

0238196

2009/01/19(月) 15:13:17

TortoiseHG0.6入れたんだが、Commitツールが変わったっぽい？
addとかと同じUIになって日本語ファイル名も表示されてるんだが。

0239デフォルトの名無しさん

2009/01/20(火) 16:38:32

git commit
したときにviが起動するんですが、よく :wq ではなくて :q をしてしまいます。
つまり、コミットメッセージを書いたのに保存せずに終了してしまい、コミットされないことがあります。
自分のポカが原因ではありますが、viを終了したときに、保存してなければ Are you sure? とかなんとか、確認のメッセージを出すようにできませんか？
よろしくお願いします。

0240デフォルトの名無しさん

2009/01/20(火) 16:53:21

vi って、修正後保存せずに :q しても、「変更がほぞんされてねーぜ jk」て言われて
終了できないんじゃなかったっけ？無理やり終了は :q!
この安全策にはいつもお世話になってるけど。

0241デフォルトの名無しさん

2009/01/20(火) 17:22:53

いつもZZで終わらせてるなあ

0242デフォルトの名無しさん

2009/01/20(火) 18:32:49

>>240
あれ、そういえばそうですよね。
なんで git commit のときは確認してくれないんだろ？

0243デフォルトの名無しさん

2009/01/20(火) 22:17:07

>>242
なんでだろうね。EDITOR環境変数は何になってる？

0244デフォルトの名無しさん

2009/01/20(火) 22:39:28

>>243
$ ech $EDITOR

なにもなしでした。
環境依存っぽいですね。当方 MacPorts 1.7, git --version 1.6.1 です。

0245デフォルトの名無しさん

2009/01/21(水) 05:22:47

水銀本
ttp://www.amazon.co.jp/dp/4798021741

0246デフォルトの名無しさん

2009/01/21(水) 09:32:40

お、このオッサン頑張ってると思ったらついに本出したか。
でも心は Bazaar に傾きつつあったり…。

0247デフォルトの名無しさん

2009/01/21(水) 12:33:53

>246
何故傾いたのか聞きたい。

0248デフォルトの名無しさん

2009/01/21(水) 13:29:44

ファイル名

0249デフォルトの名無しさん

2009/01/21(水) 19:58:38

Bazaar本も出ないかなー

0250デフォルトの名無しさん

2009/01/21(水) 21:38:42

VisualStudioにhgのプラグインを組み込んでみたけど
思っていたよりも便利だな。

プラグインが何も入っていない状態だとVSにソース管理の
メニューが全く出てこないから、ろくな機能ないと思ってたw

ただ、今配布されてるhgプラグインはイマイチだね。
最新以外のリビジョンからソースを取り出せないし、
ドキュメントの類は一切無いからインストールの仕方も
よく分からなかった。

0251デフォルトの名無しさん

2009/01/22(木) 00:40:12

流行ってる割にgitの本も無いよな

0252デフォルトの名無しさん

2009/01/22(木) 01:10:45

gitの本はPragProgから出たばかり。

0253デフォルトの名無しさん

2009/01/22(木) 01:24:15

Prologに見えた

0254デフォルトの名無しさん

2009/01/22(木) 09:24:53

>>249
Bazaar は、Bazaar スレですばらしい翻訳ページが公開されたじゃないか。
ttp://sarabande.info/doc/bzr

0255デフォルトの名無しさん

2009/01/22(木) 12:42:26

>>254
なんじゃこれはー！
翻訳者GJすぎる

0256デフォルトの名無しさん

2009/01/22(木) 12:55:06

>254
でも、公式サイトからリンクして貰わないと、あんま意味ないよね。
ま、リンクされてても、いつも鯖落ちてるSubversion和訳の例もあるけど。

0257デフォルトの名無しさん

2009/01/22(木) 14:02:59

コミットIDを指定して git log -p することってできない？
git log -p 3a1b4c1de5926fgh4390
みたいにしてみたけど、そのコミットだけを見ることはできなかったっす。

0258デフォルトの名無しさん

2009/01/22(木) 14:07:14

>>257
できたよ。
IDの後ろ削ってみたらどう？

0259デフォルトの名無しさん

2009/01/22(木) 15:03:23

>>258
できないっすよ？他のコミットも混じってるよね？
バージョンによって違うのかな？
$ git --verion
git version 1.6.1

IDの後ろって何？

0260デフォルトの名無しさん

2009/01/22(木) 16:10:28

>>259
git log -p 3a1b4c1de5926fgh4390
↓
git log -p 3a1b4
という風にすること。
これでログが表示されなかったら3a1b4で始まるIDのコミットがそもそもレポジトリに存在しないことになる。

0261デフォルトの名無しさん

2009/01/22(木) 16:33:34

>>257
範囲指定は <since>..<until>。省略するとHEAD。
ということで、見たいやつの一個手前のIDも調べて

git log -p 一個前..見たいやつ

とかやればいいんじゃないかな。

0262258

2009/01/22(木) 16:40:49

ごめん、完全に勘違いしてた。
>>258 >>260は無視してくれ。
git show 3a1b4c1de5926fgh4390
ならそのコミット分だけ見れるよ

0263デフォルトの名無しさん

2009/01/22(木) 16:48:37

ベストな解は262が出してくれてるけど。

>>261
一個前のID調べなくてもいい。

git log -p 見たいやつ^..見たいやつ

で、いける。

0264デフォルトの名無しさん

2009/01/22(木) 17:10:52

何を言ってるのかよく意味が分からなかったが理解した。
git log -p -1 commit-ish
がしたいってことね。

0265デフォルトの名無しさん

2009/01/23(金) 01:31:00

なんかいろいろありがとう。
>>264 にある -1 オプションで、希望するものが見れました。さんくす。
ほかのひともありがとさんでした。

0266デフォルトの名無しさん

2009/01/23(金) 12:55:27

>>249
bazaarなんてCanonical関係者ぐらいしか使ってないのに、
本なんて出るわけないだろwww

0267デフォルトの名無しさん

2009/01/23(金) 13:58:45

日本語ファイル名に対応してくれればなぁ

0268デフォルトの名無しさん

2009/01/23(金) 13:59:20

あ、hg がって付けるの忘れた

0269デフォルトの名無しさん

2009/01/23(金) 16:20:10

>>268
Tortoisehgで日本語化けなくなったからこれでしばらく行くかな、俺は。

0270デフォルトの名無しさん

2009/01/23(金) 16:24:40

>>269
日本語ファイル名はutf-8で格納してくれる？

0271デフォルトの名無しさん

2009/01/23(金) 16:40:52

>>269
そのファイルを Linux で取り出しても化けてない？

0272デフォルトの名無しさん

2009/01/23(金) 18:49:15

http://www.python.org/dev/peps/pep-0374/
PythonってMercurialとGitとBazaarのミラーがあるんだな。

0273デフォルトの名無しさん

2009/01/25(日) 16:08:18

gitとMercurialとBazaarのうち一番今後見込があるのはどれですか？
ちゃんと生き残ってくれるものを使いたいです。

0274デフォルトの名無しさん

2009/01/25(日) 16:15:41

>>273
gitは死ぬこた無い。bzrもCanonicalがある限りは大丈夫だろう。hgは知らね。

0275デフォルトの名無しさん

2009/01/25(日) 16:16:35

>273
将来変換出来なさそうな、ややこしい機能は使わないようにすれば？

0276デフォルトの名無しさん

2009/01/25(日) 16:58:46

だれか、どれかひとつにコミットしたら、
ほかの種類のリポジトリにもコミットする仕組み作ってくれよ。

0277デフォルトの名無しさん

2009/01/25(日) 17:25:27

中央をsvnにすればクライアントはどれでもいけるんじゃね？

0278デフォルトの名無しさん

2009/01/26(月) 18:23:28

>>273
好きなのを選べばいい。
ただgitとmercurialはそれほど差はないけどbazaarは全然別物なんでそのへんは考えておいた方がいいと思う。

0279デフォルトの名無しさん

2009/01/26(月) 21:31:41

hg convert svn+ssh:// がエラーになるんだけど

0280デフォルトの名無しさん

2009/01/26(月) 22:04:22

>>278
どういうこと？　むしろgitだけが（インターフェース的に）別物なんだと思ってたんだけど

0281デフォルトの名無しさん

2009/01/27(火) 11:56:33

gitの質問です。

> git push
Counting objects: 11, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 717 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To [email protected]:foobar/project.git
2c1d0b7..2bcaea9 master -> master
! [rejected] README -> README (non-fast forward)
error: failed to push some refs to '[email protected]:foobar/projet.git'

これってどういうエラーですか？何が原因？

0282デフォルトの名無しさん

2009/01/27(火) 16:45:17

>>281
>>163
>>165

0283デフォルトの名無しさん

2009/01/28(水) 00:51:31

git/hg/bzrの中では総合的にみて結局hgに落ち着いた。

0284デフォルトの名無しさん

2009/01/28(水) 02:01:33

おなじく

0285デフォルトの名無しさん

2009/01/28(水) 02:43:52

意外。
流れを見るとbazaarなのかと思ったら。
是非理由を。

0286デフォルトの名無しさん

2009/01/28(水) 12:04:15

本が出た。

0287デフォルトの名無しさん

2009/01/28(水) 12:18:39

>>283
hg のどのあたりがよいの。当方bzr ユーザ。

0288デフォルトの名無しさん

2009/01/28(水) 12:21:23

何か変にbzrを持ち上げるレスがあって気持ち悪い

0289デフォルトの名無しさん

2009/01/28(水) 15:03:47

>>288
持ち上げるつもりがなくても、もちあがっちゃうんだとおもう。
俺も hg を使ったことあるけど、bzr の方が導入に際してのハードルがはるかに低い。
hg の場合だと色々調べてテストを重ねてようやく日本語も問題なく導入できた、という感じだけど、
bzr の方は何も考えずにコマンドをうったら使えた。
ftp などへのアップも簡単だし。

0290デフォルトの名無しさん

2009/01/28(水) 15:33:57

俺もhgのどこが良いか聞きたいなぁ。gitとbzrは使わざる追えないんだけど、hgだけは使う機会が無い。

0291デフォルトの名無しさん

2009/01/28(水) 15:38:08

ミスった。使わざるを得ない、ね。

0292デフォルトの名無しさん

2009/01/28(水) 15:39:22

svnとtracで充分

0293デフォルトの名無しさん

2009/01/28(水) 16:40:04

>>289
いま、Bazaar1.11付属のTortoise Bazaar(0.2rc0)で D:\新しいフォルダ\ に
リポジトリ作ろうとしたら、文字化けしたし、OKボタン押しても動作しなかった。

ちなみにTortoiseHg0.6で同じことをしたら、画面上では文字化けするものの
リポジトリは作れた。リポジトリのクローンは失敗した。

日本語関係の設定はどちらも何もしてない、はず。

日本語の扱いは、hgはもちろんだがbzrも完璧ではない模様。
(設定をちゃんとすれば動くの??)

0294デフォルトの名無しさん

2009/01/28(水) 16:49:50

いちいち日本語がどうとかチェックするの超うぜーよ

0295デフォルトの名無しさん

2009/01/28(水) 17:03:20

俺もhgに落ち着いたけど、ぶっちゃけどれでもいい。
ただ、VisualStudio用のプラグインがあったという点でhgになっただけだな。
git/bazaarの方が圧倒的にいいならプラグインくらいは自作するけど、
そこまで差がないからなぁ。

0296デフォルトの名無しさん

2009/01/28(水) 18:54:26

いずれにせよ、このスレであんまりBazaar主張するのは止めようぜ
俺もBazaar信者ではあるけれど
ここ最近の流れには、他のVCS（gitやHg）が下に見られているような雰囲気を感じる

>>293
それTortoiseBzrの問題

0297デフォルトの名無しさん

2009/01/28(水) 18:57:11

いや、そこはBazaar万能論を振りかざしてもらった方が、スレ的には議論が
盛り上がるだろ。

0298デフォルトの名無しさん

2009/01/28(水) 18:59:35

今までhghghghghghghghghghgって雰囲気だったのに
突然bzrbzrbzrbzrって言われてもキチガイが自演してるようにしか見えない

0299デフォルトの名無しさん

2009/01/28(水) 19:05:20

hgはファイル名の日本語対応はしないって開発者が明言したんじゃなかったっけ。

0300デフォルトの名無しさん

2009/01/28(水) 19:13:17

そのまま突っ込んでそのまま取り出せりゃ問題ねーだろという
開発側のマルチバイトコードへの認識の無さが露呈したね。
その後相変わらず状況に変化はないんだろうか。

0301デフォルトの名無しさん

2009/01/28(水) 19:17:49

誰か問題ありありですって実例添えて言ってくればいいんだろうけど

0302デフォルトの名無しさん

2009/01/28(水) 19:21:44

マイドキュメントのフルパスに必ず日本語が入るような

0303デフォルトの名無しさん

2009/01/28(水) 19:32:58

ユーザーアカウントが日本語だとマイドキュメントのフルパスに日本語が入るのか

0304デフォルトの名無しさん

2009/01/28(水) 22:04:07

なんだかんだいって、svn最強の地位はしばらく揺るぎそうにないな

0305デフォルトの名無しさん

2009/01/28(水) 22:08:06

日本語ファイル名でも同じ文字コード使ってるOSどうしでやりとりしてる分には問題は起きないよな？
(win32mbcsは必要だけど)
おかしくなるのはWindowsとLinuxの間でやりとりしたりする場合。

Subversionではこういうところで不安感じないからなぁ。

0306デフォルトの名無しさん

2009/01/28(水) 22:16:46

いちいち新しいバージョンのクライアントツールで、文字コード関連で問題がないかどうか
チェックするのに疲れました。

0307デフォルトの名無しさん

2009/01/28(水) 22:17:28

subversionでも、ファイル名がUnicodeで
NFDなファイルシステム(MacOS X)とNFCなファイルシステム(他)の間で
濁点付きカタカナとか扱うと面倒なことが起こる。
結局Unicodeつーてもファイル名をバイト列としてしか見てないんだよな。

0308デフォルトの名無しさん

2009/01/28(水) 22:39:59

hgはpython3移行でどうするかたのしみ

0309デフォルトの名無しさん

2009/01/28(水) 23:01:21

>>306
そう、それ。
俺も今のところ hg に落ち着いてるんだけど、正直もう疲れたってのがある。

0310283

2009/01/29(木) 00:30:07

時間をおいて見にきたらレスがいっぱいあって驚いた
hgに落ち着いた理由は以下の点
・git はコマンド体系が難しくて低能な俺には無理。
初心者に使い方を教えるのも難しい。
・bzrは期待も注目もしてるけど Tortoiseがまだ
実用レベルでないのと、ディレクトリも管理対象なのが
帰って面倒で俺にはデメリット。RHEL4上でソースからの
インストールがユーザ権限ではなかなかうまくいかず面倒。
標準で手軽なwebブラウジングサーバがない。
ブランチの仕組みがうちのプロジェクトとは肌が合わない。
svnに戻ったようなRev番号の付け方がちょっと気に入らない。
・hg は branchの扱いがうちのプロジェクトにあってる。
mqが逸品。たまたまプロジェクトに必要な機能であった。
コマンド体系が単純なので人に広めやすい、覚えやすい。
ちょうど日本語の本も出たしプロジェクトで採用しやすくなった。
インストールも楽だし、GUI(hgk)もすぐに使える点。
hg serveでWebブラウジングがすぐに使える点。
ディレクトリを扱わない点がプロジェクトにはあってる。
TortoiseHgは一応使えるレベル(TortoiseSVNには及ばないが)。

0311デフォルトの名無しさん

2009/01/29(木) 00:38:55

ここ最近のBzr系の書き込みは自演としかみえなかったしなぁ
Bzrはいいところは多いが、何もかもBzrの方がいいみたいな
書き込みは嘘過ぎる。

0312デフォルトの名無しさん

2009/01/29(木) 00:42:42

ついにbzrにもアンチが現れたとなればbzrも大きくなったものだ。

0313デフォルトの名無しさん

2009/01/29(木) 00:49:20

http://www.python.org/dev/bazaar/
>Experimental Bazaar branches
さてどうなるか。

0314デフォルトの名無しさん

2009/01/29(木) 01:00:13

>>310
ディレクトリも管理対象がデメリットってのが何故なのか気になる。
あとmqもrebaseあればいらないような。

0315デフォルトの名無しさん

2009/01/29(木) 01:02:42

あらかさまなアンチの書き込みは無いようだが。
あぁ、アンチとレッテル貼ってBzrを持ち上げようとしてるだけか。

0316デフォルトの名無しさん

2009/01/29(木) 01:05:34

アンチ乙

0317デフォルトの名無しさん

2009/01/29(木) 01:07:48

hq信者もbzr信者もUZEEEEEEEEEEEEEEE
gitこそが最強の勝者

0318デフォルトの名無しさん

2009/01/29(木) 01:09:24

darcsを忘れてもらっては困る

0319283

2009/01/29(木) 01:11:33

>>314
rebaseが目的じゃない使い方してる。
説明が難しいけど、他責の不具合の影響を
他の部分で一時的に対処するパッチをmqで
作って、直ってきたらパッチを廃棄して、
不具合対処の一時しのぎのコミットをしないように
することでソースをクリーンにしておくような使い方。

0320デフォルトの名無しさん

2009/01/29(木) 01:17:32

そういりゃhgのmqとhgのshelveとgitのstachとbzrのshelveってどう違うんだっけ。誰かおしえて欲しい。

0321デフォルトの名無しさん

2009/01/29(木) 05:58:23

>>310
> 標準で手軽なwebブラウジングサーバがない。
これ結構大きいよね
bzrwebは標準じゃないし、Pythonのライブラリ呼び出しがうまくいかずに動かなかったりするし

0322デフォルトの名無しさん

2009/01/29(木) 08:17:52

>>320
hgのmqに相当するのはgitのstgitじゃないか？

0323デフォルトの名無しさん

2009/01/29(木) 09:42:22

win/ubuntu bzr, mac/bsd hg, linux git
なんか勝手に各ユーザーのイメージ像。

0324デフォルトの名無しさん

2009/01/29(木) 10:58:14

svn + tracで不満ない

0325デフォルトの名無しさん

2009/01/29(木) 11:31:35

それは一番いらねー奴だな。

0326デフォルトの名無しさん

2009/01/29(木) 13:10:04

hgの日本語対応ってdirstate.pyのdirstate::writeとdirstate::_readでdirstate::_mapとdirstate::_copymapの
ファイル名の文字コードを変換すればいいだけじゃないの？

0327デフォルトの名無しさん

2009/01/29(木) 13:17:34

Windows野郎にはsvnしかない

0328デフォルトの名無しさん

2009/01/29(木) 20:28:05

そんなに問題か？
どうしても欲しかったらLunchPad使えばいいんじゃないの？

0329デフォルトの名無しさん

2009/01/29(木) 21:18:39

>>301
http://www.selenic.com/mercurial/wiki/index.cgi/InternationalizationPlan
気づいているがな

0330ヒロシ

2009/01/29(木) 22:11:19

初めまして。
初音ミクの曲を作っているのですが，画像はどうやって描けばいいのですか？？

0331デフォルトの名無しさん

2009/01/30(金) 00:33:17

>329
だいじょうぶなのかな。

> Things we're not sure about:
>
> * dealing with filesystem locales, especially on Windows

0332デフォルトの名無しさん

2009/01/30(金) 10:02:38

hgの感覚でgit pushしたんだけど
作業ファイルを更新するには?
hgならhg update相当のやつ

0333デフォルトの名無しさん

2009/01/30(金) 10:34:37

>>301
誰かが多言語対応のパッチ作って送りつけたら却下されたんじゃなかったっけ。

0334デフォルトの名無しさん

2009/01/30(金) 14:10:58

>>332
hg updateとhg checkoutは一緒でそれがgit checkoutに相当する…はず

0335デフォルトの名無しさん

2009/01/30(金) 16:07:31

Switching to Bazaar (bzr)
http://groups.google.com/group/mozilla.dev.apps.bugzilla/browse_thread/thread/8f1d9255845b3794

BugzillaがリポジトリをCVSからBazaarに変更しようとしているようだ。

0336デフォルトの名無しさん

2009/01/30(金) 19:56:15

Firefoxの開発プロジェクトとは合わせないのか。

0337デフォルトの名無しさん

2009/01/31(土) 19:18:09

水銀本ポチってみた。
たぶんあのおっさんが Web に上げてる情報をまとめたぐらいのもんだとは思うけど。
マージツールについての詳しい記述があるとありがたいな。

0338デフォルトの名無しさん

2009/01/31(土) 22:50:32

Mercurial本買ったよ。
前半はどこにでもありそうな分散管理の説明だけど、
後半の他環境とのやりとりがなかなか面白かった。

0339デフォルトの名無しさん

2009/02/01(日) 00:49:46

まああの本は確かにWebに上げてた情報をまとめただけの感はあるが、
初心者に読ませる本としては良いんじゃないかと思う。

0340デフォルトの名無しさん

2009/02/01(日) 12:58:11

それはない

0341デフォルトの名無しさん

2009/02/01(日) 16:13:21

本は仕事で使い始めたので買ったよ。
凋落しても移行ツールが用意されるはずだから安心しる
と書いてあってとても心配になった

0342デフォルトの名無しさん

2009/02/01(日) 20:12:34

おまいらはRCSを卒業してCVSも卒業してSVNも卒業して分散SCMを
使おうとしているのに、俺の会社の連中は、そもそもSCMの存在すら
知らん奴が9割を越える。

自称、世界で戦えるソフトウェア開発チームなのに。

そりゃ、赤字額が7時のニュースで報じられる訳ですよ。
誰も危機感持ってないけど。

0343デフォルトの名無しさん

2009/02/01(日) 21:13:25

腐ったRCS並のロック型ポリシーの市販ツールを押しつけられて日々イライラさせられているので
そういう何も知らない人間ばかりなとこのほうがまだ幸せに思える

0344デフォルトの名無しさん

2009/02/01(日) 21:32:59

俺も水銀本買った。
本は情報が集約されてて、オフラインでいつでも読めるのがいいよね。

0345デフォルトの名無しさん

2009/02/01(日) 22:42:57

>>343
このスレを見ないほうが精神的に安寧なんじゃまいか？

0346デフォルトの名無しさん

2009/02/01(日) 22:54:36

工作員がまぎれてます。

0347デフォルトの名無しさん

2009/02/01(日) 23:08:32

>>343
VSSですね、わかります。よーくわかります。

0348デフォルトの名無しさん

2009/02/01(日) 23:23:04

>>345
かもね。あんなツールでもそれしか知らない人間にとっては
ただ巻き戻せるというだけで便利なものだと思ってるらしいから

>>347
gitかsvnかってレベルじゃないのでねぇ・・・
ツールを選ぶ自由が欲しいっす

0349デフォルトの名無しさん

2009/02/01(日) 23:23:37

VSSって設定で多重coできるんじゃなかったっけか。
もう何年も使ってないけど。

0350デフォルトの名無しさん

2009/02/01(日) 23:24:30

VSSはロックなしにも出来るぞ。

0351343=348

2009/02/02(月) 00:23:47

私のほうはVSSじゃなくて別のツールなんでちょっと誤解させてすまんかった。>>349,350
で、そのツールでも多重チェックアウトとマージの機能はあるにはあるんだけども、そのマージの使い勝手が悪いし、
どっちにしろチェックアウト前にいちいちプログレスバーを出されるし、コメントがコミット単位じゃなくてファイル別に
表示されるので変更を追うのがわかりにくいしetcって具合にまぁ問題はそこだけじゃないんだ。
古くさいものがいたるところに残っててそれがデフォルトになってる。LinusはCVSを焼き直しただけのSVNなんて
ダメだと言ったけど、新しい知見に基づいた細かい改善点があるだけでも使い勝手は随分違うものになるものだと思うよ。

0352デフォルトの名無しさん

2009/02/02(月) 00:53:36

具体的な不具合がなければSVNで十分だと反論があるでしょう。
理想を追ってるんじゃなくて現実の対応に使ってるわけだしね。

0353デフォルトの名無しさん

2009/02/02(月) 01:31:45

SCMを知らないのが多いってことは、
自分の好きなSCMを広めるチャンスですよ。

0354デフォルトの名無しさん

2009/02/02(月) 05:47:06

それは言えてる。CVSを変に運用しちゃっている某所ではその変な運用故に
CVSにしがみつくしかなくなってしまっている。

0355デフォルトの名無しさん

2009/02/02(月) 09:53:37

水銀本ではそのあたり、「勝手 Mercurial 化のススメ」と称して
(コソコソと)併用する運用例が記載されています。
ま、まだ立場的にそんなもんでしょう、やっぱり。

0356デフォルトの名無しさん

2009/02/03(火) 23:01:36

>>353
そのせいでbzrを広めようとするアホが大量に沸いて困ってるんだがwww

0357デフォルトの名無しさん

2009/02/04(水) 01:57:48

>>356
なんかまずいの？

0358デフォルトの名無しさん

2009/02/04(水) 03:42:13

bzrは邪教。

0359デフォルトの名無しさん

2009/02/04(水) 04:43:35

ちょっと待て
自分が選んだSCMの人気が無いからって、他のを叩くんじゃない

0360デフォルトの名無しさん

2009/02/04(水) 14:18:19

file名をutf-8にするextentionがMLに流れてた。
http://www.selenic.com/pipermail/mercurial-devel/2009-February/010173.html

0361デフォルトの名無しさん

2009/02/05(木) 01:45:08

>>360
日本語だと特定の文字でエラーが出て使いもんにならんかった。

0362デフォルトの名無しさん

2009/02/06(金) 21:12:53

>>359
bzrなんて使っているやつなんていないだろwww
bzr使うぐらいならsvk使うわ。
機能的にほぼ一緒だしな。

0363デフォルトの名無しさん

2009/02/06(金) 21:47:58

さすがにそれはないな

0364デフォルトの名無しさん

2009/02/06(金) 23:12:07

もう俺が使ってるhgでいいだろ

0365デフォルトの名無しさん

2009/02/06(金) 23:32:32

gitで良くないか?

0366デフォルトの名無しさん

2009/02/06(金) 23:57:00

管理ディレクトリの名前はかぶってないんだから、内部でbzr, hg, gitを
パラレルに呼び出す bzrhgit を開発すれば丸く収まる。

0367デフォルトの名無しさん

2009/02/07(土) 00:04:12

svkでいいよもう

0368デフォルトの名無しさん

2009/02/07(土) 00:16:56

俺が本買った Mercurial でいいってば。

0369デフォルトの名無しさん

2009/02/07(土) 00:19:32

hgはwindowsでは使い物になりません。

0370デフォルトの名無しさん

2009/02/07(土) 03:43:18

俺が使ってるTortoiseHGでいいってばよ。

0371デフォルトの名無しさん

2009/02/07(土) 06:11:32

>>366
天才現る

0372デフォルトの名無しさん

2009/02/07(土) 08:16:39

TortoizeHGは枯れてなさすぎ

0373デフォルトの名無しさん

2009/02/07(土) 15:46:40

トータルハーゲーいつまともになんの？

0374デフォルトの名無しさん

2009/02/07(土) 15:58:24

>>372 >>373
少しはまともに名前を認識してやれよ。

0375デフォルトの名無しさん

2009/02/07(土) 16:30:32

トートイズヘイチジー

0376デフォルトの名無しさん

2009/02/07(土) 17:36:01

>>360
File "mercurial\demandimport.pyc", line 75, in __getattribute__
File "mercurial\demandimport.pyc", line 74, in __getattribute__
File "mercurial\demandimport.pyc", line 44, in _load
File "mercurial\demandimport.pyc", line 72, in __getattribute__
RuntimeError: maximum recursion depth exceeded in cmp

動かなかった

0377デフォルトの名無しさん

2009/02/10(火) 02:59:57

1.6.1.3

0378デフォルトの名無しさん

2009/02/10(火) 19:13:40

git darcs
emacsから使うならどっちがおすすめ？

0379デフォルトの名無しさん

2009/02/11(水) 05:26:28

Mercurial

0380デフォルトの名無しさん

2009/02/11(水) 13:29:31

bzr

0381デフォルトの名無しさん

2009/02/11(水) 13:59:22

arch

0382デフォルトの名無しさん

2009/02/11(水) 14:27:30

全部試すがいい

0383デフォルトの名無しさん

2009/02/11(水) 14:42:29

Unix系OSならな。
Windowsは試すだけ無駄。

0384デフォルトの名無しさん

2009/02/11(水) 14:47:46

Mercurialは良いと思うのですが、コマンド名はなんとかなりませんか？
ハゲハゲ言われて傷つくのですが。トータルハゲとかひどすぎます。

0385デフォルトの名無しさん

2009/02/11(水) 14:51:51

亀水銀

0386デフォルトの名無しさん

2009/02/11(水) 15:15:44

ハゲは新しいな。ｗ

0387デフォルトの名無しさん

2009/02/11(水) 16:09:59

>>384
ヘゲって読めばおｋ

0388デフォルトの名無しさん

2009/02/11(水) 16:34:44

>>384
あれはハイグレードの略

0389デフォルトの名無しさん

2009/02/11(水) 16:44:09

ひぎぃ

0390デフォルトの名無しさん

2009/02/11(水) 16:49:40

トータルハゲわらた
俺もトータルハゲつこうとる

0391デフォルトの名無しさん

2009/02/11(水) 18:25:42

そもそもなんでtortoiseって名前なのよ？
センスねー

0392デフォルトの名無しさん

2009/02/11(水) 20:21:46

おまえはウルフルズファンを敵に回した

0393デフォルトの名無しさん

2009/02/12(木) 10:02:08

あんなグループいらんわい。

0394デフォルトの名無しさん

2009/02/12(木) 10:28:51

>>393 = >>391
なに無理してんの？

0395デフォルトの名無しさん

2009/02/12(木) 10:53:41

日本人から見ると、書きにくく読みにくい名前なのは確か

0396デフォルトの名無しさん

2009/02/12(木) 10:57:39

tortoise読めなかったり読み間違えたりして恥かいたことがあるとか

0397デフォルトの名無しさん

2009/02/12(木) 11:18:29

>>396
読み違えてるやつ多数なので恥とは思わなかったり。
難読漢字と同じで知らなきゃ読めないし。

0398デフォルトの名無しさん

2009/02/12(木) 11:21:44

とーたすって読む人ととーといず（す）って読む人がいる

0399デフォルトの名無しさん

2009/02/12(木) 12:14:06

>>396
おもいっきり「とーといす」って言ってましたよ。 z_/o
比較的早く辞書で調べたんで、1、2人でしたが(たぶん)。

まあご多分にもれず、バージョン管理システム使うのが少数派な
職場だったのも、このときだけは幸いしたということかな。

0400デフォルトの名無しさん

2009/02/12(木) 13:33:06

いやでもロゴが亀なんだから気づくだろjk

0401デフォルトの名無しさん

2009/02/12(木) 15:16:57

亀は「タートル」だけだと信じて疑ってなかったんだよ、常考。

0402デフォルトの名無しさん

2009/02/12(木) 15:17:05

Are Those Turtles?

Why, yes, they are, indeed, turtles. That's the animal chosen by the
publisher for our book cover. And before you ask us, "Why?" 丕ｹ we
don't really know. It's cool, and our wives are pleased that at least
something "icky" wasn't chosen to represent Subversion.

http://svnbook.red-bean.com/index.en.html

0403デフォルトの名無しさん

2009/02/12(木) 15:27:15

漏れは亀を意味する英単語としてタートルよりトータスの方を先に覚えてたな

0404デフォルトの名無しさん

2009/02/12(木) 15:33:56

tortoise head

0405デフォルトの名無しさん

2009/02/12(木) 16:32:05

何のスレかわからなくなってまいりました。

0406デフォルトの名無しさん

2009/02/12(木) 21:37:40

トータスって聞くとゾイドを思い出す。どうでもいいが。

0407デフォルトの名無しさん

2009/02/12(木) 22:19:39

カノントータス→タートルズの順で覚えた。

>>399
トータスと読むんだよと言ってるのに
頑なにトートイスと読んでる人がいるから大したことない。
辞書を引けば一発なのに…

0408デフォルトの名無しさん

2009/02/12(木) 22:47:33

トータスってトータルぽく聞こえるだろ！ハゲを合わせて考えろよ。
トートイスハゲ＝？
トータルハゲ＝全天頂禿？

0409デフォルトの名無しさん

2009/02/12(木) 23:14:57

>>402
よくわからないけど、妻が喜ぶから亀だって？

0410デフォルトの名無しさん

2009/02/13(金) 00:15:55

トートイズでいいじゃない

0411デフォルトの名無しさん

2009/02/13(金) 00:17:58

【char】変な読み方するなその２【ちゃー】
http://pc11.2ch.net/test/read.cgi/prog/1177251487/

0412デフォルトの名無しさん

2009/02/13(金) 00:22:26

母音がoiと繋がってるあたりを見て、フランス語風にﾄﾙﾄﾜｰｽﾞと読むのかと思った。

0413デフォルトの名無しさん

2009/02/13(金) 08:13:47

Longman 2005 Voice Packageで発音聞いたら、トーテェスだな

0414デフォルトの名無しさん

2009/02/13(金) 08:37:39

また何のスレかわからなくなってきました。

0415デフォルトの名無しさん

2009/02/13(金) 10:37:37

>>411
そう。
何かしんないけど、みんなcharをちゃーって呼ぶ
きゃらって読むと不快な顔される

0416デフォルトの名無しさん

2009/02/13(金) 18:31:05

私の会社では今までバージョン管理ツールが使われておらず、共有ファイルサーバに
各自でファイルの上書き更新という原始的な開発をやっていました。

この度ようやくバージョン管理ツールを入れてみようということで、いろいろ調査して
いるところです。

モノ自体は長所と短所を考えながら検討中なのですが、仮にsvnを使うとします。
完全にWindows環境で使用する場合、かつアクセス権やセキュリティを考える必要が
全くない場合、ファイルサーバの共有フォルダにリポジトリを置いて、各自がTortoiseSVNのfile:///でアクセスを行う運用形態に問題点はあるでしょうか。

個人的にはsvnserverを起動させて、svn://でアクセスした方が安全なように
思うのですが、サーバはウチの部署だけのものではないので、勝手にアプリを
インストールすることはできません。

0417デフォルトの名無しさん

2009/02/13(金) 21:06:53

>>416
http://tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-repository.html#tsvn-repository-local-share

0418デフォルトの名無しさん

2009/02/13(金) 23:23:44

SVNは稼動が始まったら2度と離れられないくらいべんりだよ。
いますぐはじめるんだ！

0419デフォルトの名無しさん

2009/02/13(金) 23:27:57

ぎっと、はげ、ばざー、とかいうけどSVNだけはガチなんでしょ？

0420デフォルトの名無しさん

2009/02/14(土) 03:20:33

>>416
UNIX系サーバがあるなら、そこでやったほうが無難かと…。
SSHが動いていれば、別にroot権限は一切なくても、誰かさんのホーム以下でバイナリをコンパイル
して、リポジトリを作って、各自パスを通せばsvn+ssh://で使えるし。

あるいは、coLinux上でやってもいいし。

＞ファイルサーバの共有フォルダにリポジトリを置いて、各自がTortoiseSVNのfile:///でアクセスを行う
これは最悪級に危険なのでやめましょう。
ネットワークファイルシステムは、かなり同期処理がルーズですから、
同時アクセスで余裕でリポジトリがぶっ壊れます。

0421デフォルトの名無しさん

2009/02/14(土) 05:19:50

>>420
わりと長いこと samba 共有上 file://server/share/... で使ってるプロジェクトがあるけど、
同時アクセスで壊れたことは無いなぁ。

ただ、うっかり誰かがリポジトリを移動（たぶんエクスプローラでうっかりドラッグ）しちゃって
寿命が縮む思いをしたことはあるので、やっぱりおすすめできない。

0422デフォルトの名無しさん

2009/02/14(土) 11:38:40

一を見て百を知った気になる

0423416

2009/02/14(土) 12:48:19

皆様アドバイスありがとうございます。
>>417様のリンクは、真っ先に見るべきところでした。申し訳ありません。

何にせよ、やはり共有ファイルサーバのfile://アクセスは避けるべきですね。
個人ブログでいくつかこのような運用を見たので、もしかしたら普通にできるのかも
と考えてしまいました。

やはり、サーバ管理者を説得するようにしてみます。

0424デフォルトの名無しさん

2009/02/14(土) 15:52:29

>>423
利用者が全員Windowsなら文字コードの問題も起きないし、
MercurialやGitをCGIで運用してみたら？
既にWebサーバが動いていることが前提だが。

あるいは、サーバ管理者の許可を取って、自分の部署にサーバを
1台置かせてもらうとか。

0425デフォルトの名無しさん

2009/02/14(土) 16:49:26

サーバって言っても、十中八九余っているWindowsマシンの共有フォルダをつかっているだけだと思うぜ

0426デフォルトの名無しさん

2009/02/14(土) 16:53:41

部署内サーバーとか作ったら駄目なの？

0427デフォルトの名無しさん

2009/02/14(土) 17:46:43

bitbucket登録してみたんだけどutf-8以外のソースをブラウザで見ると
化けるのはどうしようもない？

0428デフォルトの名無しさん

2009/02/14(土) 18:20:28

>>424
おいおい、Windowsでhgやgitを薦めるなよ

0429デフォルトの名無しさん

2009/02/14(土) 18:25:38

なんかまずいんですか？

0430デフォルトの名無しさん

2009/02/14(土) 18:32:50

SVNのがGUIで操作できてべんりじゃね？

0431デフォルトの名無しさん

2009/02/14(土) 18:42:41

>>429
趣味でやるんじゃねーんだよ

0432デフォルトの名無しさん

2009/02/14(土) 18:43:36

Windowsなら、TortoiseSVN以外ありえんでしょ、今なら。

0433デフォルトの名無しさん

2009/02/14(土) 18:46:59

>>429
職場のチーム開発でhgやgitを勧める理由なんかないだろ

0434デフォルトの名無しさん

2009/02/14(土) 18:47:54

集中砲火ﾜﾛﾀ

0435416

2009/02/14(土) 18:55:59

更なるアドバイスどうもです。
お察しの通り、ウチのサーバはWindows2000 Server（古っ!）で、パブリックフォルダを共有にしている
だけです。

ただ、それでも一応管理者が定期的なバックアップを取っていて、ここにファイルを置いている限りは
物理的な障害に関しては管理者が全責任を持ってくれます。
部署で運用するPCは基本的には部署で責任を持たなければならなくなるので、なるべく会社の資産と
なるようなデータ・コードは共有ファイルサーバに置くのが決まりごとみたいになってます。

こちらでもう少し調べた結果、別にsvnサーバPCを立ち上げて、rootをファイルサーバの共有フォルダに
する方法を考えてみました。
あまり聞いてばかりでは申し訳ないので、テスト用PCで試行錯誤してみます。

0436デフォルトの名無しさん

2009/02/14(土) 19:08:03

念のため言っとくけど、バックアップはファイルコピーじゃ駄目だからな。

0437デフォルトの名無しさん

2009/02/14(土) 19:28:30

>>428 >>431-433
詳しく

>>435
HTTPサーバーやSSHサーバーが社内にあるなら、Bazaarを使って
既存のサーバーを流用するという手もあるよ

0438デフォルトの名無しさん

2009/02/14(土) 19:32:49

SVNなら事務の人間でも使ってるよ。ｈｇやらなんやらってのも使ったことないけどそのくらい敷居低い？

0439デフォルトの名無しさん

2009/02/14(土) 20:54:26

>>435
部署で責任持ってサーバーくらい管理すりゃいいじゃん。
決まり事じゃなくて、誰も出来ないやれないだけだろｗ

0440デフォルトの名無しさん

2009/02/14(土) 20:56:28

>>438
分散型でも集中型と同じ中央リポジトリ運用ができるものもある
gitはできる

0441デフォルトの名無しさん

2009/02/14(土) 21:11:00

bzrの融通の利き方は異常。

0442デフォルトの名無しさん

2009/02/14(土) 21:12:40

GUIが使えるかどうか返事はないのかと。

0443デフォルトの名無しさん

2009/02/15(日) 00:08:54

Windows、バージョン管理未経験。
この条件下なら、いまのところはTortoiseSVN一択だな。

gitは論外、TortoiseHgは日本語化ける、TortoiseBzrは未完成すぎ。
また、TortoiseHgもTortoiseBzrもコマンドラインでないとできないことが多々ある。

全員コマンドラインOKなら、正直どれでもいいな。

0444デフォルトの名無しさん

2009/02/15(日) 00:32:43

Mercurialのことちょっと聞きたいのだけども、
hg mv hoge newhoge
って存在意義あるの？
マニュアル見たら削除して追加するだけ、とか・・・
普通にリネームしてもいいじゃん、みたいな

0445デフォルトの名無しさん

2009/02/15(日) 00:46:06

ヒストリを持ったまま移動させるには copy して remove すれば十分ってこったろ

単に（ファイルシステム上で）リネームしただけだとヒストリが受け継がれない

0446デフォルトの名無しさん

2009/02/15(日) 00:55:55

え？？？？

何がいいたいかというと、
hg mv すると差分が追えないんですよ。
CSVもSVNもこのような悪い仕様をかかえていたというのに、何故こうなってるんだろう。
diff(patch)形式の仕様との互換性のため？

0447デフォルトの名無しさん

2009/02/15(日) 00:56:37

ごめんtypo、CSV→CVS

0448デフォルトの名無しさん

2009/02/15(日) 01:19:02

>446
Subversion も move は copy して remove だが、履歴は追える。
「差分が追えない」ってのはどういう意味だ？
変更履歴として「リネーム」として表現されて欲しいってことか？

0449デフォルトの名無しさん

2009/02/15(日) 01:41:09

>>446
hg diff -g
hg log -f file

0450デフォルトの名無しさん

2009/02/15(日) 02:31:27

>>449
うおいけるね
なんだTortoiseHgが対応してないだけか・・・

0451デフォルトの名無しさん

2009/02/15(日) 08:41:56

>>420
>同時アクセスで余裕でリポジトリがぶっ壊れます。
いまだにBDB使ってるやつがいるんだなwww

0452デフォルトの名無しさん

2009/02/15(日) 10:19:37

BDBは論外だけど　
ファイルロック系がまともに動かないのものは多いので
ファイル共有上で動かすなってのは正解というか基本だと思うが。

0453デフォルトの名無しさん

2009/02/15(日) 10:56:52

ハゲの日本語対応まとめたサイトとかない？

0454デフォルトの名無しさん

2009/02/15(日) 13:35:35

藤原のオッサンのとこぐらいかな？
ttp://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial.html
それでもちょっと古くなってきてるようだけど。

0455デフォルトの名無しさん

2009/02/15(日) 16:22:10

>>451-452
SVNは今デフォのリポジトリ形式（LSFS？）だと一応は大丈夫みたいなドキュメントに記述があったな
どこだっけか・・・

0456デフォルトの名無しさん

2009/02/15(日) 16:29:18

>>453
>>454はちょい古いので、Mercurial 日本語とかで合わせて検索した方がいいっす
そのページ見ててみ、どこだったかでハマった覚えがあるので

0457デフォルトの名無しさん

2009/02/15(日) 17:33:33

分散型を日本語Windowsで使おうと思うと

git … Windows? 日本語? ｼﾗﾈｰﾖ　って感じｗ
　cygwinあるいはmsysで使えるが…。日本語はUTF-8 cygwinで使えるんだろうか？
　Unix系でのユーザー数は圧倒的。

mercurial … とりあえずmbcs extensionで、\混じりでも使えるようになる。
　でもUTF-8のUnix系との相互運用は無理。
　Tortoiseは日本語対応してないらしい？。

bazaar … パスをUnicodeで保存するので、仕様上はWindowsだろうが日本語だろうが、相互運用も問題ないはず。
　しかしユーザー少なくて情報が今ひとつ…。
　やはりTortoiseは日本語対応してないっぽい。

svk … バックエンドがSubversionそのものなので問題なく使える。
　TortoiseSVNも使えるが、リモートとのやりとりはコマンドラインでやるしかない。

現状こんな感じか？
最近忘れられがちだけどsvkも悪くないと思う。

0458デフォルトの名無しさん

2009/02/15(日) 17:38:48

TortoiseSVN+svk以外は、調べたり試行錯誤したりするだけ時間の無駄

0459デフォルトの名無しさん

2009/02/15(日) 18:51:52

エンジニアでなければね。

0460デフォルトの名無しさん

2009/02/16(月) 00:07:05

>>457
UTF-8 cygwin でLinuxとWindowsで相互運用してるが、コマンドラインで
使う分には、log diffでの日本語の扱いや、日本語ファイル名についても
今のところ問題無い。
逆にWindowsでしか使わないなら(パスがShift-JISで記録されていいなら)
TortoiseGIT+msysgit は現時点ではSVN以外のTortoise系で一番使えると思う。

0461デフォルトの名無しさん

2009/02/16(月) 15:46:19

http://d.hatena.ne.jp/secondlife/20090213/1234502842
Bazaar全否定ということでいいですか？

0462デフォルトの名無しさん

2009/02/16(月) 16:42:14

>>461が何を言ってるのかよく理解できない

0463デフォルトの名無しさん

2009/02/16(月) 17:50:22

msysgitをファイル名をUTF-8で格納するように改造したら最強かな？

0464デフォルトの名無しさん

2009/02/16(月) 19:31:35

バージョン管理システムって、差分を積み重ねているとすると、
途中の一つの版を取り出す時、内部ではそれまでの複数の差分を一気に適用しているの？

0465デフォルトの名無しさん

2009/02/16(月) 21:20:14

>>463
TortoiseGIT+UTF-8 Cygwinも可能だけど、UTF-8にするとGUI関係がバケまくる。
まぁ日本語ファイル名をGUIで使うなら、TortoiseHGやTortoiseBzrが対応するのを待ったほうがいいかな。

0466デフォルトの名無しさん

2009/02/16(月) 23:10:36

>>464
sccsは最初の版からの履歴を保存する。
RCS/CVSは最新の版からの履歴を保存する。
これらの場合は、一気に適用するように実装されている。
それ以降のDBを使うVCSの場合はしらね。

0467デフォルトの名無しさん

2009/02/16(月) 23:38:33

>>465
Mercurialはファイル名に関してGitと同じポリシーなんだし、日本語ファイル名に
正式対応するのを期待するものではないと思う。
個人的には、ファイル名はUTF-8で格納してほしい&cygwinには頼りたくないから、
gitやhgを使うなら自分でUTF-8化するな。
今のところBazaarで問題ないけど。

0468デフォルトの名無しさん

2009/02/16(月) 23:55:04

>461
はてなは、Subversionのバックアップを取ってなかったのか？
RAIDが有ればバックアップ要らないよ派の人なの？

0469デフォルトの名無しさん

2009/02/17(火) 00:37:50

>>462
bazaarにgitのbranchに相当するものがないと言いたいんじゃないの？

0470デフォルトの名無しさん

2009/02/17(火) 06:03:53

>>466
「最新の版からの履歴を保存する」というのを理解できてないんですが、
一気に適用するとなると、版を重ねる毎に重くなっていきそうですね。

0471デフォルトの名無しさん

2009/02/17(火) 07:06:52

>>469
gitは触った程度で、本格的に使ってないんだけど
gitのブランチとbazaarのブランチの違いって何？

0472デフォルトの名無しさん

2009/02/17(火) 07:53:06

>>470
RCSなどでは最新版は(ほぼ)丸ごと管理ファイルに収容されているので、最新版を取り出すのが最速になるということ。
sccsでは、最新版は差分を辿らないといけないので版を重ねる毎に最新版を取り出すのが遅くなっていく。

0473デフォルトの名無しさん

2009/02/17(火) 09:46:55

>>471
bazaarのbranchはgit(hgもか)のcloneに相当するもので
gitやhgのbranchに相当するものは無いということかな

0474デフォルトの名無しさん

2009/02/17(火) 16:31:37

hg->ﾊｹﾞ
bazaar->ｻﾞﾏｱｰｰ
bzr->ﾌﾟｹﾞﾗ
ここまで読み替えできてるんだがgitのいい候補がみつからない。

0475デフォルトの名無しさん

2009/02/17(火) 16:52:13

>>472
「最新の版からの履歴を保存する」というと、
コミット時にこれまでの全ての差分を毎回更新しなければいけない感じが
するのですが、そんなことはないですか？
もしそうだとすると最新版を取り出すのは速くても、コミットはやはり遅くなりますね？

0476デフォルトの名無しさん

2009/02/17(火) 17:01:26

>>475
大丈夫、前回以前の差分はそのままでいい。

0477デフォルトの名無しさん

2009/02/17(火) 17:18:09

>>476
あ、なるほど・・・そうですね。どもども。

0478デフォルトの名無しさん

2009/02/17(火) 20:29:23

git でリビジョンの範囲を指定するのって「..」でできなかったっけ?
git revert HEAD^^^..HEAD としたら
fatal: cannot find 'HEAD^^^..HEAD' となった。

0479デフォルトの名無しさん

2009/02/17(火) 20:48:04

いや、そもそもgit revertで複数のリビジョンを指定できるのか？

0480デフォルトの名無しさん

2009/02/18(水) 00:01:26

gitは前の版をまるごとzipして保存してたと思う。
これなら任意の版との差分も定数オーダーでできる
最近はハードディスクも無駄にでかくて余ってるしいい判断だと思った

0481デフォルトの名無しさん

2009/02/18(水) 01:07:59

バージョン管理システムはとても便利なんだが
logを見直して「ああ自分はこの日のこの時間にこんなことをやってたんだな」と分かることが
逆に暗い気分を呼び覚ますことがある

たとえば3日間朝から晩までプログラミングしてたとかですね

0482デフォルトの名無しさん

2009/02/18(水) 01:27:29

>474
・嫉妬
・自慰
・自慰人
・油gitる

ちなみにgit=ばか者、愚か者、あほ、間抜け
ttp://eow.alc.co.jp/git/UTF-8/?ref=gg

0483デフォルトの名無しさん

2009/02/18(水) 22:05:06

このスレ的には、ClearCaseって糞ですか？
値段だけは金塊以上の価値みたいですが…
こんなもん導入する漏れの会社は終わりですか？

0484デフォルトの名無しさん

2009/02/18(水) 22:45:07

>>483
糞です
そうです
終わりです
こう言えば君の心は満足するのかい？

0485デフォルトの名無しさん

2009/02/18(水) 23:42:30

糞かどうかは自分で使ってみて判断すればいいだろう
俺は有料のバージョン管理システムでこれといった物を知らないが

0486デフォルトの名無しさん

2009/02/18(水) 23:52:32

ClearCaseはやる気をなくすほどゴテゴテしてるからなあ。
使いこなせないと猫に小判。使いこなしてもそんなに価値は感じないけどｗ

集中管理ならsubversionのがとっつきやすいし実用性十分。

0487デフォルトの名無しさん

2009/02/19(木) 00:13:11

>>483
プロジェクトの規模にもよるんじゃないかな。
大規模なプロジェクトで、ClearQuest と一緒に使うとガッチリと使い方が縛られるから、
管理しやすくなる。猫も杓子も使い方が同じになるからね。

でも、小規模なプロジェクトで開発者間である程度共通認識が出来上がっているプロジェクトでは、
そのガチガチに縛られるのが大変苦痛になるときがある。

まぁ、結局のところ何を主眼においているかだと思うよ。
バージョン管理のみに主眼をおいていると、ClearCase は確かに大仰になる。

0488デフォルトの名無しさん

2009/02/19(木) 11:05:56

達人プログラマーに「今すぐバージョン管理システムを使い始めましょう」と書いてあったんだけど
実際どこからどういう風にはじめるか書いてないところが親切極まりない本だぜ！・３・；
っていうか、タイトルどおり初心者の読む本じゃないな、これ･･･

0489デフォルトの名無しさん

2009/02/19(木) 11:51:01

>>488
手取り足取り教えないとわからないヤツは達人の入り口にもまだ来てねーよｗ
初めてならsubversion、ぐぐれば入門記事がいろいろ出てくる

0490デフォルトの名無しさん

2009/02/19(木) 21:25:08

最近どこでもとりあえずhg init, hg commit -Aって打っとくようになってきた

0491デフォルトの名無しさん

2009/02/20(金) 20:30:35

$ git co master
$ git merge experimental
error: Entry 'foo/bar/README' not uptodate. Cannot merge.
fatal: merging of trees a3595041b66ac7e627c64e79c6dcd66b9a954262 and b1a468cbcf693fd95c83fdd5cf25f317a0d4c782 failed

というエラーがでるんですけど、どうしたらエラーを解消できますか。

0492デフォルトの名無しさん

2009/02/21(土) 03:45:50

>>491
foo/bar/README って変更したけどコミットしてなかったりするんでは？
コミットしてからならマージできるんじゃないかな。

0493デフォルトの名無しさん

2009/02/21(土) 14:55:06

Windows版のMercurial コマンドライン版が日本語ファイル名のcommitに失敗するようです。
巨大なファイル郡で TortoiseHg がハングしたため、コマンドラインからコミットしたのですが、
日本語ファイル名のファイルが漏れてしまいます。
(hg add . 、 hg ci 後何故か、hg stで追加してないとできてしまう)

仕方ないので、残ったものだけTortoiseHgで追加しているのですが、
コマンドライン版で日本語ファイル名も追加、コミットする方法はないのでしょうか？

%HOME%\Mercurial.iniには、以下のように書いてあります・・・
[extensions]
hgext.convert=
hgext.win32text=
hgext.win32mbcs=

0494デフォルトの名無しさん

2009/02/21(土) 14:55:50

> (hg add . 、 hg ci 後何故か、hg stで追加してないとできてしまう)
(hg add . → hg ci 後何故か、hg stで追加してないファイルがある(日本語ファイルのもの)と言われてしまう)

0495デフォルトの名無しさん

2009/02/21(土) 15:04:26

対応策：WindowsでMercurialを使うのを止める

0496デフォルトの名無しさん

2009/02/21(土) 15:17:42

とりあえず、hg addで
　adding （日本語ファイル名）
とでてaddはされるけど、
hg ci でコミットができないみたいです。

hg ciした後、hg stするのですが、
　A （日本語ファイル名）
のようにコミットされていないことが確認できます・・・。

>>495
エエｴｴｪｪ(´Д｀)ｪｪｴｴエエ

0497デフォルトの名無しさん

2009/02/21(土) 15:21:28

・結論
日本語ファイル名なんて使うのやめる

0498デフォルトの名無しさん

2009/02/21(土) 15:28:14

うちはコード以外のリソースもVCSで管理してる関係上、日本語は使うなとは言えないんだよね。
で、結局WindowsではSubversionしか選択肢が無いと。

0499デフォルトの名無しさん

2009/02/21(土) 15:56:15

結論:
ソース以外のリソースはどうせ差分追跡なんてしないだろうからzipアーカイブしてしまう。
これなら中身が日本語のファイル名でも大丈夫。

0500デフォルトの名無しさん

2009/02/21(土) 16:12:08

Mercurialはエンコーディングの設定しても、
駄目文字含んだディレクトリでエラーになってしまう。
ファイルパスのエンコーディングの扱いに関して、
作者が根本的に勘違いしてるんじゃないかな。
Subversionは外人が作ったと思えないくらいまともに動いてくれて惚れ惚れする。
GUIクライアントはどうだか知らんけど。

0501デフォルトの名無しさん

2009/02/21(土) 16:12:09

結論（笑）

0502デフォルトの名無しさん

2009/02/21(土) 16:25:24

>>499
個別のファイルがいつ変更されたかも見れないなんて。
そこまでして使う理由があるのかと

0503デフォルトの名無しさん

2009/02/21(土) 16:40:09

バージョン管理ツールに「実際にファイルが変更された時刻」なんて記載されていないんだ。
ことがzipファイルになったからと言って、タイムスタンプを中身に合わせるだけで充分用が足りるだろ。
まさかとは思うが、zipアーカイブする作業を手作業で行なうなんて考えているわけじゃないよな。

# 寧ろ、フックスクリプトを用意するのが面倒とかそっち方面で突っ込まれると思っていたが……

0504デフォルトの名無しさん

2009/02/21(土) 16:44:36

コミットログ見ればこのファイルはどのリビジョンで更新されたかすぐわかるじゃないか
zipでまとめられたらそれがわからなくなるじゃないか。

0505デフォルトの名無しさん

2009/02/21(土) 16:44:59

503は普段 diff や annotate を使われない方のようです

0506デフォルトの名無しさん

2009/02/21(土) 17:06:33

結論　日本語が使えるVCSを使う

0507デフォルトの名無しさん

2009/02/21(土) 17:25:36

>>505
素朴な疑問だが、>498の言うコード以外のリソースでもdiffやannoするの?
それはどんなリソース?

私は「日本語のファイル名を持つ」「コード以外のリソース」だからブックファイルやdocファイルを想定したのだけれど。
# 後は画像とかもあるだろうけど、いずれにしてもdiff取れるような代物じゃないよなぁ……

0508デフォルトの名無しさん

2009/02/21(土) 17:29:49

つxdocdiff

0509デフォルトの名無しさん

2009/02/21(土) 17:51:51

結論: 日本語が使えるように自分でハックする

0510デフォルトの名無しさん

2009/02/21(土) 17:52:29

いちいちzipしてcommitとかありえん。

0511デフォルトの名無しさん

2009/02/21(土) 17:59:00

zipでやりたいやつはやればいいが、それを標準としてMercurialなどという屑ツールを勧めないでくれ。

0512デフォルトの名無しさん

2009/02/21(土) 18:00:30

Windowsで仕事で使うなら、現状Subversion以外の選択肢はないだろ。
分散やりたかったらsvkで。

0513デフォルトの名無しさん

2009/02/21(土) 18:11:04

禿同

0514デフォルトの名無しさん

2009/02/21(土) 18:11:49

Subversion使いたくない点はただ1つ
各ディレクトリに.svn作るダサさと、中央集権という点だけだ

0515デフォルトの名無しさん

2009/02/21(土) 18:12:28

Tortoise シリーズの完成度を抜きすれば Bazaar もありなんじゃね？

0516デフォルトの名無しさん

2009/02/21(土) 18:15:40

>>514
バージョン管理システムに慣れていない奴らを相手にするときは、
中央集権リポジトリの方が運用統制がとりやすいけどな。

0517デフォルトの名無しさん

2009/02/21(土) 18:18:16

>>515
仕事で使うのなら TortoiseBzr が使い物にならないのは致命的なのでは
全員が CUI 使ってくれるのならともかくとして

0518デフォルトの名無しさん

2009/02/21(土) 18:18:59

>>516
それに、使用者の学習コストを考えたときに、CSVやSubversionのモデルの方が理解が早い。
「ファイルサーバ上の共有フォルダ」というメタファーでいける。

0519デフォルトの名無しさん

2009/02/21(土) 18:20:15

WinCVS作ってたチーム（個人？）はどこ行ったんだ？
あれ結構出来が良かったのに。他のVCS用のクライアントも作ってほしいぞ。

0520デフォルトの名無しさん

2009/02/21(土) 18:21:42

eclipse+hgでも日本語だめだめなの？

0521デフォルトの名無しさん

2009/02/21(土) 19:28:42

GUI被せてバグることはあっても、逆は無いだろ。

0522デフォルトの名無しさん

2009/02/21(土) 21:16:43

つまり、生hgが駄目駄目ってことか。

0523デフォルトの名無しさん

2009/02/21(土) 23:08:53

日本語通らないってことはない。俺は使えてるし。
ファイル名が長すぎるとかじゃないのか？

0524デフォルトの名無しさん

2009/02/21(土) 23:18:53

通らないことがある、ってだけでもう致命的に駄目

0525デフォルトの名無しさん

2009/02/21(土) 23:27:43

ディレクトリ名に構とかソとか含めてコミットしてみろ

0526デフォルトの名無しさん

2009/02/22(日) 00:27:04

仕事で使う場合は、自分が気をつけてれば使えるってレベルだと駄目なんだってことが
どうしてわからないんだろう。

0527デフォルトの名無しさん

2009/02/22(日) 01:35:04

>>525
確かに化け文字はだめだな。
ファイル名の方は問題ないのになぁ。

0528デフォルトの名無しさん

2009/02/22(日) 07:42:04

>>522
そう

>>525-527
ファイル名もダメっぴ
いろいろ試したが、

x scripts/リンク処理/LINKに補助機能追加.js
x scripts/リンク処理/LINK先を強制表示.js
x scripts/検索/正規表現でページ内検索.js
o scripts/リンク処理/２ちゃんねる用ポップアップ.js
o scripts/リンク処理/IEで開く.js

"能""表"とかのダメ文字だな
hgの話ね

0529デフォルトの名無しさん

2009/02/22(日) 14:18:00

fixutf8使えばいいだろ

0530デフォルトの名無しさん

2009/02/22(日) 18:28:25

hg
ファイル名に0x5cがあると1.1から動かねー!!!!!
0x5cがあるとdelete返してきてファイルなしになってcommitできねーwwww
1.0.2に戻すと最新のリポジトリと互換性がないwwwwww

誰だよこんな糞仕様にしたやつはwwww

0531デフォルトの名無しさん

2009/02/22(日) 18:34:28

仕様じゃなくてバグじゃね？

0532デフォルトの名無しさん

2009/02/22(日) 18:43:29

>>530
そういうのは気づいた人が報告しないと直らないんだぜ。

0533530

2009/02/22(日) 18:50:56

>>532
俺に言うなwww

0534デフォルトの名無しさん

2009/02/22(日) 19:49:58

>>528
通らない文字みるとあからさまにバックスラッシュ関係だねぇ
"\"が2バイト目にあるマルチバイトが駄目ポ

0535デフォルトの名無しさん

2009/02/22(日) 19:54:48

pythonって割と低レベルなんだな。

0536デフォルトの名無しさん

2009/02/22(日) 19:57:36

hg
今のバージョンでもファイル名を直接指定すれば0x5cがあってもコミットできる。

0537536

2009/02/22(日) 20:00:01

ただし処理が昔のままなのでコミットできるだけで将来的には多分コミットできなくなるはずwww

0538デフォルトの名無しさん

2009/02/23(月) 08:43:01

早く bzr が熟成しないかな。hg 見限りたくなってきた。
コマンドが多少打ちにくいとか、少々動作が遅いぐらいかまやせんよ。

0539デフォルトの名無しさん

2009/02/23(月) 10:52:29

bzr自体は十分使える状態だと思うよ。tortoiseBzrとかbzr-svnとか
周辺ツールにまだ難があるけど。
ただ、bzrにgitやhg的なbranchが無いのが痛い。
svn的なbranchならcloneで十分だし、シンプルな実装は賛同できるんだけど、
何だかんだ言っても便利だからなぁ。

0540デフォルトの名無しさん

2009/02/23(月) 11:59:00

確かにBazaarを使ってると

master -> sub

こんな風にbranch切ったあと、subのファイルを編集してるつもりが
間違ってmasterの方を編集してしまうことがあって
こういう時には、ディレクトリ内容すげ替え方式のgit-branchがちょっと羨ましい

あともう一つ羨ましいのはgithub

0541デフォルトの名無しさん

2009/02/23(月) 12:28:15

bzrにはlaunchpadがあるからいいじゃない。
しかも今年中にオープンソース化される。
ただ、シンプルにレポジトリの管理だけをしたい時に
gitにはgitosisがあるのが有り難い。

0542デフォルトの名無しさん

2009/02/23(月) 14:51:48

>>535 hgがPythonの最低バージョンを2.4以降にしてくれればよかっただけのことなんだけどね。
>>538 成熟した頃には新しいバージョン管理ツールが出ていてそちらに目移りしているでしょう。

0543デフォルトの名無しさん

2009/02/23(月) 15:27:41

まあ英語圏の奴らが作ってるからいかんともしがたいな。

0544デフォルトの名無しさん

2009/02/23(月) 16:28:33

>>543
だが独自に修正することくらいはできる

0545デフォルトの名無しさん

2009/02/23(月) 17:33:03

parent: 7554:11a4eb81fb4f

diff -r 11a4eb81fb4f -r 5dd432f98473 hgext/win32mbcs.py
--- a/hgext/win32mbcs.py Tue Dec 30 22:10:41 2008 +0100
+++ b/hgext/win32mbcs.py Mon Feb 23 16:32:44 2009 +0900
@@ -44,6 +44,7 @@
import os
from mercurial.i18n import _
from mercurial import util
+from mercurial import extention, osutil

def decode(arg):
if isinstance(arg, str):
@@ -108,6 +109,17 @@
sjis s_jis shift_jis_2004 shiftjis2004 sjis_2004 sjis2004
shift_jisx0213 shiftjisx0213 sjisx0213 s_jisx0213'''

+def listdir_wrap(listdir, path, *args, **kwargs):
+ try:
+ path = decode(path)
+ if not path.endswith(os.sep):
+ path += os.sep
+ path = decode(path)
+ return listdir(path, *args, **kwards)
+ except: UnicodeError
+ raise util.Abort(_("[win32mbcs] filename conversion fail with"
+ " %s encoding\n") % (util._encoding))
+
def reposetup(ui, repo):
# TODO: decide use of config section for this extension
if not os.path.supports_unicode_filenames:

0546デフォルトの名無しさん

2009/02/23(月) 17:35:18

@@ -120,3 +132,5 @@
wrapname(f)
ui.debug(_("[win32mbcs] activated with encoding: %s\n") % util._encoding)

+ extention.wrapfunction(osutil,'listdir', listdir_wrap)
+
diff -r 11a4eb81fb4f -r 5dd432f98473 mercurial/util.py
--- a/mercurial/util.py Tue Dec 30 22:10:41 2008 +0100
+++ b/mercurial/util.py Mon Feb 23 16:32:44 2009 +0900
@@ -907,11 +907,11 @@
dircache = {} # dirname -> filename -> status | None if file does not exist
for nf in files:
nf = ncase(nf)
- pos = nf.rfind(sep)
- if pos == -1:
- dir, base = '.', nf
+ dir, base = os.path.split(nf)
+ if dir:
+ dir += sep
else:
- dir, base = nf[:pos+1], nf[pos+1:]
+ dir = '.'
cache = dircache.get(dir, None)
if cache is None:
try:

0547デフォルトの名無しさん

2009/02/23(月) 17:35:59

>>544
お前が修正しろよ

0548デフォルトの名無しさん

2009/02/23(月) 17:51:30

>>545
本家には送らないの？

0549デフォルトの名無しさん

2009/02/23(月) 17:54:41

>>548
windowsなんて持ってませんwww

0550デフォルトの名無しさん

2009/02/23(月) 18:50:03

>>545-546
ここに書き込んだコードの著作権は2chにある
取り込んでもらった後2chが訴えたら終わり

0551デフォルトの名無しさん

2009/02/23(月) 18:58:28

>>550
常識的に考えてバグの修正に著作権が発生することはないと思うが

0552デフォルトの名無しさん

2009/02/23(月) 19:24:56

mercurialってGPLじゃなかったか？

0553デフォルトの名無しさん

2009/02/23(月) 19:30:20

http://www.23ch.info/test/read.cgi/tech/1223709050/#a672

0554デフォルトの名無しさん

2009/02/23(月) 20:19:29

>>545
decodeを２回してるぞwww

0555デフォルトの名無しさん

2009/02/24(火) 00:37:33

>>545
ってか、修正してるバージョン古くね？

0556デフォルトの名無しさん

2009/02/24(火) 00:43:39

あーやっちゃったね。
そのパッチの著作権、2chに帰属しちゃった。

0557デフォルトの名無しさん

2009/02/24(火) 01:03:41

>>555
1.1.2じゃね？

0558デフォルトの名無しさん

2009/02/24(火) 01:41:21

>>557
あー。なるほど。
リポジトリの最新のバージョンみてたわ…

0559デフォルトの名無しさん

2009/02/24(火) 07:08:27

>>551
こと著作権に関して常識的にってのは通用しない
著作権法がすべて
そしてそれは常識とずれてるから世の中問題になってるわけで

0560デフォルトの名無しさん

2009/02/24(火) 10:34:22

>>559
BBSとかの規約もズレてる気はする

0561デフォルトの名無しさん

2009/02/24(火) 11:20:07

2chに帰属ってのも実際は争ってみないとわからないんじゃないの。

0562デフォルトの名無しさん

2009/02/24(火) 11:59:49

そういうのがめんどくさいから、パッチ書いたらどこかにアップしてURLを示すのが吉。

0563デフォルトの名無しさん

2009/02/24(火) 12:42:14

>>551
常識て。ｗ

著作権は著作物に自動発生するだけ。
バグがどうとか関係ない。

0564デフォルトの名無しさん

2009/02/24(火) 13:11:43

そのパッチ程度だと創作的と認められるか微妙かもしれんけどね。

0565デフォルトの名無しさん

2009/02/24(火) 13:57:05

ここに#include <stdio.h>とかi++;とか書いたらこれも2chのチョサッケーンになるのか

0566デフォルトの名無しさん

2009/02/24(火) 13:57:53

バカじゃねえの

0567デフォルトの名無しさん

2009/02/24(火) 15:49:22

取り込む側が、余計なリスクを負うかどうかの問題なんだよ

0568デフォルトの名無しさん

2009/02/24(火) 16:00:59

>>565
その程度だと著作物としての創作的表現に入らないから np

0569デフォルトの名無しさん

2009/02/24(火) 16:29:53

＞バカじゃねえの
は２ｃｈの著作物になりました

0570デフォルトの名無しさん

2009/02/24(火) 20:24:35

のまネコはavexの著作物

0571デフォルトの名無しさん

2009/02/24(火) 23:39:16

前提条件としての議論の余地が多分にあるが
仮に2chに書かれたコードがGPLのpatchであるとして、
仮に2chにそのコードの著作権があるとして、
そのコードが、GPLの派生である以上、GPLでなければならないならば、
2chが自らの著作物として、そのコードがGPLであると主張した場合、
どのような問題が発生するのだろうか？

0572デフォルトの名無しさん

2009/02/25(水) 01:23:29

日本語でおｋ

0573デフォルトの名無しさん

2009/02/25(水) 01:30:50

いつから著作権スレになったんだ？

0574デフォルトの名無しさん

2009/02/25(水) 02:03:58

スレ移動しようぜ、向こうは過疎ってるし。

こっちはこっちで
同じ話題を短い周期で
繰り返してる気がするけどなｗ

0575デフォルトの名無しさん

2009/02/25(水) 08:43:47

>>541
lanchpadはなんか規模がでかすぎる感じ。
インターフェースがわかりにくし、パッっとみ何するサイトなのか、なにしたらいいのかわからん。
githubとかBitBucket.orgみたいなコンパクトなリポジトリホスティングがほしす。

いってしまうと、googlecode projectみたいなのでいいんですよね。
それが、forkできればコラボが楽だなあ、という程度
(じゃあ、bzr-svnで(以下略))

あとlanchpadのサイト重いのもイヤイヤ感に拍車を掛ける。

lanchpadの利点がよくわからないから、どうしても否定的になってしまうな

0576デフォルトの名無しさん

2009/02/25(水) 08:45:25

そういえば、TortoiseGitってどうですか？
そこそこ使えますか？
日本語対応具合とか
TortoiseGitで足りない機能ある時はコマンドライン版は何使ってます？

0577デフォルトの名無しさん

2009/02/25(水) 10:48:28

>>575
Launchpad使ってるけど、その辺の意見には同意
Bazaarでの開発にはとても役に立つし、実際に便利に使わせてもらっているんだが
画面のゴチャゴチャ感と重さはどうにかならないかなーと思う
メニュー項目が必ず全部（使っていない項目も含めて）表示されることも、ゴチャゴチャ感を増している

ちなみにLaunchpadの利点は
・独自ブランチ→マージ提案が便利（ほかのホスティングでも似た機能はあると思うけど）
・共同翻訳（Translations）に強い
あたりかな

0578デフォルトの名無しさん

2009/02/25(水) 11:51:44

>>576
試してから書き込め

0579デフォルトの名無しさん

2009/02/25(水) 15:51:48

margeが優れてるのはdarcsでいいの？

0580デフォルトの名無しさん

2009/02/25(水) 16:13:12

mergeが優れているのは人。

0581デフォルトの名無しさん

2009/02/25(水) 16:22:50

>>579
mercurial or git

0582デフォルトの名無しさん

2009/02/25(水) 23:11:11

そもそもmergeが優れているってどういうこと

0583デフォルトの名無しさん

2009/02/26(木) 00:16:08

SubversionとMercurial使ってるけど、俺も「Mercurialはmergeが優れている」って
聞く度にいつも、いまいち意味が分からんと思う。

0584デフォルトの名無しさん

2009/02/26(木) 00:44:14

branchは、破棄されるか、trunk(master)に統合されるか二択。
そういったprojectなら、gitやhgはbranchしたのが何時だったか思い出す
必要が無い。mergeが優れているのは、その一点のみ。
その主張は、ほとんどの場合正しい。

0585デフォルトの名無しさん

2009/02/26(木) 01:34:55

ああ、branchで作ったディレクトリを見失う（どこにブランチ作ったか忘れる）心配がないって事ね
でもそれmergeが優れているわけではなくて、単なるbranch方式の違いだよな

0586デフォルトの名無しさん

2009/02/26(木) 02:08:42

マージの優劣って言葉通りじゃなくて、マージトラッキングや
その自由度・速度を含めたことだと思うが･･･

0587デフォルトの名無しさん

2009/02/26(木) 02:16:08

Mercurialって、マージの自由度低くない？
統合する方向のマージに強制されてるような気になってる来るというか、
cherry-pickingしにくい仕組み。

むしろ、Subversionぐらいの放任主義の方が自由感がある。

0588デフォルトの名無しさん

2009/02/26(木) 02:28:45

git or mercurialは3-way マージでsubversionは2-way マージだったはず。

0589デフォルトの名無しさん

2009/02/26(木) 02:32:41

>>587
機能を追加するたびに、bookmarkがbranchを使えばそもそもcherry-pickingする必要がない。
gitとmercurialは両方とも、mergeとcherry-pickingを区別してたと思う。

0590デフォルトの名無しさん

2009/02/26(木) 02:50:41

>588
3-way マージって、
(1)自分が編集したバージョン
(2)第三者が編集したバージョン
(3)上の(1)の元になったバージョン
の3-wayでしょ？

なら、Subversionと一緒じゃん？

0591デフォルトの名無しさん

2009/02/27(金) 00:19:15

>>590
Subversionって、ファイル単位でコンフリクトしたらCになって終了（解消してね）
じゃなかったっけ。今は違うのかな。
svkとかGitだと行単位でぶつかってなければ良い感じにマージしてくれる。

0592デフォルトの名無しさん

2009/02/27(金) 00:22:56

CVSの昔から、行単位でぶつかってなければ自動マージだろう……。

0593デフォルトの名無しさん

2009/02/27(金) 00:25:56

行単位だよ。

0594デフォルトの名無しさん

2009/02/27(金) 00:53:35

>>590
gitとmercurialは(3)が(1)と(2)の両方の元になったファイル

0595デフォルトの名無しさん

2009/02/27(金) 09:56:06

Linuxレベルならともかく、普通の規模のプロジェクトとか
普通の業務利用とかでそんなに賢いマージが必要
なのは、ちょっとどうかという気もするが・・・

マージだけならSubversionで困らない。
会社でSubversion個人でGitだけど

0596デフォルトの名無しさん

2009/02/27(金) 11:02:52

も少し賢くてもいいけどなぁ
あと Subversion は遅くね?

0597デフォルトの名無しさん

2009/02/27(金) 12:16:30

TortoiseHGでコミットするとき、Mステータスのファイルにデフォルトでチェック付けたい。
どっかで設定できる？
コミットツールはinternalって設定にしてる。

0598デフォルトの名無しさん

2009/02/27(金) 15:48:06

分散SCMだと分岐したまま進められちゃうから、
共通先祖を考慮したマージが必要なんじゃないかな。

Mercurial の内部マージと diff3 のマージってどっちがいいのかな？
衝突時に共通先祖が表示されるんで diff3 使ってるけど・・・

0599デフォルトの名無しさん

2009/02/28(土) 03:32:14

デフォルトでチェックされてるけど

0600デフォルトの名無しさん

2009/02/28(土) 08:09:04

600

0601デフォルトの名無しさん

2009/03/01(日) 13:26:37

分散型のバージョン管理システムの場合、
それぞれのリポジトリはリポジトリ丸ごと
持っているという感じなんでしょうか？

あるリポジトリをマスターと決めたとして、
そのフルのクローンをそれぞれ持っているということでしょうか？

いまはSubversionを使っていて trunk, branches, tags 型で
かんりしてまして、branches の下の自分が作業を進める
ブランチだけ手元のワーキングコピーにチェックアウトして
作業しており、マージはマージ担当（まれに自分）に任せてます。

そもそも分散型だと trunk, branches, tags 型の
管理というのはやらないものなのでしょうか？

分散型のバージョン管理システムの紹介記事を読んでいると、
そもそも「ブランチ」というのはリビジョンツリー（というかDAG）
上の異なるヘッドことを指しており、リポジトリ上で別の
ディレクトリとして分岐されたものという意味ではないですよね？

確かに「ブランチするときはそのブランチ用のリポジトリを
作れば良い」という記述も見ました。そのときリポジトリ丸ごと
クローンするのでしょうか？巨大なプロジェクトだと一部だけ
クローンして作業を進めたいというのはあり得ると思います。

分散型だと「あるリポジトリが消失しても別のリポジトリを
マスターと思えばよい」という記述も見ましたので、
分散している各リポジトリはそれぞれ対等にフルのツリーを
持っているのでしょうか？

0602デフォルトの名無しさん

2009/03/01(日) 13:50:00

VCS毎に違いはあるだろうけど、たいていはローカル（というかハードリンク可能な場所）なら
ハードリンクでリポジトリの内容を共有して領域節約できる。
ネットワーク経由の場合もフルに取ってくるんじゃなくて、最新からこのリビジョンまでって指定も出来る。

「ブランチ」って言葉の使い方も、VCS毎に変わるから一概に言えないな。
gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。

結局のところいくら記事読んでも、実際使ってみないと実感わかないと思うよ。
きっと分散じゃないVCS使い始めたときもそうだっただろ。
Subversion使ってるなら、svkとかgit-svn使ってみるとか。

0603デフォルトの名無しさん

2009/03/01(日) 14:11:54

そもそも「リポジトリ」という言葉の意味すらシステムによって違うしな

>>601
端的に言うと、分散型の進め方では
「フルのクローンをそれぞれ持っている」という理解はおおよそ合ってる
各作業メンバーが、「masterの履歴＋自分が行った変更の履歴」を持ってるような感じ

> 巨大なプロジェクトだと一部だけ
> クローンして作業を進めたいというのはあり得ると思います。
一部だけ持ってこれるような仕組みがあるよ
たとえばBazaarなら、履歴なしで最新版のファイルだけを取ってこれるようなオプションがある

0604601

2009/03/01(日) 14:58:56

>>602-603 ありがとうございます
>gitやhgは同じリポジトリの中でブランチ出来るけど、bazaarはリポジトリも別になるとか。

分散型といってもいろいろあるんですね、流儀が（当たり前か）。

>>602 wrote ネットワーク経由の場合もフルに取ってくるんじゃなくて、
>最新からこのリビジョンまでって指定も出来る。
>>603 wrote たとえばBazaarなら、履歴なしで最新版のファイルだけ
>を取ってこれるようなオプションがある

リビジョン範囲は指定できるものもあるんですね。
「分散型」を十把一絡げで理解しようとしたのが間違いでした。

0605601

2009/03/01(日) 15:01:29

最も強く疑問に思ったのは、あるプロジェクトのリポジトリ内に
「アプリの主要部分、いくつかの下請けライブラリ、
ドキュメント、UI関係」などがあったとき、
自分が担当しているライブラリ、ドキュメントの部分だけを
クローンして作業を進めるということができるのだろうか、という点でした。

これは最初から「ドキュメント用のリポジトリ」などに分離
しておくのが分散型の流儀なのだろうか？という点です。
これもDVCSによって異なるのかもしれませんが。

もう一つの疑問が、そのように完全に分離したとして、
共通の祖先をもたない複数のリポジトリを複数あつめて
一つのプロジェクトを遂行するのは難しいのでは？ということです。

たとえばプロジェクトの途中で「これは共通のライブラリで実現するように分離しよう」
などという決定が可能なのだろうか、と懸念しています。

Pythonを常用しているので、まずはMercurialとBazaarから主に上記の点について
実感をもつべく使い始めてみようと思いますが、DVCSの機能もさることながら
運用上のポリシーという側面も大きいと思うので、実際に使っておられる方の
アドバイス（ベターなプラクティス）があればぜひお聞かせください。

0606デフォルトの名無しさん

2009/03/01(日) 16:48:13

そもそも分離したいという目的は？
リポジトリの物理的大きさの問題であれば
いまさらそんな気にすることはないと思うけど・・・

管理面の規模の問題なら、分割するのもありかもね。
JDK7 なんかは分かれてるし。
分割した方が管理コストがさげられるならそうするべきでしょう。

0607デフォルトの名無しさん

2009/03/01(日) 18:47:10

http://sarabande.info/doc/bzr/user-guide
ここの画像無くなってる？

0608デフォルトの名無しさん

2009/03/02(月) 20:27:43

>>601さん、なかなか興味深い質問ですね。
分散VCSを使い始めた人の意見や疑問点をもっと聞いてみたいので、ほかにも質問があれば遠慮なく書いてください。
もちろんすべてに答えられるわけではないですが、他の人にも参考になると思います。

>>606
ディスクスペースを節約するために必要なディレクトリだけ持ってくるというのはあり得る。
たとえばゲームのように画像や動画や音声ファイルがある場合、それらもリポジトリに登録するべきだけど、
そうするとリポジトリサイズが膨らみすぎて、いくらHDDが安いと言ってもちょっと困る。
リポジトリからとってくるネットワーク資源もばかにならない。

あと、ディレクトリごとにアクセス権をつけたいという要求もある。
たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
＃この場合はリポジトリを分けた方が自然かも。

0609デフォルトの名無しさん

2009/03/03(火) 02:43:14

>>608
メディアファイルをリポジトリに「登録するべき」と決めつけずに、
分散かどうかに関わらず、リソースなども照らし合わせて管理方法を検討すべきだろうね。
最新ファイルしかいらないのにそもそもリポジトリを公開すべきなのか、とかも。

サブプロジェクトへの権限委譲については、
やっぱりJDK7みたいにするのがいいんじゃないかな。
アクセス制限も分散は難しいし、ロックもないし、
人間どうしの折衝や信頼は結構重要。

0610デフォルトの名無しさん

2009/03/03(火) 09:52:12

>>605
あまり回答にはなってないだろうけど参考までに。

何度も書いたが、CVS は modules ファイルを駆使してリポジトリツリーの
好きなところからちぎってきて組み合わせられるのが便利だった。
管理が良くも悪くもファイル単位ゆえ、自作ライブラリディレクトリから
アプリに必要なファイルのみチョイスするような芸当もできた。

今は Subversion を飛ばして Mercurial を使用(試用)中だけど、さすがに
CVS のような細かいことはできそうにないし、ハードウェアリソースも KB 単位で
ケチるような状況ではないので、ライブラリに関しては独立したリポジトリとして
開発時のディレクトリ構成を工夫している。

ただ、ファームウェアのような非常に小さなプロジェクトがたくさんあるような状況では、
いちいちリポジトリを分けるか一まとめにしてしまうかは悩むところ。分けると同期も面倒に
なってくる。今のところ、とりあえず一まとめにしているけど、もっといい方法はないか思案中。
大きなプロジェクトで使うことに主眼が置かれているんだろうな。

0611デフォルトの名無しさん

2009/03/03(火) 22:23:29

>>608
> あと、ディレクトリごとにアクセス権をつけたいという要求もある。
> たとえば画像ファイルは全員がアクセス可能だけど、元となるPhotoshopファイルはデザイナーだけがアクセス可能にしたい、とか。
> ＃この場合はリポジトリを分けた方が自然かも。
こういう事やりたいなら、PerforceやTeam Foundation Serverのような、
クライアント・サーバー型のバージョン管理システムが適してる。

0612デフォルトの名無しさん

2009/03/03(火) 23:08:29

python3000で組まれたバージョン管理ツールってないのかな？

bzrやhg何かの古株が対応するよりも新しく作る方が
早いかもしれんし。

0613デフォルトの名無しさん

2009/03/04(水) 13:17:49

windowsで日本語も使えるのはどれになるのでしょうか？
darcsの話題があんまり出ないのは死んだプロジェクトになってしまったのでしょうか？

0614デフォルトの名無しさん

2009/03/04(水) 14:19:36

>>613
全部試せよ。
それが嫌ならSubversionを押し戴け。

0615デフォルトの名無しさん

2009/03/04(水) 21:21:08

日本語を使えるので人に勧められるのはSubversionしかない

0616デフォルトの名無しさん

2009/03/04(水) 23:22:18

日本語コミットメッセージが書ければうちでは十分。

0617デフォルトの名無しさん

2009/03/04(水) 23:22:27

svnで不満があるならsvk使えばいいし。
svn最強。

0618デフォルトの名無しさん

2009/03/05(木) 02:30:42

svnは良くも悪くも無難でいいけど、svkはいろいろ酷い目にあった。

0619デフォルトの名無しさん

2009/03/05(木) 09:52:59

TortoiseHgの欠点は、
・付属のhgだと日本語ファイル名×
・TortoiseHgだと日本語ファイル名OK
・でも、hg mv がないｗｗｗ

ので、現時点で日本語ファイル名のファイルの移動する手段がありませんｗ
ワロタ

0620デフォルトの名無しさん

2009/03/05(木) 09:53:30

> ・でも、hg mv がないｗｗｗ
・でも、TortoiseHgにはhg mv 相当がないｗｗｗ

スマソ

0621デフォルトの名無しさん

2009/03/05(木) 09:55:53

>>613
WindowsでGUIでやりたいとなると、TortoiseSVNしか選択子なしですわ

0622デフォルトの名無しさん

2009/03/05(木) 10:51:26

肢

0623デフォルトの名無しさん

2009/03/05(木) 11:00:22

trac + svnで充分満足であります

0624デフォルトの名無しさん

2009/03/05(木) 15:21:59

hg来たな

0625デフォルトの名無しさん

2009/03/05(木) 18:09:59

>>624
0.7入れてみた。
毎回アンインストール→再起動→インストール→再起動を強いられるのは勘弁して欲しいな。
あと、テーマ機能とか付いたみたいだけど、そんなことしてる場合じゃないだろって感じ。
まだまだですな。

0626デフォルトの名無しさん

2009/03/05(木) 19:38:47

>>610
ライブラリ毎にリポジトリをつくったら、あとは
プロジェクトのリポジトリをつくって
ライブラリをhg pull --forceで取り込んでmergeすればok.

0627デフォルトの名無しさん

2009/03/05(木) 20:00:26

git push でエラーが出ます。

$ git push
Counting objects: 9, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 924 bytes, done.
Total 6 (delta 3), reused 0 (delta 0)
To [email protected]:myname/project.git
3648514..9fc4c3a ot -> ot
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to '[email protected]:myname/project.git'

これはどういう意味で、どう対処すればいいでしょうか。

0628デフォルトの名無しさん

2009/03/05(木) 20:04:29

うちの環境では0.7+ini設定で日本語使えてる感じがするな
まあたまたまなのかもしれん

0629デフォルトの名無しさん

2009/03/05(木) 20:07:30

>>626
意味がよくわからない。
最後の節の、小さなプロジェクトがたくさんある場合の対処法？

0630デフォルトの名無しさん

2009/03/05(木) 22:53:08

>> 628
TortoiseHg 0.7にwin32mbcsエクステンションの設定で、わりといい線までいくみたいですね。
でも、ディレクトリ名の最後の文字が0x5cを含んでいたりすると、まだコケる模様。

0631デフォルトの名無しさん

2009/03/05(木) 22:53:56

アンカー失敗したorz

0632デフォルトの名無しさん

2009/03/06(金) 00:39:14

>>627
>>282

0633デフォルトの名無しさん

2009/03/06(金) 02:06:53

>>630
多分TortoiseHgだとファイル名を指定してaddしてるんで動いているように見えるだけ。
Mercurial 1.2でも直ってない。

0634デフォルトの名無しさん

2009/03/06(金) 02:15:23

正直、日本語ファイル名の対応でいうと
SVN＞bazzar＞git＞mercurial
何もしないでバイト列で扱うgitのほうが、まだマシだ

0635デフォルトの名無しさん

2009/03/06(金) 04:50:33

もう疲れたよ、パトラッシュ・・・

0636デフォルトの名無しさん

2009/03/06(金) 08:58:53

Mercurial Patch
ttp://bitbucket.org/witten/win32mbcs-patch

0637デフォルトの名無しさん

2009/03/06(金) 10:52:03

git のfast forwardって何ですか。
マニュアルみてもさっぱりわかりません。

0638デフォルトの名無しさん

2009/03/06(金) 11:10:00

>>636
何勝手に2chの著作物を断りもなく公開してんだよ？

0639デフォルトの名無しさん

2009/03/06(金) 22:07:18

>>635
マネスレに（・∀・）ｶｴﾚ!!

0640デフォルトの名無しさん

2009/03/07(土) 01:36:05

1.6.2

0641デフォルトの名無しさん

2009/03/07(土) 01:42:16

>>637
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#fast-forwards

0642デフォルトの名無しさん

2009/03/07(土) 09:27:55

　　　　　　　　　　　　　　　　　　　　　　　/
　　　　　　　　　　　　　　　 ,. ､　　　 /　　／
　　　　　　　　　　　　　　 ,.〃´ヾ.、　　/　／
　　　　　　　　　　　　　／ |l 　　 ',　 / ／　　2chの著作物です！
　　　　　 ,､　　　 ,r'´　　||--‐r､ ',　　　　　パッチは2chの著作物でした！
　　　　　　l.l.　,..ィ'´　　　　l',　　'.j　'.　　　　　パッチは2chの著作物でした！
　　　　　　 'r '´　　　　　 ',.r '´　!|　　＼
　　　　　　 l!　　　　　....:.:.:.:.:.:ヽ､　 ,ｌ　　　　＼
　　　　　　ゝ､.,_ ---‐‐‐----ゝ､ノ
　　　　　　　 | |
　　　　　　 .| |
　　　　　　 | |
　　　　　　　　| |
　　　　　　 | |

0643デフォルトの名無しさん

2009/03/07(土) 19:40:51

個人で使う分には関係ないだろ。
本家には未来永劫取り込まれないだろうが。

0644デフォルトの名無しさん

2009/03/07(土) 19:52:07

だがちょっと待ってほしい。
２ちゃんねるが初出だとどうして言えるだろうか。

どこかに公開されていたものが２ちゃんねるに投稿されたのではないか。
２ちゃんねるにそれを書き込んだ人物が、
当該文書の原著作者であったとどうして証明できるだろうか。

0645デフォルトの名無しさん

2009/03/07(土) 20:00:20

方式主義なら話は単純だったんだろうか。

0646デフォルトの名無しさん

2009/03/07(土) 20:32:44

話を3日前にもどそう

0647デフォルトの名無しさん

2009/03/07(土) 22:28:02

bzr revert -r date:2009-03-04

0648デフォルトの名無しさん

2009/03/08(日) 02:27:26

著作権ってある程度芸術性みたいなのが求められたりするし、
そのパッチ単体程度だと、著作物にならないんじゃね。
まぁ、慣例的にもそこに文句つけたりしないだろうし、
どうでもいいが。

0649デフォルトの名無しさん

2009/03/08(日) 04:31:46

日本ではたぶんそうなる。
問題は、日本だけで開発されてるようなプロジェクトじゃないってこと。
将来の開発者を含む全ての開発者が、今後活動する可能性がある全ての国や地域の法規に照らして判断する必要がある。
そうじゃないと、例えば何も知らずに加わった新開発者が、旅行先で突然逮捕されるかもしれない。

ぶっちゃけ、そんなリスクのあるパッチ取り込むより、自分達で書き直すほうがまし、っていうか。

0650デフォルトの名無しさん

2009/03/08(日) 09:00:28

TortoiseHg付属hgの日本語ファイル名周りしらべたけど、hg mvが駄目ってのは勘違いだったみたいスマソ。

hg commit(hg ci)で、addした駄目文字ファイル名のファイルがコミットできないみたい。
hg mv が駄目だと思ったのは、mv時にremoveしてaddされるので、その後のcommitがおかしいためみたいです。

検証過程：

>touch 表の噂.txt # touchは空ファイル作ってるだけです。
>touch test.txt # ただしBorland版touchね
>hg st
? test.txt
? 表の噂.txt
>hg ci -A -m "added from command line" # 追加しながらコミット。ここまではよい
adding test.txt
adding 表の噂.txt
>hg st # コミットできてねえ！add相当は一応できてる
A 表の噂.txt
>hg add . # 念のため
>hg ci -m "added from command line retry"
nothing changed # ええ！？無視ですか？
>hg st
A 表の噂.txt # ダメポｗｗｗ

つーわけで、>>636 を試してみるぜ

0651デフォルトの名無しさん

2009/03/08(日) 09:13:43

あれ？もしかして、>>636ってソースからコンパイルがいるのかよ・・・
Bazzarみたいにプラグイン形式じゃないのか orz
面倒クセー

0652デフォルトの名無しさん

2009/03/08(日) 13:04:22

TortoiseHg 0.7 かなりよいですねー。

コミットツールがようやく置き換えられて、ファイル名や以前のコミットログの参照は、
駄目文字含め文字化けしなくなった。
diffの表示も中身がSJIS、UTF-8でも問題ない。
(このコミット時の簡易diff表示は他のTortoise系でもほしいくらい)

残念ながら、Rename Fileはリネームのダイアログが文字化けするし、
win32mbcsのエラーで実際にリネームできないし、
ドラッグアンドドロップでのリネームはまだ非対応なものの、
Guess Renamesで適当にリネームした後、リネームの自動検出ができる。
そっちは駄目文字含め、日本語ファイル名OK、なので実質は問題ないだろう。

これで、コマンドライン版 hg なくても日常作業は事足りるようになった。

しかし、hgのコマンドライン版は日本語リソース追加されてて、日本語で出てきてびっくりしたｗ

0653630

2009/03/08(日) 13:46:07

>>652
日本語ファイル名対応は、まだ完全ではないようなので要注意ですよ。

0654デフォルトの名無しさん

2009/03/08(日) 14:23:16

>>651
本体の1.2のソースダウンロードしてローカルリポジトリ作って>>636のパッチ当てて
できたhgext/win32mbcs.pyとmecurial/util.pyをTortoiseHg/library.zipの中の同じ位置に配置すればとりあえず動くっぽい

0655652

2009/03/08(日) 15:11:02

TortoiseHg 0.7 で実質、>>619の問題は一応解消した。

>>650 は相変わらず駄目だが、直接ファイル名指定してやると一応通る

>hg ci -m "added from command line retry" 表の噂.txt
>hg st 　　　　　　　# OK
>

だけどまあちょっと怖いね。

しかし、bitbucket.rogに日本語ファイル名のファイルをpushしたら、
未だに更新ファイルの詳細ページがInternal Server Errorで見れねえｗ
これ、大分前から変わってないな

0656デフォルトの名無しさん

2009/03/08(日) 21:34:15

TortoiseHg 0.7のコミットツールの
ログ入力欄のフォントが気に入らない。
変更できねえかな。

0657デフォルトの名無しさん

2009/03/10(火) 19:06:14

TortoiseHgの翻訳をLaunchpadでするって激しく何か間違っている感が…。

0658デフォルトの名無しさん

2009/03/11(水) 20:31:36

git push
と
git push origin master
の違いがわかりません。だれか教えて。

あと
git checkout -b dev origin/dev
としたあとにpushするのって、
git push
でいいのか
git push origin dev
としなきゃいけないのか、どっちでしょう。

マニュアルのここを読めでもいいので、教えてください。

0659デフォルトの名無しさん

2009/03/11(水) 23:50:36

>>658

git push だけの場合は<repository>と<refspec>を省略したことになるので、
.git/configにremoteとmergeが指定されていればそこにpushしようとするよ。

git checkout -b dev origin/dev とした場合は、devにremoteとmergeが指定されてる
はずなので、省略してgit pushだけでもおk。

git pushはExamplesが俺はすごい分かりやすいと思う
ttp://www.kernel.org/pub/software/scm/git/docs/git-push.html#_examples

0660デフォルトの名無しさん

2009/03/12(木) 11:02:25

>>659
うおーなんとわかりやすい説明。
.git/config みたら
[branch "dev"]
　　remote = origin
　　merge = refs/heads/dev
と書いてありました。なるほど。
どうもありがとうございました。

0661デフォルトの名無しさん

2009/03/12(木) 17:54:40

Bazaar and Mercurial SCM services launched
http://apps.sourceforge.net/wordpress/sourceforge/2009/03/11/bazaar-and-mercurial-scm-services-launched/
>The SCM platforms supported by SourceForge.net differ in capabilities. All of our SCM services include rsync backups, web-based browsing, authentication with SourceForge.net accounts, and direct support by SourceForge.net staff.

0662デフォルトの名無しさん

2009/03/12(木) 19:42:09

git pull --rebase
と
git fetch
git rebase origin
には違いはありますか。

0663デフォルトの名無しさん

2009/03/12(木) 23:11:56

>>661
Gitには既に対応してる？

0664デフォルトの名無しさん

2009/03/12(木) 23:31:40

>>661
なんということだ
Bazaarユーザーの俺はlaunchpadとSourceForge.net、どっちを使えば

0665デフォルトの名無しさん

2009/03/13(金) 11:29:09

http://git.sourceforge.net/
こいつがGit対応を阻んでいるのかｗ

0666デフォルトの名無しさん

2009/03/13(金) 21:19:25

sourceforgeはgitにずいぶん前に対応しなかったっけ?
http://slashdot.jp/developers/article.pl?sid=08/11/15/058203

0667デフォルトの名無しさん

2009/03/13(金) 22:20:48

>>666
jpだけって書いてあるじゃんwww

0668デフォルトの名無しさん

2009/03/14(土) 01:46:59

Git だけ >>661 より少し前に対応済み。
"Git now available for SF.net hosted projects 2009-02-18"
http://sourceforge.net/community/forum/topic.php?id=4779&page#post-10374

0669デフォルトの名無しさん

2009/03/14(土) 08:34:01

>>665
warota

0670デフォルトの名無しさん

2009/03/14(土) 09:13:46

結局git, hg, bzr, cvs, svnが使えるのか＞sf.net

0671デフォルトの名無しさん

2009/03/16(月) 18:26:48

git branch -r したときに、たとえば
origin/HEAD
origin/master
origin/experiment
origin/development
と出てたとします。
ここで、リモートのリポジトリから origin/development が削除されたとします。
しかし手元で git fetch してから再度 git branch -r すると、origin/development が残ったままになっています。
つまり、この状態では git branch -r が正しい情報を表示してくれない（または git fetch しても
rogin/development が削除されたという情報が反映されない）ということです。
このあと git branch -r -d origin/development を実行すると表示されないようにはなりますが、やっぱり気持ち悪いです。

長くなりましたが、質問をまとめると、リモートブランチの*正確な*一覧をとってくるのはどうしたらいいでしょうか。
または git branch -r したときに、すでにリモートブランチで削除ずみのものを表示させないようにするにはどうしたらいいでしょうか。

よろしくお願いします。

0672デフォルトの名無しさん

2009/03/17(火) 23:37:37

>>671
git remote prune はどうかな。

0673デフォルトの名無しさん

2009/03/18(水) 15:06:17

>>672
まさにそれでした。
$ git remote prune --dry-run origin
Pruning origin
URL: [email protected]:user1/project1.git
* [would prune] origin/development
$ git remote prune origin
Pruning origin
URL: [email protected]:user1/project1.git
* [pruned] origin/development

どうもありがとうございました。

0674デフォルトの名無しさん

2009/03/21(土) 22:06:38

TortoiseHg 0.7.1 (with Mercurial 1.2.1)、インストール前に
旧版をアンインストールしておく必要がなくなったようです。

0675デフォルトの名無しさん

2009/03/22(日) 00:50:08

TortoiseHg 0.7.1を試してみてRename Fileの化け文字は
ある程度改善したみたいだ。しかしファイル名に「ソ」が
あるとやはり化ける。あと少しで完璧なのに惜しい。

0676デフォルトの名無しさん

2009/03/22(日) 01:14:54

>>675
予とか表は大丈夫なのか？

0677デフォルトの名無しさん

2009/03/22(日) 02:21:57

>>675
>>636

0678デフォルトの名無しさん

2009/03/23(月) 13:28:13

TortoiseHGのGUIツールキットがなかなかよさげなんですが、あれって何使っているんでしょうか？

0679デフォルトの名無しさん

2009/03/23(月) 18:38:33

>>678
gtk

0680デフォルトの名無しさん

2009/03/24(火) 00:16:26

TortoiseGitでgithub使えている人いる？

mkdir magemoge
cd magemoge
git init
touch README
ToritoiseGitで追加、コミット
git remote add origin [email protected]:user_name/magemoge.git
ToritoiseGitでpush

以下のエラー
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
どうすりゃいのかな？

0681680

2009/03/24(火) 00:27:07

ssh周りかな？と重い
TortoiseGitのオプションで、sshにplink.exeを指鋳閧ｵ、
Pageantを立ち上げて鍵を追加し、実行したのですが、やはりエラーがでてしまいます。
github側にはすでに、対応する公開鍵をついかしてあります。

> git.exe push "origin" master
> fatal: The remote end hung up unexpectedly

うーん。

0682680

2009/03/24(火) 01:13:56

何度もスマン
コマンドラインgitだと大丈夫でした。
`ssh-agent -k`を実行して、git push master original で無事いけました。
TortoiseGitの時はどうすんだろ

0683デフォルトの名無しさん

2009/03/24(火) 03:30:39

問題山積みですな

0684デフォルトの名無しさん

2009/03/24(火) 10:22:41

TortoiseHg 0.7.2

0685デフォルトの名無しさん

2009/03/24(火) 11:14:10

まだ>>636が必要そうだね

0686デフォルトの名無しさん

2009/03/24(火) 18:35:35

git push すると次のようなエラーがでます。
このエラーは何を意味していますか。
またどう対処すればいいでしょうか。

$ git push
Counting objects: 159, done.
Delta compression using 2 threads.
Compressing objects: 100% (47/47), done.
Writing objects: 100% (81/81), 10.66 KiB, done.
Total 81 (delta 58), reused 47 (delta 33)
To [email protected]:myname/myproject.git
c62e2a8..cd4f2f0 dev -> dev
! [rejected] master -> master (non-fast forward)
! [rejected] experiment -> experiment (non-fast forward)
error: failed to push some refs to '[email protected]:myname/myproject.git'

よろしくお願いします。

0687デフォルトの名無しさん

2009/03/25(水) 10:33:22

TortoiseGitの右ドラッグ＆ドロップで "Git Copy and rename versioned item here"という選択肢が出るのですが、
現バージョンでは実装されていないものの、コマンドライン版gitでは何に値するものなのでしょうか？

他にも、

・Git Move versioned items(s) here → git mv 相当？
・Git Move and rename versioned items here → 同上
・Git Copy versioned item(s) here →これもなんだろ？

などがコンテキストメニューで出ますね。

0688687

2009/03/25(水) 10:49:54

assert(?) - git equivalent to “svn copy” for forking files with history?

http://markpasc.livejournal.com/186489.html

ああ、普通にコピーするだけでも一応以下のコマンドで感知はできるのか･･･

git log -C -C --name-status --no-walk

なるほど。TortoiseGitの方はコピーしたかどうか、というのはわからないみたいｄせいあｔ。

0689デフォルトの名無しさん

2009/03/27(金) 13:38:42

ためしに、MercurialでXAMPP(1万ファイル300MBくらい)を突っ込んでみたんですが、
XAMPPのアップグレード後で更新ファイル数が多いと
TortoiseHgがハングしてしまうｗ
Intel Q6600程度のCPUだと返ってきません

コマンドライン版hgだとサクサクですね。
Tortoiseの方はあまり大きなプロジェクトは考えられてないもんですかね？

0690デフォルトの名無しさん

2009/03/27(金) 13:39:53

訂正

> TortoiseHgがハングしてしまうｗ
TortoiseHgでコミット時、ウインドウがハングしてしまうｗ

コマンドライン版だと、hg commitやhg add .ともに軽いです。

0691デフォルトの名無しさん

2009/03/27(金) 13:42:04

>>689
また訂正スマソ

> > TortoiseHgがハングしてしまうｗ
> TortoiseHgでコミット時、ウインドウがハングしてしまうｗ

コミット時に立ち上がるウインドウがハングしてしまう

です、なので、TortosieHgだとコミットができません orz
まあ、XAMPPは日本語ファイル名はないみたいなのでコマンドライン版でも問題ないのですが

0692デフォルトの名無しさん

2009/03/28(土) 00:01:54

TortosieSVN でも、よくあること。
しばらく経ってやりなおす。

0693デフォルトの名無しさん

2009/03/28(土) 17:36:10

俺はログオフしてるわ
次同じことやってだめなら諦めてコマンド打ってる

0694デフォルトの名無しさん

2009/04/01(水) 03:59:16

python subversion -> mercurial決定
http://mail.python.org/pipermail/python-dev/2009-March/087931.html

0695デフォルトの名無しさん

2009/04/01(水) 04:04:35

>694
ハゲがバザーよりsvnユーザーにとって学習しやすいってのは、
どの辺の話だ？

0696デフォルトの名無しさん

2009/04/01(水) 04:35:49

>>695
bazaarのメーリングリストでも同じこと言ってるやつがいるなw
bazaarのメーリングリストでキレながらStephenが説明してるから見て来たら？

0697デフォルトの名無しさん

2009/04/01(水) 05:59:45

祭り会場（エイプリルフールネタじゃないよ。）

【ネット】朝日新聞編集局員（４９）、２ちゃんねるで荒らし行為。差別を助長する書き込みも…朝日、「処分します」と謝罪で★３０
http://tsushima.2ch.net/test/read.cgi/newsplus/1238529614/

0698デフォルトの名無しさん

2009/04/01(水) 10:20:00

>>697 通報した

0699デフォルトの名無しさん

2009/04/01(水) 18:34:07

>>695
Guidoが勝手に言ってるんだから本人に聞けば？

0700デフォルトの名無しさん

2009/04/01(水) 20:25:21

TortoiseHg 0.7.3

0701デフォルトの名無しさん

2009/04/02(木) 08:11:07

駄目文字ファイル名には対応したが、駄目文字フォルダ名には対応できてない気がする

0702デフォルトの名無しさん

2009/04/02(木) 17:16:18

>>701
Mercurial自体が対応してないのに？

0703デフォルトの名無しさん

2009/04/02(木) 23:16:39

バージョン管理システムのバージョンを管理するのが面倒くさい。
バージョン管理システムのバージョンを管理するシステムは無いの？

0704デフォルトの名無しさん

2009/04/03(金) 00:54:05

パッケージ管理システムでも使えよ

0705デフォルトの名無しさん

2009/04/03(金) 15:05:50

質問があるのですが、よろしいでしょうか？

バージョン管理システムで「この行のローカル変更を無視する」ような指定の
できるものはありませんか？

例えば、設定ファイルなど、個々のユーザや環境ごとに内容を書き換える必要
のあるファイルをバージョン管理しようとすると、個々のローカルの変更が当
然、競合してしまいます。

しかし、このファイルをバージョン管理から外すと、新しい設定項目が増えた
ときにも、全ユーザの設定ファイルをアップデートすることができません。

そこで、たとえば
String db_name = "db_(ユーザ名)"; // svn:ignore
という具合に、svn:ignore の出現する行はバージョン管理の対象から外す、と
いった機能がほしいのです。

レポジトリには svn:ignore を含まないコードを登録し、各ユーザがチェック
アウト後に自分に適した値に書き換えてから、自分で svn:ignore と書き加え
ます。その後はその行だけ、バージョン管理システムから無視されるようにな
るので、アップデートすればその行以外は更新されます。

また、svn:ignore の書かれていない行を変更してコミットすれば、レポジトリ
に登録されたコードは当然、変更されます。

こんな機能を持つバージョン管理システムはないでしょうか？

--
もしかして分散バージョン管理システムなら、こういう使い方もできるのでしょ
うか？

0706デフォルトの名無しさん

2009/04/03(金) 15:13:01

>>705
設定ファイル側で個々のユーザ毎の設定だけ別ファイル作るとかして対応したら？

0707705

2009/04/03(金) 15:26:19

>>706
それはある程度やっておりますが、そういう個人ごとのファイルを中途半端に
バージョン管理したいのです。設定項目が増えたりしますから。

今は、設定項目が増えたりするときは、メーリングリストで通知しています。
もっとうまい方法がないかと思うのです。

0708デフォルトの名無しさん

2009/04/03(金) 16:44:32

コミットのトリガーで動く前処理スクリプトか、
svnの代わりに呼ぶラッパー作れば？

0709705

2009/04/03(金) 17:27:21

>>708
それはいいかもしれませんね。
ただ、コミットのトリガーだと、ユーザ環境では「変更されたファイル」とし
て扱われてしまうし、
svnの代わりのラッパーは、ユーザのOSやクライアントソフトの種類が多くて難
しそうです。

0710デフォルトの名無しさん

2009/04/03(金) 18:18:09

>>705
分散型なら各自の設定ファイルもバージョン管理できるだろうけど、
それだけの為に分散型にするのはどうだろうね。
あなた一人だけでやってるなら頑張って使い方覚えればおkだけど。。。
antとかrakeみたいなので設定ファイルをジェネレートするようにしたほうが
適してるかも。

0711デフォルトの名無しさん

2009/04/03(金) 18:46:32

xmlでもiniでもconfigでも、拡張子の後に更にsampleとか拡張子付加して管理してる
使う側が勝手にマージしろって感じに

0712デフォルトの名無しさん

2009/04/03(金) 18:47:42

んでコミットされないようにignoreにも登録

0713705

2009/04/03(金) 19:13:18

>>710
おっしゃるとおり、当分はSubversionから離れることはできないでしょう。
分散型については将来に備えて知っておきたいと思っています。

ant や rake については、毎回ユーザが設定値を与えるならわずらわしいし、
値を保持するなら、その値をどうバージョン管理するかという話に。

>>711-712
それはTortoiseSVNのチュートリアルが推奨している方法ですね。
（サイトが落ちているようなのでキャッシュ）
http://72.14.235.132/search?q=cache:oA9O7x9K_XMJ:www.caldron.jp/~nabetaro/svn/TortoiseSVN-1.3/TortoiseSVN_ja/ch05s02.html

うちもそうしているのですが、テンプレートが更新されても気づかないんです。
ユーザにマージさせるのに、メーリングリストで通知することになります。

0714デフォルトの名無しさん

2009/04/03(金) 20:13:50

別にそれで良くね？
あとはpost-commitにでも特定のファイルがコミットされたら
注意しやすいように、分かりやすくなるようにスクリプト書くだけじゃん

0715705

2009/04/03(金) 21:08:44

>>714
なるほど、テンプレートファイルが更新されたら、自動でMLにメールを投げる
とかですね。

結局、その辺に落ち着くしかないのかもしれません。自分の当初のアイディア
も、例えば設定項目が増えた場合、その増えた値を個々のユーザに書き換えて
もらう必要があるなら、通知が必要なようですし。

0716デフォルトの名無しさん

2009/04/04(土) 01:09:39

>>705
うちはgit使ってるけど、
- ベースとなるブランチをmasterとする
- ホスト毎にそのホスト固有の修正を行うブランチを用意(host/foo, host/bar, ...)
- masterに更新があった場合はgit rebase master host/fooとして各ホスト用データを更新
としてる。

0717デフォルトの名無しさん

2009/04/04(土) 08:47:23

>>716
便乗質問させてください。
その場合は、ローカルの仕事を本家にcommitしたいときはcherypickするのでしょうか？
そのままmergeしちゃうとホスト固有の部分も区別なくmergeされちゃうので、
まずいですよね。

0718716

2009/04/04(土) 16:29:32

>>717
そもそもhost/fooではホストローカルな修正しかしないので、masterにそういう修正を持っていくことはないよ。
masterに持っていきたくなるような修正はmasterで作業すれば良いんだし。

それでも誤ってmasterで行うべき作業をhost/fooでしてしまうことはあるかも知れない。
そういうときは
- まだコミットしてないならgit checkout -m masterでブランチ切り替えて作業継続。
- 既にコミットしてたらmasterで該当コミットをgit cherry-pickしてから
　ホストローカルなブランチではgit resetやgit rebase -i masterで該当コミットを抹消。
としてる。

0719636

2009/04/07(火) 02:47:46

ファイル構成が大幅に変わってpatchがあてれなくなっていたので更新した

0720デフォルトの名無しさん

2009/04/07(火) 04:04:43

gitでhttp:/server/proj.gitからコミットasdf1234....を取りたい
んだけど、どうやればいいの？

全部取ってrevertを使ってみたが訳が分からん。
あまりに説明が無さ過ぎて泣ける。

0721デフォルトの名無しさん

2009/04/07(火) 10:35:04

全部取ってるなら

git checkout asdf1234

でいいんじゃないか？

0722デフォルトの名無しさん

2009/04/07(火) 18:42:00

>>713
各自用のバージョン管理しないローカル設定ファイル(ignoreされる)を
用意して、テンプレート設定ファイルの各値を上書きするように
ビルドツールを組んで、実行環境が構築されるようにしてやってるよ。
この場合、テンプレートにローカル設定がマージされるので、
ローカル設定ファイルの内容は古くても動く可能性がある。

もし各環境用の設定も全てあなたがメンテしないといけないなら、
各環境用にブランチ作るとかかなー

0723デフォルトの名無しさん

2009/04/08(水) 02:47:45

tracがパッケージとして既にあるubuntuか
安定性のcentosか
どっちでリポジトリ関連の鯖たてようかなあ

0724デフォルトの名無しさん

2009/04/08(水) 08:56:58

ubuntuのパッケージって結構古いのばっかりじゃなかったっけか。
あと日本語化するならapt使って入れるのはやめといた方がいい希ガス。

0725デフォルトの名無しさん

2009/04/08(水) 21:34:44

Ubuntu,Debianはbackportsで多少新しいのが入る。
CentOSはrpmforgeで同様に。
日本語化するならtracをいったん入れる直前までやってtracに必要なパッケージをメモって、
で必要なパッケージを入れて、日本語版Trac入れる、かな。

あと、ちょいとスレ違いなので、Tracの話題ならこっちの方がよいかと。
【バグ管理】 BTS使ってる？【追跡ﾞ】２
http://pc12.2ch.net/test/read.cgi/tech/1163173901/l50

0726デフォルトの名無しさん

2009/04/08(水) 23:25:22

メッセージ翻訳担当募集
http://groups.google.com/group/mercurial-ja/browse_thread/thread/96cdbf93d4f76f53?hl=ja

＞なぜかリリースノートには記載されていないのですが（笑）、
＞一応 Mercurial 1.2 版からヘルプ類が日本語化されています。
＞しかし、ちょっと試してみればお分かりのように、まだまだ翻訳網羅率が
＞高くありません。とはいえ、数が数なので、私1人の翻訳では、流石に
＞ペースアップにも限界があります。

0727デフォルトの名無しさん

2009/04/09(木) 02:51:34

>726
日本語のmanがかなり古いんだが、そろそろ更新しないのかな？
mercurial wiki上に有るんなら俺が訳してもいいんだが。場所違うし。

0728デフォルトの名無しさん

2009/04/12(日) 16:58:17

自宅LANで使ってるファイルサーバがWindows Server 2003なんですが
これにバージョン管理システム入れるとしたら何使うのがお奨め？

用途としては、デスクトップとノートでソースの同期を取るくらい。
ネットワーク越しにファイルをやり取りできるデーモンを立ち上げっぱなしにできて、
日本語ファイルがちゃんと扱えれば、何でもいい。
サーバー側はコマンドラインで構わないけど、クライアント側はGUIツールがあると嬉しい。

できれば、はやりのgitとかmercurialみたいな分散システムも使ってみたくて
特にmercurialに目を付けてたんだけどサーバ側をWindowsにしてもちゃんと使えるのかしら

0729デフォルトの名無しさん

2009/04/12(日) 17:11:12

そういう用途ならDropboxなどでもいいようにも見える。

0730デフォルトの名無しさん

2009/04/12(日) 21:26:57

>>728
そんなあなたにMicrosoft Visual Studio Team System 2008 Team Foundation Server
お値段は破格の30万円！

クライアントのTeam Suiteはなんと驚きの130万円！

0731デフォルトの名無しさん

2009/04/12(日) 22:17:16

http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/

・git は全部保存、hg は差分保存
・git のブランチは分散と別に設計されてる、hg は分散がそのままブランチ

0732デフォルトの名無しさん

2009/04/12(日) 22:56:57

「日本語ファイルがちゃんと扱えれば」ってことは、Bazaarがベストなのでは

0733デフォルトの名無しさん

2009/04/12(日) 23:52:33

>>731
bazaarですねw

0734デフォルトの名無しさん

2009/04/13(月) 00:12:48

でも TortoiseBzr って日本語の扱い不自由じゃなかったっけ？
もう直ったのかね。

0735デフォルトの名無しさん

2009/04/13(月) 01:11:11

>>734
Tortoiseは不自由ですね

0736デフォルトの名無しさん

2009/04/13(月) 01:55:27

結局svnが無難ってことだな

0737デフォルトの名無しさん

2009/04/13(月) 03:08:59

＞・git は全部保存、hg は差分保存
今は違うだろ

0738デフォルトの名無しさん

2009/04/13(月) 06:36:16

TortoiseHgは最近になって日本語がほとんど無問題になった。

0739デフォルトの名無しさん

2009/04/13(月) 14:14:12

ほう

0740デフォルトの名無しさん

2009/04/13(月) 14:30:24

Tortoise系もインターフェイスはいっそ共通にしてプラグインでVCSを切り替えられたらいいのにな。
そうすれば各VCSの開発者は純粋に自分のところだけ作るだけでいいし。

0741デフォルトの名無しさん

2009/04/13(月) 14:35:31

普通に邪魔だし不要

0742デフォルトの名無しさん

2009/04/13(月) 15:34:47

Mercurial も、気づけば結構バージョンアップしてるけど、
サーバー(push/pull するだけの貯蔵庫)のバージョンは 1.0.1 で
まだ不都合ないかな。

0743デフォルトの名無しさん

2009/04/13(月) 18:30:28

http://www.selenic.com/mercurial/wiki/index.cgi/FixUtf8Extension
こんな extension があるのね。
最初から最後までこの extension を有効にしておけば、Windowsでも
Unicodeファイル名問題無しになるのかな？

あとは Launchpad の mercurial 版があれば最強なんだよな。
非公開リポジトリいらないから個人リポジトリがほとんど制限なく
作れるホスティング。

0744デフォルトの名無しさん

2009/04/14(火) 10:43:23

>>743
最近、自宅鯖開通させたからつくってみようか？

0745デフォルトの名無しさん

2009/04/14(火) 12:24:21

BitBucketじゃ不満かあ。俺はあのくらいちょうどよいが。
ファイル置き場やフォーラムがない点はちょいと困るけど

0746デフォルトの名無しさん

2009/04/14(火) 12:54:48

>>745
他人のプロジェクトのbranchを作って公開するのに、一気に数MB消費
するからなぁ。。。150MBは不安。
$10/year で 5GB くらい気前よくくれても良いのに。
どうせ内部ではbranchはハードリンクになってて大して容量使ってないんだろ・・・

Launchpad は無料で無制限。 Canonical 気前よすぎ

0747デフォルトの名無しさん

2009/04/14(火) 12:57:21

>>744
ありがとう。
でも、 bitbucket も launchpad も、ホストされているプロジェクトの
branch を作るのが目的だから、自分専用リポジトリ置ける場所が
あっても意味がないんだよなぁ。

0748デフォルトの名無しさん

2009/04/14(火) 16:09:58

TortoiseHGをsshでつかいたいんですが
Network error: Connection Refused
と出て接続できません。
サーバ側でsshd -dで起動してみると
そもそも接続してきてません。
TortoisePlink.exeを直に実行してもダメですが、
Putty.exeなら接続できます。
何が悪い?

0749デフォルトの名無しさん

2009/04/14(火) 16:10:27

お前の頭

0750デフォルトの名無しさん

2009/04/14(火) 16:55:08

>>748
俺はその辺調べるのが面倒なんで、Mercurial.ini に
ssh = C:\cygwin\bin\ssh
と設定して、Cygwin の ssh 使ってる。

0751デフォルトの名無しさん

2009/04/14(火) 17:10:56

>>750
なるほど、>748の頭を調べるのは面倒だな。

0752デフォルトの名無しさん

2009/04/14(火) 17:57:31

ちゃんとした答えを出せる>>750の頭＞＞＞>>748の頭＞＞＞(越えられない壁)＞＞＞>>749の頭

0753748

2009/04/14(火) 18:08:17

素のputtyについてくるplink.exeで試したら原因がわかったよ。
puttyのdefault settingでhostを指定していたんだが、
plink.exeの引数にhostを指定してもdefault settingにつなぎにゆくのが原因だった。
default settingのhostを空にしたらtortoiseplink.exeで接続できた。
みんなが応援してくれたおかげで解決できたよ。じゃまた。

0754デフォルトの名無しさん

2009/04/14(火) 18:09:40

と748が顔を真っ赤にして反論してます

0755デフォルトの名無しさん

2009/04/14(火) 18:30:44

みんなやさしいな

0756デフォルトの名無しさん

2009/04/14(火) 18:46:05

>>753
えらいえらい

>>749
>>754
マジで氏んでいいよ

0757デフォルトの名無しさん

2009/04/14(火) 18:48:46

分かりすぎる自演にﾜﾛﾀ

0758デフォルトの名無しさん

2009/04/14(火) 18:53:48

>>753
そのぐらいここにいる歴戦の勇者はとっくに感づいてんだよヴォケ

0759デフォルトの名無しさん

2009/04/14(火) 18:54:44

いやあIDがないと自演の濡れ衣かぶせるのもちょろいなぁ

0760デフォルトの名無しさん

2009/04/14(火) 19:04:59

　　　　（　嫌　生　人　こ
　　　　）だ　.き　.を　れ
　　　　（　お　て　.疑　以
　　　　）！　い　.い　上
　　　　（　　　く　 .な
　　　　）　　 .の　.が
　　　　（　　　.は　.ら
　　　　　～､_　　　　　　 _
　　　　　　　　｀,～～～´
　　　　　＿＿＿_
　　　　／　　　　＼
　　　／　 _ノ　ヽ､_　＼
　／　oﾟ⌒　　　⌒ﾟo　＼
　 |　　　　（__人__）　　　　|
　＼　　　｀ ⌒´ 　　／

0761デフォルトの名無しさん

2009/04/14(火) 20:36:47

　　　　　＿＿＿_
　　　　／⌒　　⌒＼
　　　／（ ●）　（●）＼
　／::::::⌒（__人__）⌒::::: ＼　　だから自演するお！
　 |　　　　　|r┬-|　　　　　|
　＼　　　 `ー'´ 　　／

0762748

2009/04/14(火) 20:54:33

linkのソース読んで何でこんな挙動なのか理解したよ。
ttp://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter7.html#plink
7.2.1 Using Plink for interactive logins
に書いてある説明が default setting に対しても効いているということでした。
オプションの処理コードがplinkとまったく別物なのでした。
みんな知ってるなら教えてくださいよ。

0763デフォルトの名無しさん

2009/04/14(火) 20:54:37

　　　　　　　　＿＿＿_
　　　　　　　／　　三　＼
　　　　　／　─　三ー　＼　　　　だからコイツも自演に決まってるお！
　　　　／　（○）　（○）　＼
　　　　|　　　（__人__）　　　 |
　　　　＼　　　｀ ⌒´ 　　 ,／　

0764748

2009/04/14(火) 20:56:40

>>762 コピペしっぱいしたので訂正
puttyだと引数で指定したホストにつながるのは
オプションの処理コードがplinkとまったく別物なのでした。

0765デフォルトの名無しさん

2009/04/14(火) 21:50:16

>>747
bitbucket は知らないが、 launchpad では普通にプロジェクトのブランチ作れてるのでは

0766デフォルトの名無しさん

2009/04/15(水) 01:43:29

>>765
うん、だから bzr + Launchpad には満足してる。
mercurial の場合 bitbucket の容量制限が不満だから、 Launchpad みたいな
大規模のOSSホスティングサイト無いのかなーって。

0767デフォルトの名無しさん

2009/04/17(金) 11:12:21

TortoiseSVNを1.6.0にしてから、
Cannot accept non-LF line endings in 'svn:log' property
と言われてコミットに失敗するようになった。
いろいろ試した結果、全角文字の直後に改行を入れると
このエラーが出るみたいなんだけど、
誰か根本的な解決方法を知ってたら教えてくれ。

0768デフォルトの名無しさん

2009/04/17(金) 11:16:39

>>767
Subversion r11
http://pc12.2ch.net/test/read.cgi/tech/1230488758/332-

0769デフォルトの名無しさん

2009/04/17(金) 11:34:27

>>768
ありがと。開発版では直ってるのか。そっち使ってみる。

0770デフォルトの名無しさん

2009/04/17(金) 16:11:39

>>769
改行せずにコミットして、後でログを編集すれば改行入れられる
今はそれで逃げてる
1.6.2で直ると思うからそれまで待ち

0771デフォルトの名無しさん

2009/04/17(金) 22:33:05

トートイスと言えばペリカンの万年筆。
それ以外はトータスと読め。

0772デフォルトの名無しさん

2009/04/18(土) 18:33:45

個人で勉強に作ったプログラムとか、ちょっとしたツールとか、それなりにがんばったプログラムとか、
とにかく色々ぶちこみたいんだけど、Mercurialってサブディレクトリだけのチェックアウトとかできないんですね・・・
素直にSubversion使っとけという事なんだろうか。
あれも、リビジョンがごっちゃ混ぜになるみたいだけど。
教えてエロい人

0773デフォルトの名無しさん

2009/04/18(土) 18:41:32

>772
バザーならできる。

0774デフォルトの名無しさん

2009/04/18(土) 20:18:18

douyaruno?

0775デフォルトの名無しさん

2009/04/19(日) 05:23:38

Bazaarもできないだろ。エンハンス予定にはあるが。

0776デフォルトの名無しさん

2009/04/19(日) 06:43:06

TortoiseHg 0.7.4 released

0777デフォルトの名無しさん

2009/04/19(日) 11:56:20

トータスハゲの更新きたか
日本語はどうなったんだ

0778デフォルトの名無しさん

2009/04/19(日) 21:50:01

ttp://bitbucket.org/tortoisehg/stable/wiki/ReleaseNotes

Release 0.7.4
0.7.4 is primarily a bug fix release

Installer changes in 0.7.4
* #146 - disable beep sound in hgtk dialog

Bug fixes in 0.7.4
* #137 - Path Settings: default of default-push path can not be deleted
* #154 - fix duplicating TortoiseHG menus on File menu
* #156 - Commit single file via context menu in Commit Dialog
* #163 - proper method for discovering parent of qtip
* #164 - hide passwords on proxy and email tabs
* Improve display of merge changesets in history dialog
* Fix directory renames from context menu
* Prevent delete events from killing the filter dialog

0779デフォルトの名無しさん

2009/04/20(月) 16:17:23

git cheat sheetをみてやっとgitの使い方がわかったが、
hgユーザからするとrebseの意味が違っていていやだなぁ。

0780デフォルトの名無しさん

2009/04/21(火) 23:28:24

ClearCaseのコマンドラインツールからチェックアウト取り消し操作が激しく糞な点について。

0781デフォルトの名無しさん

2009/04/21(火) 23:34:40

ClearCase自体がちょっとアレだからしかたあるめい

0782デフォルトの名無しさん

2009/04/23(木) 14:47:27

TortoiseGitって日本語ログ、日本語ファイル名はおｋ？

0783デフォルトの名無しさん

2009/04/23(木) 14:58:46

>>782
git 使うならファイル名もログもasciiのみで書くべき

0784デフォルトの名無しさん

2009/04/23(木) 15:38:12

>>782
ログに日本語は使えたが、改行が全然反映されなかった。

0785デフォルトの名無しさん

2009/04/23(木) 18:07:27

>>783
why?

0786デフォルトの名無しさん

2009/04/23(木) 22:22:29

>>785
ファイル名もログもバイト列として扱うから。
まぁログは一応UTF-8推奨でデフォルトではUTF-8以外ははじくから、
あとは改行コードだけ決めておけば使っても良いけど。

0787デフォルトの名無しさん

2009/04/24(金) 08:35:51

なるほど、そしたら、TortoiseGit側にTortoiseHgのmbcs拡張みたいに変換機構があれば、いけるということか。
下手すると、SJISとか、UTF-16で突っ込んでしまう可能性がありますね

0788デフォルトの名無しさん

2009/04/24(金) 08:37:02

http://github.com/unageanu/jiji/tree/master
githubとか見てたら、思いっきり日本語ログ使っているプロジェクトとかあるんだけど、大丈夫なのかな

0789デフォルトの名無しさん

2009/04/24(金) 09:44:26

ごめん、UTF-8なら大丈夫なのね…

0790デフォルトの名無しさん

2009/04/24(金) 09:45:19

TortoiseGit使ってみているんだが、cloneできない。

コマンドラインスイッチ"-v"がないって言われるんだが…

git.exe clone -v "git://github.com/to/tombloo.git" "T:\work\tombloo"
error: unknown switch `v'

0791デフォルトの名無しさん

2009/04/24(金) 09:57:07

>>790
本家のIssueに登録しておいた。（先にgoogle groupsで聞くべきだったか？）

>>788
>>790問題でcloneできなかったので、CYGWIN git(UTF-8)でcloneしてみて
TortoiseGitでlog見てみたが普通に見られるな。特に化けてない。
問題は入力だな。

0792791

2009/04/24(金) 12:17:16

TortoiseGitが MSYSGITではなく、CYGWIN(UTF8化)版のgitを先に認識しているようで、
そのため日本語が通っているように見えるだけかもしれません。
注意してください。

0793デフォルトの名無しさん

2009/04/25(土) 19:33:21

http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html
Mercurialかぁ…

0794デフォルトの名無しさん

2009/04/26(日) 15:15:16

mercurial人気だねぇ。

git: ファイル名はバイナリ、コミットログもバイナリ(utf-8推奨)
- シェルとかperlとか必要、
- ファイル名変更したらシラネ。
- 1リポジトリ1ブランチ
hg: ファイル名はバイナリ、コミットログはUnicode
- シェルとかPerlとか不要でプラグインもPythonだから基本クロスプラットフォーム。
- ファイル名変更したらシラネ。
- 1リポジトリ1ブランチ
bzr: ファイル名もコミットログもUnicode
- シェルとかPerlとか不要でプラグインもPythonだから基本クロスプラットフォーム。
- ファイル名やディレクトリ名変更してもきちんと履歴管理するよ。
- 1リポジトリ1ブランチにも1リポジトリに多ブランチにも対応
になってるから、
git=最初からposixしか考えてないプロジェクト、もしくはPythonに対抗心を燃やすRubyプロジェクト用。
bzr=クロスプラットフォーム。svnにある機能は基本全部対応。汎用。
とスタンスが180度違っていいんだけど､ mercurial は微妙過ぎる。

0795デフォルトの名無しさん

2009/04/26(日) 15:24:05

なんだかどれに移行していいもんか迷っちゃって
SVNから動けねぇ・・・

一応それでまわってるわけだから別に無理して移行しなくてもいいのかもしれんけど。

0796デフォルトの名無しさん

2009/04/26(日) 15:36:41

仕事ではしばらく Subversion から移行できんだろうしなぁ

0797デフォルトの名無しさん

2009/04/26(日) 15:52:23

中央リポジトリはsvnのまま簡単には移行できないんで、
個人的にbzr使って対応している。
しかし、Linux(RHEL)でbzrを動かせてないので……

0798デフォルトの名無しさん

2009/04/26(日) 16:10:03

みんなで使うのはsvn。
hgは手元の管理にしてる。

0799デフォルトの名無しさん

2009/04/26(日) 17:19:50

gitは速いって利点があるけど, hgはなんともいえず微妙.
しかしMozillaはhg.

0800デフォルトの名無しさん

2009/04/26(日) 17:55:26

hg 速いけどなぁ

0801デフォルトの名無しさん

2009/04/26(日) 19:45:15

>>794
hgもgitもファイル名変更は履歴管理してるよな?

0802デフォルトの名無しさん

2009/04/26(日) 20:03:00

git mvでできるよ.

0803デフォルトの名無しさん

2009/04/26(日) 20:55:12

>>801,802
それ、「ファイル名変更した」っていう情報のコミットをしているだけで、
SubversionやBazaarみたいに一つのファイルの連続した履歴としては
管理してないでしょ?

$ cat >abc
aaa
bbb
ccc
$ bzr add abc
$ bzr commit -m "add abc"
$ bzr mv abc abcd
abc => abcd
$ bzr commit abcd
$ cat >>abcd
ddd
$ bzr commit -m "add ddd"
$ bzr diff abcd -r1..3
=== renamed file 'abc' => 'abcd'
--- abc 2009-04-26 11:45:33 +0000
+++ abcd 2009-04-26 11:46:30 +0000
@@ -1,3 +1,4 @@
aaa
bbb
ccc
+ddd

0804デフォルトの名無しさん

2009/04/26(日) 20:57:39

$ cat > abc
aaa
bbb
ccc
$ git add abc
$ git commit -m "add abc"
$ git mv abc abcd
$ git commit -m "rename"
$ cat >> abcd
ddd
$ git add abcd
$ git commit -m "add ddd"
$ git diff 9b61d..41f9f
diff --git a/abc b/abc
deleted file mode 100644
index 1802a74..0000000
--- a/abc
+++ /dev/null
@@ -1,3 +0,0 @@
-aaa
-bbb
-ccc
diff --git a/abcd b/abcd
new file mode 100644
index 0000000..35fbd83
--- /dev/null
+++ b/abcd
@@ -0,0 +1,4 @@
+aaa
+bbb
+ccc
+ddd

0805デフォルトの名無しさん

2009/04/26(日) 21:19:21

>>803
RTFM
$ git --no-pager diff -M HEAD~~ HEAD
diff --git a/abc b/abcd
similarity index 75%
rename from abc
rename to abcd
index 1802a74..35fbd83 100644
--- a/abc
+++ b/abcd
@@ -1,3 +1,4 @@
aaa
bbb
ccc
+ddd

0806デフォルトの名無しさん

2009/04/26(日) 21:27:09

>>803
$ hg init
$ cat >abc
aaa
bbb
ccc
$ hg add abc
$ hg commit -m "add abc"
$ hg mv abc abcd
$ hg commit -m "rename to abcd"
$ cat >>abcd
ddd
$ hg commit -m "add ddd"
$ hg diff --git -r 0 -r 2
diff --git a/abc b/abcd
rename from abc
rename to abcd
--- a/abc
+++ b/abcd
@@ -1,3 +1,4 @@
aaa
bbb
ccc
+ddd

0807デフォルトの名無しさん

2009/04/26(日) 22:26:43

>>803
http://ja.wikipedia.org/wiki/Git
>Gitでは、リネームの検出をスナップショット
>作成時ではなく履歴のブラウズの際に行う

0808デフォルトの名無しさん

2009/04/26(日) 22:37:52

結局gitもhgもファイル名変更してもおｋじゃん

0809デフォルトの名無しさん

2009/04/26(日) 22:39:54

>>805,806 ごめん、勘違いしてたみたい。これもできる?
$ bzr init repo_a
$ cd repo_a/
$ mkdir dir_a
$ cat >dir_a/a
aaa
$ bzr add dir_a/a
adding dir_a
adding dir_a/a
$ bzr commit -m "add dir_a/a"
$ bzr branch . ../repo_b
$ bzr mv dir_a dir_b
$ bzr commit -m "rename dir"
$ cat >> dir_b/a
bbb
$ bzr commit -m "add bbb"
Committed revision 3.
$ cd ../repo_b
$ bzr merge -c3 ../repo_a
M dir_a/a
All changes applied successfully.
$ bzr diff
=== modified file 'dir_a/a'
--- dir_a/a 2009-04-26 13:36:57 +0000
+++ dir_a/a 2009-04-26 13:38:12 +0000
@@ -1,1 +1,2 @@
aaa
+bbb

0810デフォルトの名無しさん

2009/04/26(日) 23:09:14

って～か、>>794読みながら、間違いだらけじゃんとか思ってたんだけど。

gitなら、コミットログもUTF-8だよね。

> 1リポジトリ1ブランチにも1リポジトリに多ブランチにも対応

これが、何を表現しているのかわからなかったんだけど、
bzr split のこと？

git には、submodule と、 subtree って、仕組みがあるんだけど、
bzr split と、機能的には被るのかね。

0811デフォルトの名無しさん

2009/04/26(日) 23:35:21

>>810
gitのコミットログはバイナリ。デフォルトではutf-8じゃないバイナリ列を拒否る
設定になっているから実質utf-8と言っていいけど。

1リポジトリ多ブランチはbzr でいう init-repo のこと。Subversionでも普通に
repo/trunk, repo/tags/footag, repo/branches/foo_branch ってするよね。

1リポジトリ1ブランチだと、データの共有は基本的にハードリンク頼みだから、
ローカル間のbranchやpullじゃないと共有されない。
他にも、Windows環境ではハードリンクを適切に扱えるツールが少ないから、
バックアップソフトがハードリンク×n個を n個のファイルとしてコピーしたり
しやがる。

0812794

2009/04/26(日) 23:41:26

勘違いしてた。hgやgitが管理しないのはファイル名じゃなくてディレクトリ名だ。

$ hg init repo_a
$ cd repo_a/
$ mkdir dir_a
$ cat >dir_a/a
aaa
$ hg add dir_a/a
$ hg commit -m "add a"
$ hg clone . ../repo_b
$ hg mv dir_a dir_b
$ hg commit -m "rename dir"
$ cat >>dir_b/a
bbb
$ hg commit -m "add bbb"
$ hg diff -r0 dir_b/a
diff -r 6573e09a792d dir_b/a
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dir_b/a Sun Apr 26 23:39:25 2009 +0900
@@ -0,0 +1,2 @@
+aaa
+bbb

gitは使う機会ないからディレクトリ名の変更を追跡しないってのも勘違いかもしれん。

0813デフォルトの名無しさん

2009/04/26(日) 23:49:46

>>811
bazaar厨が必死すぎるwww

0814デフォルトの名無しさん

2009/04/27(月) 00:03:00

1リポジトリ多ブランチってhgでも出来ると思うけど。

0815デフォルトの名無しさん

2009/04/27(月) 00:19:31

>>814
複数のheadを持てるっていう意味で?
でもtipは一つだから、普通運用する時は branch ごとに
ディレクトリを分ける。そんときにリポジトリまで分離されてしまう。

0816デフォルトの名無しさん

2009/04/27(月) 01:45:44

>>812
hgはファイルしか追いかけないのは事実だが、履歴は管理されるよ
$ hg diff -gr0 dir_b/a
diff --git a/dir_a/a b/dir_b/a
copy from dir_a/a
copy to dir_b/a
--- a/dir_a/a
+++ b/dir_b/a
@@ -1,1 +1,2 @@
aaa
+bbb

0817デフォルトの名無しさん

2009/04/27(月) 07:30:33

>>816
へぇ、今度から -g 使うよ。thanx.
あと、 transplant extension を有効にしたんだけど、
ディレクトリ名変更したブランチからcherry pickingできなかった。
これも何かのオプションで >>809 と同じことできるようになるのかな。

git はマニュアル読んでも使い方が判らん…普段hgとbzrしか使わない
せいもあるんだけど、gitってリビジョン指定の方法とか独特過ぎない?

0818デフォルトの名無しさん

2009/04/27(月) 08:13:13

>>794
hgは１リポジトリ多ブランチだよ。
gitもそうでなかったか？

0819デフォルトの名無しさん

2009/04/27(月) 09:45:16

ちょうどブランチの話題がでているので質問です。
GitでのブランチのようなことをMercurialでしたい場合にはどうするんでしょうか。

0820794

2009/04/27(月) 10:30:33

>>818
ごめん、書き方が悪かった。単純に1リポジトリに複数のbranchを
格納できるってだけじゃなくて、svnみたいに各ブランチにパスを割り当てて
アクセスできるってことを言ってたんだ。
githubにしろbitbucketにしろ、ブランチ切るとリポジトリまで分割されちゃうよね。

0821デフォルトの名無しさん

2009/04/27(月) 11:22:41

>>794はなかったことにしてもらえよｗ

0822794

2009/04/27(月) 12:28:09

>>821
そうだな。書き直すよ。

git: ファイル名はバイナリ(クロスプラットフォームでの日本語ファイル名は諦める)
- シェルとかperlとか必要。
- cherrypick可能。ディレクトリ名変更をまたいだcherrypickは不明
- git-svn はほぼ安定

hg: ファイル名はバイナリ(fixutf8拡張を使えばutf8ファイル名が可能だがまだ完全ではない)
- シェルとかPerlとか不要でプラグインもPythonだからクロスプラットフォーム。
- cherrypickは同梱されているtransplantプラグインで対応。ディレクトリ名変更をまたいだcherrypickは不可能？
- hgsubversion はまだ実験版

bzr: ファイル名はUnicode(Windows/Linux/Macの間で日本語ファイル名問題なし)
- シェルとかPerlとか不要でプラグインもPythonだからクロスプラットフォーム。
- cherrypick は完璧
- bzr-svn はほぼ安定

0823デフォルトの名無しさん

2009/04/27(月) 12:37:58

「シェルとかPerlとか」って何のこと？
なんで Python がクロスプラットフォームと言いながら Perl はダメなの？

0824デフォルトの名無しさん

2009/04/27(月) 12:45:38

>>823
そうだよな、Windowsをプラットフォームに考えたらどっちも一緒。

0825デフォルトの名無しさん

2009/04/27(月) 12:48:55

今みたいなノリで、このスレで指摘・突っ込みしながら
バージョン管理システムの比較表を作っていけば
そこそこ役に立つ比較ができるんじゃないだろうか

0826デフォルトの名無しさん

2009/04/27(月) 13:03:09

>>825
そこまでするなら、GUI フロントエンドの熟成度も併記してほしいと思いますです。

0827デフォルトの名無しさん

2009/04/27(月) 13:09:32

>>823
git のプログラムはCで書かれたプログラムとPerlで書かれたプログラムとシェルスクリプトが混ざってる。
CプログラムはPosix APIを利用しているのでmingwやcygwinに依存するし、
Perlも基本そのCygwin/mingw+msys環境用のものを使わないといけない。既にActivePerl使ってたり、
cygwinユーザーなのにmsysgit入れたりするとパスが混じりまくってワケワカメ。
3rd partyによるプラグインがWindowsではうまく動かない可能性もある。

MercurialやBazaarはたくさんのプログラムの寄せ集めではなくて一つのPythonプログラム。
Cで書かれている部分も単体プログラムではなくてPython拡張モジュールだから
Posix互換環境に依存しないし、Visual C++等のコンパイラでもコンパイルできる。

既にLinux/Unixどっぷりの人間にはgitが使いやすいかもしれないけれど、そうでない人間にとっては
シェルスクリプトもPerlもautotoolsもバッドノウハウの集大成。Cygwinになるとなおさらバッドノウハウが
多いから、みんなで環境をそろえるのが大変。
それに比べるとPythonはバッドノウハウ度が少ないので、自分でプラグインを作るのも
みんなで環境をそろえるのも容易。

0828デフォルトの名無しさん

2009/04/27(月) 13:18:07

Mercurialってバイナリdiffかなんかで一部Cを使っていたような、必須かは知らないけど。んで、他の部分もCで置き換えていくって話聞いた覚えあるけど。
あとBazaarも高速化の為に一部Pyrexを使っていたはず。Pythonの代替実装あって必須じゃなかったはずだけど。

0829デフォルトの名無しさん

2009/04/27(月) 13:34:14

>>828
うん、速度が必要な部分はCで書かれてる。
Pythonの拡張モジュールだからクロスプラットフォームなPythonAPIを利用するし、
ビルドのもPythonの標準ライブラリによって行われる。
posix準拠のCプログラムと違って最初からWindowsでも動くように設計されている。

例えば、Pythonなら open(u"ほげ表\クソ", "rb") とすると Windows の Unicode API
を使ってファイルを開く。BazaarはこのPythonの利点を活かしてUnicodeファイル名に
対応している。

0830デフォルトの名無しさん

2009/04/27(月) 19:45:30

>>825
ああ、そういうのあるとすごく助かる。
特定のシステムに傾倒しすぎないよう注意しながら追記しないといけないだろうけど。

0831デフォルトの名無しさん

2009/04/27(月) 20:52:19

とりあえず叩き台として簡易比較作ってみた

【インストール】
git → 簡単だがActivePerl等が入っていると共存が不便
hg, bzr → 簡単

【動作速度】
git > hg >= bzr が定説
ただしバージョンアップ等によって変動するので参考程度に

【日本語ファイル名】
git → 諦めたほうがよい
hg → fixutf8拡張を使えばutf8ファイル名が可能だがまだ完全ではない
bzr → 問題なし

【空ディレクトリ】
git, hg → 追跡対象に含めない
bzr → 追跡対象に含める

【ネットワークプロトコル対応】
git → ？
hg → ？
bzr → http, sftp, ftp, 独自プロトコルなど充実。ただし手軽なwebブラウジングサーバーがない

【ブランチの切り替え】
git → ？
hg → ？
bzr → ディレクトリ移動

【そのほか・備考】
・今のところ3つのなかで一番シェアが大きいのは、たぶんgit
・gitのコマンド体系は、一般的なバージョン管理システムと比べるとやや独特。慣れが必要

0832デフォルトの名無しさん

2009/04/27(月) 21:09:21

Google Summer of Code

Towards a better inotify extension
Lightweight copies/renames
Using mercurial as a client for git repositories
Mercurial on Py3k

0833デフォルトの名無しさん

2009/04/27(月) 21:41:29

そうかMercurialのページにSoCに！って掲示出てたよな。
Pythonが、Mercurialに移行する予定だし、この先、伸びそうなのはMercurialか。

0834デフォルトの名無しさん

2009/04/27(月) 21:51:17

【Web UI】
git -> gitweb (同梱)
hg -> hg serve (内包)
bzr -> loggerhead (別アプリ)

【trac】
git, hg -> ○ (複数リポジトリは面倒)
bzr -> ○ (複数リポジトリはsvnと同等)

0835デフォルトの名無しさん

2009/04/27(月) 21:55:21

【個人公開リポジトリ置き場】
git -> github (無料で300MB, wiki, ticketあり)
hg -> bitbucket (無料で150MB、 wiki, ticketあり)
bzr -> launchpad (無料無制限、 wiki, ticketあり)

0836デフォルトの名無しさん

2009/04/27(月) 22:04:20

【大規模ユーザー】
git -> Linux, gnome, rails
hg -> Python, Java, OpenSoralis
bzr -> Ubuntu, MySQL, GNU(bzrはGNU公式プロジェクトの一つ)

>>833 3つともユーザー増え続けて、svn一人負けという展開。

0837デフォルトの名無しさん

2009/04/27(月) 22:09:17

>>836
この流れでいきなりsvnの名前が出てきて驚いたｗ
CVSは負けてないのか

0838デフォルトの名無しさん

2009/04/27(月) 22:30:29

CVSは化石だろJK
gitの利用は順調に増加中だね。でもコマンド体系に難アリ。内臓のgitwebよりcgitの方が好き。
MercurialはSunが使っていたけどOracleに買われてどうなるやら。今はGoogleが押しているようだけど、Androidの開発にはgitが使われているし…。
bzrは伸びるも縮むもこれからだね。bzr-gitももうすぐ完成するらしいし。あとlaunchpadにはまだwikiはない。そのうち出来るだろうけど。

0839デフォルトの名無しさん

2009/04/27(月) 22:42:18

loggerheadは元々hgwebの派生って話だけどそうは見えんよなぁ。今じゃまったく別物に見える。
launchpadのオープンソース化が近し。他のVCSに対応させたいなら頑張ってパッチ書いてみるといいかも。まぁ7月の話だが。

0840デフォルトの名無しさん

2009/04/28(火) 00:02:03

>>837
いやだって、どれか一つを勝たせたり負かせたりしたい人間がいても
現実に３つともどんどんシェア伸ばしてるからどれが勝ちとか言えないし。

0841デフォルトの名無しさん

2009/04/28(火) 00:06:25

cleartools>unco -keep *

0842デフォルトの名無しさん

2009/04/28(火) 00:31:24

gitやhgがシンプルなポリシーでツールを作り上げてるのに対して、
Bazaarは最強指向というか迷走してるというか。

Pythonがhgに決定しちゃった！
=> bzr: 「bzr-svn, bzr-git, bzr-hg が全部きちんと動けばどのプロジェクトがどのVCS選んでもbzr使えるさ！」

svnの無くてもあまり困らない機能(external referenceとか)
=> hg/git: 「なくても運用でなんとでもなるよね」
=> bzr: 「どんな運用方法もそのまま受け入れるぜ！NestedTreeもうすぐ実装できるから待ってな！」

毎月のバージョンアップが見せる開発力は清々しいほどでもあるが、
バージョンアップに付き合わされる運用側は面倒になってhgに逃げるという。

0843デフォルトの名無しさん

2009/04/28(火) 00:43:30

>>842
>svnの無くてもあまり困らない機能(external referenceとか)
git submodule?

0844デフォルトの名無しさん

2009/04/28(火) 01:06:57

>>843
外部のリポジトリを取り込むのはhg/gitにもあるのか。
http://www.selenic.com/mercurial/wiki/index.cgi/NestedRepositories

bzrはsplitもあるからもともと一つだったtreeの一部を切り離して
他のプロジェクトの外部リファレンスにって使い方もできるけど、
svnの「いつでもどこでも自由に切って持って行きな！」ていうのは
さすがにムリっぽい。

0845デフォルトの名無しさん

2009/04/28(火) 01:50:03

gitがrevisionのことをcommitというのはなぜか？
commitは動詞だろうが！

0846デフォルトの名無しさん

2009/04/28(火) 07:16:45

ありのまま今起こったことを話すぜ。
bzr pull に少し時間がかかったのでアレ？と思って確認すると、
svnのワーキングコピーだった。
きちんと svn up したのと同じ状態になっていた。

svnのリポジトリどころかワーキングコピーまで、bzr (bzr-svnプラグイン+)
にとってはbranchフォーマットの一種扱いなのね。変態だなぁ。

0847デフォルトの名無しさん

2009/04/28(火) 12:27:38

質問です。

Mercurial 1.2.1をWindowsのコンソールで使ってるんですが、
表示されるメッセージを英語に切り替えるにはどうしたらいいですか？

chcp 65001
HGENCORDING=utf-8

に設定してもPythonが動作しないので気になります。
一応、個人で使ってるのでそのまま文字化けしてても作業自体は問題ないです。

0848デフォルトの名無しさん

2009/04/28(火) 13:14:17

レスでまとめ作ると後で探すの面倒だから、
適当なwikiのページ借りてまとめ作ったらどうだろうか？

0849デフォルトの名無しさん

2009/04/28(火) 13:15:41

誰かatwikiで借りてきてください

0850デフォルトの名無しさん

2009/04/28(火) 13:24:05

0851デフォルトの名無しさん

2009/04/28(火) 13:39:55

>>850
http://www5a.biglobe.ne.jp/~shinotan/miru.JPG

0852デフォルトの名無しさん

2009/04/28(火) 14:23:40

>>794
darcsは？

windowsで動くdarcsのバイナリがみつかんない
自分でコンパイルなんてしてらんないんだけど

0853デフォルトの名無しさん

2009/04/28(火) 14:37:15

>>852
hg, git, bzr と違って人気ないじゃん。
俺はこの3つですら使いこなせてないから、もうこれ以上増やさないでくれ。

0854デフォルトの名無しさん

2009/04/28(火) 14:40:49

ブラウザの話題でもいるよね、こういう「俺が使えるもの以外は淘汰されろ」って奴。

0855デフォルトの名無しさん

2009/04/28(火) 14:44:17

>>838
ttp://q.hatena.ne.jp/1237792736
CVS強すぎｗｗ

0856デフォルトの名無しさん

2009/04/28(火) 14:46:16

>855
RCSとか、もう化石になってると思ったのに。

0857デフォルトの名無しさん

2009/04/28(火) 14:50:27

うちは今CVSからsvnに移行中だ
全員一斉に切り替えなきゃならんからめんどい・・・

0858デフォルトの名無しさん

2009/04/28(火) 15:05:29

darcsの利点
http://www.jmuk.org/diary/2007/12/01/0

0859デフォルトの名無しさん

2009/04/28(火) 15:05:50

>>856
はてなにはポイント乞食がいるので最初の選択肢と最後の選択肢は信用できない。
わけもわからずに最初(または最後)の選択肢を選んで投票するバカをうまく排除しないと
有意な結果が得られない。

0860デフォルトの名無しさん

2009/04/28(火) 15:11:20

>>855
CVSは過去の資産（リポジトリ）がたくさん残っているのだと思う。

自分はdump, restore, dumpfilterのおかげでメインはSubversionを使ってる。
リポジトリをメンテナンスできるのは強い。

最近はSubversionでチェックアウトして手元ではMercurialで管理してる。
.svnと.hgが同じディレクトリに仲良く共存してるｗ

0861デフォルトの名無しさん

2009/04/28(火) 15:50:15

仲が良いかは些か疑問だが。

0862デフォルトの名無しさん

2009/04/28(火) 16:59:05

>>794
多ブランチがなにをいいたいのかさっぱりわからんのだが
ひとつのリポジトリに複数の関連のないプロジェクトをいれられるかどうかという話なら git でもできる

mkdir project; cd project; git init; echo pu > 1.txt; git add 1.txt; git commit -m '1'; cd ..
mkdir another; cd another; git init; echo pe > 2.txt; git add 2.txt; git commit -m '2'; cd ..
cd project; git remote add another ../another; git remote update; git checkout another another/master;
git remote rm another; cd ..; rm -rf another

こうしとけば project のリポジトリに master と another のまったく別のプロジェクトが同居してる状態になる
あとは git checkout でいくらでも移動できる

git remote つかわなくてもできそうだな...

0863デフォルトの名無しさん

2009/04/28(火) 17:00:11

おっと git checkout の際に -b が必要だな

0864794

2009/04/28(火) 17:59:16

>>862
repos/
+proj1/
| + trunk/
| + branches/
| | + maint/
+ proj2/

こんな感じで、リポジトリの中にサブディレクトリを作ってサブプロジェクトや
ブランチを放り込む方式をsvnではよく使うじゃん。それのこと。
changesetはbranchじゃなくてrepositoryで管理するから、同一repository内の
別のbranchに同一のchangesetをpushしたらきちんと同一部分が検出されて、
pushの転送量やサーバーのHDD使用量を節約できる。

言い方がまずかったと >>820 で反省して、 >>822 では削除したからもう許して。

0865デフォルトの名無しさん

2009/04/28(火) 19:43:40

>>864
できるできないという視点でいったら、
そういう運用できない管理システムなんてないのでは？
もちろん効率や使い勝手などを鑑みれば
現実的でない運用になるシステムもあるだろうけど。

そもそも、少なくとも分散VCSなら、
そういう運用をする必要性が感じられない。
Subversionは、その方法でしかブランチができないというだけで、
そこに合わせる必要性はないと思うけども。

0866794

2009/04/28(火) 21:25:47

>>865
うん、そうだね。大して重要じゃないよね。

clone リモート/abranch ローカル
ローカル作業
clone ローカルリモート/newbranch (転送はローカル作業分だけ)
ってするだけでnewbranchが自動でabranchと関連づけられるとか、
Tracで特別な設定なしで複数サブプロジェクトを管理できるかとか、
そーゆーこと考えてたんだけど、どうでも良いよね。

>>822 では削除したからもう許して。

0867デフォルトの名無しさん

2009/04/28(火) 21:51:12

仮にディレクトリ＝ブランチの運用したとして、
そういう操作ができてしまうのは危険な気がするけど・・・

hgしか使ったことないけど、たぶんどの分散VCSでも、
トランザクションと、トランザクションの転送は分けて考えてるよね。

Tracについては、複数リポジトリの対応待ちだな。

0868デフォルトの名無しさん

2009/04/28(火) 21:59:20

>>867
トランザクションって何を心配しているのか知らないけど、
bzr は init-repo しておけば自動で >>866 になるよ。
ただ、trac-bzrは最適化ができてないのか若干重い気がするから、
結局 tracがあるサーバーには svn を入れて bzr-svn 使ってるけど。

0869デフォルトの名無しさん

2009/04/28(火) 22:16:58

bzr の shared repository はサーバー側じゃなくてクライアント側でも
すごく便利で、

bzr init-repo foo
cd foo
bzr branch http://svn.foo.org/branch/1.0 foo-1
bzr branch http://svn.foo.org/trunk foo-trunk

こうやると、複数のbranchを追いかけるときに古いリビジョンは共有できる。
svnからのbranchってリビジョン一個一個ダウンロードで遅いから
この機能は必須。
git-svn でも同等のことできそうだけど知らない。

0870デフォルトの名無しさん

2009/04/28(火) 22:43:34

>>848-849
Wikipedia に比較ページ作るんじゃなくて、新しくまとめWiki借りた方が良い？
その方が良いのなら wikiwiki.jp あたりで適当に作ってくるけど

0871デフォルトの名無しさん

2009/04/28(火) 22:59:36

Wikipediaに比較ページあるけどねいちおう
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

0872デフォルトの名無しさん

2009/04/28(火) 23:09:04

Wikipediaで議論するとぐだぐだになりやすいのが難点か

0873デフォルトの名無しさん

2009/04/28(火) 23:37:21

>>869
branchとtrunkで2回取ってこないといけないことが一番の無駄といことに気付けよwww

0874デフォルトの名無しさん

2009/04/28(火) 23:39:47

>>873
だってsvnで公開されてるOSS多いんだもん。仕方ないじゃん。

0875デフォルトの名無しさん

2009/04/28(火) 23:43:26

>>873
gitだと、例えばlinusツリーとlinux-nextツリーをローカルにcloneしてくるときに
一度にcloneできるの？

0876デフォルトの名無しさん

2009/04/29(水) 00:49:46

>>870
たぶんかりたほうがいい気がする。

0877デフォルトの名無しさん

2009/04/29(水) 01:39:42

>>875
remote add して remote update で何が不満?

0878デフォルトの名無しさん

2009/04/29(水) 04:40:05

hgが採用しているbranchの考え方が一番しっくりくる。

0879デフォルトの名無しさん

2009/04/29(水) 05:20:16

こんな記事が出たよ。
ttp://www.atmarkit.co.jp/news/200904/28/googlecode.html

↓記事中のリンク
ttp://code.google.com/p/support/wiki/DVCSAnalysis
ttp://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_1.html (>>207)

0880デフォルトの名無しさん

2009/04/29(水) 08:20:57

>>879
へぇ、gitのClient Storage Managementとかってやつ、よさげだなぁ

0881デフォルトの名無しさん

2009/04/29(水) 08:30:51

>>877
何が不満と言われても、git知らないから訊いてるのに。
でも、remote add / remote update 便利そうだな。
svnリポジトリも remote add できるの？

0882デフォルトの名無しさん

2009/04/29(水) 09:04:43

これどこで聞いたらいいのかわからんのだが、
Dropboxというストレージwebサービスがあり、これが履歴管理機能がついているんだ。
これがとにかく簡単で、特定ディレクトリにファイルを入れるだけで自動同期、自動履歴管理に入る。

こういう簡単さを既存技術で、かつローカルで環境(もしくはLAN内でもない)で行ういい方法ないですかね。
簡単にいうならば、コピーするくらいの感覚でバージョン管理できるみたいなの

0883デフォルトの名無しさん

2009/04/29(水) 10:12:17

>>882
Dropboxに>>882のいう機能がつくらしい
ただ、>>882の機能の特化したソフトではないから、望むものになるかはわからんけど

【落箱】　Dropbox　【共有/同期/版管理/OS非依存】
http://pc12.2ch.net/test/read.cgi/software/1221752091/406

406 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2009/04/27(月) 15:58:27 ID:mMA6f1g5P
次期アップデートでローカルネットワーク内での同期が実装されるらしいね
PC３台ぐらいを使い分けてるから同期スピードが上がると助かるわ

0884デフォルトの名無しさん

2009/04/29(水) 13:03:46

Dropboxとかって基本的に一人相手のだよね。
複数の箇所から非同期に編集されることはあんまり期待してなかったような。

0885デフォルトの名無しさん

2009/04/29(水) 17:50:07

>>884
確かにそうですね。

>>882のように、ファイル共有＋バージョン管理用途だと
webdav + svnみたいになるんでしょうかね…
samba+デイリーcronでsvnにコミットという手もあるかもしれません。

100万ファイルくらいを予定しているんですが、絶えうるもんですかね。
まずTortoise系は使っちゃ駄目そうｗ

ちょっとずれるけど、gitとかhgはともかく、svnだとすでに.svnがあるディレクトリつっこんだら.svnかぶらないものなの？

0886デフォルトの名無しさん

2009/04/29(水) 18:13:10

./.svn を svn の管理対象にするってわけか・・・

0887870

2009/04/29(水) 19:08:12

適当にWikiまとめてみた
http://wikiwiki.jp/vcs/

0888デフォルトの名無しさん

2009/04/29(水) 19:11:50

まず過去ログ

0889デフォルトの名無しさん

2009/04/29(水) 20:14:23

>>887
乙
暇なときにテーブル形式の早見表追記してみるか・・・

0890デフォルトの名無しさん

2009/04/30(木) 09:08:17

>>882
ﾜﾛﾀ、それ今卒研で構築中。
うまくいけば言ったとおりのものをbazaarで作れるようになるんだが、
教授がすんなり認めてくれるかが難点。

0891デフォルトの名無しさん

2009/04/30(木) 10:37:38

>>882
そういうのあったらいいなぁ。
うちの会社のオジサン連中が誤ってファイルの上書きをすることが多いので
バージョン管理システムを使わせたいのだけれど、TortoiseSVNでも難しすぎる。
ディレクトリに放り込んだら自動的に履歴管理してくれるのがあると便利。

0892デフォルトの名無しさん

2009/04/30(木) 10:54:26

つ[clear case]

0893デフォルトの名無しさん

2009/04/30(木) 11:09:55

>>887
乙。比較表もどうせだったら表形式にして、各項目ごとにページ作って表からリンク張ったらどうだい？
そうすれば、全体を見たい場合は表を見て、詳しい比較を見たい場合は各ページにすぐ飛べると思うから。

0894デフォルトの名無しさん

2009/04/30(木) 11:27:54

>>893
wikiなんだから、自分で編集すれば良いんじゃね？

0895デフォルトの名無しさん

2009/04/30(木) 11:37:31

>>894
ごもっともなんだけど、人にページを作ってもらってるからコンセンサスを取っといたほうがいいかと思って。
特にページを大きく改変する提案だから、無断で変えて人が混乱したりスレが荒れたりするのは避けたいと思うから。

というわけで、>>893のような感じに編集しておｋ？

0896デフォルトの名無しさん

2009/04/30(木) 12:03:56

Windows Storage Server使っとけ

0897デフォルトの名無しさん

2009/04/30(木) 12:13:45

>>895
各項目ごとにページ作るのは細かすぎる気がする。
俺は今のスタイルが好き。
表が欲しいなら別ページに表を作って、リンクは今の一覧の各項目を指すように
するのはどう?

0898デフォルトの名無しさん

2009/04/30(木) 12:45:20

>>891
VAXのVMSがそんなかんじだった

0899デフォルトの名無しさん

2009/04/30(木) 12:46:38

>>891
etckeeper

0900デフォルトの名無しさん

2009/04/30(木) 13:31:12

>>891
svnfsとかbzrfsとか？

0901デフォルトの名無しさん

2009/04/30(木) 15:37:55

netbeasns試しに使ってみたら
デフォルトでMurcurial入ってた

0902デフォルトの名無しさん

2009/04/30(木) 16:54:45

Easy Git
http://www.gnome.org/~newren/eg/
http://github.com/blog/333-easy-git
gitのラッパとのこと。これで勝つる！

0903デフォルトの名無しさん

2009/04/30(木) 21:50:24

無理

0904デフォルトの名無しさん

2009/05/01(金) 14:55:23

なんだかんだでdarcsにおちついた
ubuntuのdarcsのバージョンが古くてwikiのコマンド使えない

0905デフォルトの名無しさん

2009/05/01(金) 15:00:21

darcsのcheat sheetを検索しても出てこない
ここら辺がユーザー少ないソフトを使うときの不便さか

0906デフォルトの名無しさん

2009/05/01(金) 15:04:57

>>904
コンパイルすれば？て言おうと思ったがHaskell使うのかこれ＿|￣|○

0907デフォルトの名無しさん

2009/05/01(金) 16:37:57

で、ghcのコンパイルが超めんどいわけだw

0908デフォルトの名無しさん

2009/05/01(金) 16:39:46

Ubuntuならghcのパッケージあるだろ。

0909デフォルトの名無しさん

2009/05/01(金) 16:57:31

遊びじゃねーんだよ

0910デフォルトの名無しさん

2009/05/02(土) 01:45:47

>>904
もしよければ、darcsに落ち着いた理由とか教えてください

0911デフォルトの名無しさん

2009/05/04(月) 18:33:03

2009-05-02: TortoiseHg 0.7.5 released
0.7.5 is a bug fix release

0912デフォルトの名無しさん

2009/05/04(月) 18:44:09

もうhgはあきらめろ

0913デフォルトの名無しさん

2009/05/04(月) 19:30:30

使えねーハゲだぜ

0914デフォルトの名無しさん

2009/05/06(水) 06:53:28

ちょいとお聞きしたいのですが、gitやhg、
というか、githubやbitbucketなど(sourceforgeとかでもいいんですが)公開するオープンソースのアプリで、
ソースにパスワードなど個人情報が含まれるファイルの処理をどうしたものかと思っています。

そういうものってどうするのが定石なのでしょうか？

例えば、config.yml みたいに設定を外に出しておいて、
バージョン管理ソフトでは除外指定。
で、初期化コマンドかジェネレータみたいなのを用意して、
そこでユーザーがconfig.ymlを生成しつつプロンプトでパスワードなどを聞くとか…

他のソフトではどうしているのかな、と思いまして
お力をお貸しください。

0915デフォルトの名無しさん

2009/05/06(水) 07:34:17

>>914
gnomeアプリならSeahorseやgnome-keyring使うべし

0916デフォルトの名無しさん

2009/05/06(水) 08:41:20

>>915
ありがとうございます。
Seahorseやgnome-keyringをちょっと見てみました。

Rubyのちょっとしたスクリプトなんすけど、Windowsでの動作も考慮に入れたいので、
そのままは使えないと思うのですが、
概念は参考になりました。
やっぱりこういうのは考える人はいるんですね

0917デフォルトの名無しさん

2009/05/06(水) 08:46:39

>>914
例えば、Ruby on Railsのアプリは config/database.yml などに環境依存の設定があるので、
公開されているrailsアプリがどう公開されているか参考になります。

実際の例では、プロジェクト管理ソフトのRedmineの場合↓
Redmine - /trunk/config - Redmine
http://www.redmine.org/projects/redmine/repository/browse/trunk/config

database.yml.example、 email.yml.example みたいにして、
database.yml、email.ymlそのものはリポジトリに入れてないですね。

0918デフォルトの名無しさん

2009/05/06(水) 14:25:36

>>916
rubyのスクリプトならpitじゃない?
http://lowreal.rubyforge.org/pit/

0919デフォルトの名無しさん

2009/05/06(水) 15:04:52

>>918
あ、いや、取得した後どうするものか？と思いまして…バージョン管理ソフトとの兼ね合いについて…
pitだと~/.pit以下に保存するみたいですね。アカウント情報ならこういう実装でもいいと思います
http://coderepos.org/share/browser/lang/ruby/pit/trunk/lib/pit.rb

Rubyだと、highlineというのもあるみたいですが、こちらは保存機能はなし？
パスワードの入力を受け付けるプログラムを作る - うなの日記
http://d.hatena.ne.jp/unageanu/20090226/1235653192

上記サイトの方が作っておられるjijiというRubyプログラムでは、
highlineでプロンプトで聞いたあと ~/.jiji/conf/configuration.yaml に手動で保存しているみたいでした。
http://github.com/unageanu/jiji/blob/32faf624610a22b11316b4f24344e08717683410/lib/jiji/command.rb

参考になりました。ありがとうございます。

0920デフォルトの名無しさん

2009/05/06(水) 18:06:47

highlineはコマンドラインで便利に使える入力インターフェイスであって、
設定を扱うとかいうのとは軸が違う。

0921デフォルトの名無しさん

2009/05/09(土) 11:00:35

tortoisesvnをWindows7RC1 x64にインストールしたんだけど
シェルにメニューが出てこない・・・
これは諦めろってこと？

0922デフォルトの名無しさん

2009/05/09(土) 11:11:55

>>921
ちゃんとTortoiseSVNも64bit版で?

0923デフォルトの名無しさん

2009/05/09(土) 12:06:21

hg-fixutf8 という、Windows上でもリポジトリにutf-8でファイル名を
突っ込むhg拡張、今までSetOutputCP(65001)に依存していたから
挙動不審だったりしたんだけど、現在のコードページで表示可能なら
現在のコードページを利用するようになった。
これで大抵の日本語ファイル名はutf-8で扱えるようになったはず。

0924デフォルトの名無しさん

2009/05/09(土) 14:07:26

>>923
あれ、ちゅーことはTortoiseHgで日本語ファイル名つかっちゃまずかったのか？
BitBucket.orgにつっこんだら、サーバーエラーでてたけどこれが原因か？

0925デフォルトの名無しさん

2009/05/09(土) 14:11:35

>>924
前に試しにWindowsのTortoiseHgからつっこんだ日本語ファイル名のリポジトリなんだが、
今BitBucket.org上でみてみたら、化け化けになってたわ。前は見れてたけど。
該当ファイルのソース見ようとしたら、サーバーエラーは起きず、ちゃんと(？)404NotFoundになるようになってる

0926デフォルトの名無しさん

2009/05/09(土) 14:43:10

>>923
これだよね
FixUtf8Extension - Mercurial
http://www.selenic.com/mercurial/wiki/index.cgi/FixUtf8Extension

拡張導入して、
前のリポジトリを移行しようとしているんだが、上手くいかない…

>hg addremove -s 100

C:\Program Files\TortoiseHg\library.zip\mercurial\util.py:1043: UnicodeWarning:
Unicode equal comparison failed to convert both arguments to Unicode - interpret
ing them as being unequal
abort: [win32mbcs] filename conversion fail with cp932 encoding

とか言われる

0927926

2009/05/09(土) 14:53:51

>>926 ですが、TortoiseHg 0.7.5のhgだとwin32mbcsを[extensions]に書いておくと、エラーがでるみたいです。
はずしたら、移行できました。ちょっと変ですが…

0928デフォルトの名無しさん

2009/05/09(土) 15:18:19

>>927
以前からエラー吐いてたな。
どっちも文字コード関係だからバッティングすんじゃね？

0929デフォルトの名無しさん

2009/05/09(土) 17:51:52

もともとWindowsのファイル名はユニコードだからこのやり方が自然だよね。
標準になって欲しい。

0930デフォルトの名無しさん

2009/05/09(土) 18:56:55

>>926
お前アホだろwww

0931デフォルトの名無しさん

2009/05/09(土) 19:19:02

>>929
残念ながら、svnとbzrはその「自然な」方針だからファイル名エンコーディングが
違う環境でリポジトリを共有できるけど、hgとgitは「ファイル名はバイナリ列」という
ポリシーだからダメなんだよね。
Linux以外シラネのgitは3rd partyが何とかしないといけないの判るけど、
hgはクロスプラットフォームをうたってるんだから正規化されたutf-8で
リポジトリに格納するオプションが公式で欲しいわ。
hg-fixutf8もけっこう強引な方法使ってるから、なんかのコマンドで問題起きたり
別の拡張とバッティングしたりし易い。

0932デフォルトの名無しさん

2009/05/09(土) 19:54:43

>>930
せめて理由を言えよ。ただ、人を罵倒するのは罵倒されても文句言えないぞ

0933デフォルトの名無しさん

2009/05/09(土) 23:29:47

darcsはファイルのパーミッションを覚えてくれないのか・・・
hgはできる？

0934デフォルトの名無しさん

2009/05/10(日) 05:25:51

>>932
馬鹿

0935デフォルトの名無しさん

2009/05/10(日) 08:00:54

>>933
execute以外のパーミッションを言っているなら、
hgもsvnもできない。おそらくgit,bzrも。
executeはどれもok

0936デフォルトの名無しさん

2009/05/10(日) 08:58:18

>>932
煽りは華麗にignoreするべし

0937デフォルトの名無しさん

2009/05/10(日) 14:57:27

>>935
残念
/etc
の管理したかったのに・・・

0938デフォルトの名無しさん

2009/05/10(日) 14:58:41

>>937
つetckeeper

0939デフォルトの名無しさん

2009/05/10(日) 20:50:17

Windowsではexecuteの扱いはどうなるの？
無視されるのですか？

0940デフォルトの名無しさん

2009/05/11(月) 08:26:25

>>939
NTFSには実行属性あるじゃない。反映されるかは知らないけど

0941デフォルトの名無しさん

2009/05/11(月) 12:27:08

>>939
どうなるのとは？何の話かな？
権限の話(プロパティのセキュリティタブとかの)なら、無視されるはずですよ

0942デフォルトの名無しさん

2009/05/19(火) 17:05:17

Mercurial で、一連のコミットをそれぞれ別のパッチとして取り出すにはどうしたらいいですか。
基本的な質問で済みません。

0943デフォルトの名無しさん

2009/05/19(火) 17:24:38

>>942
hg log -p した結果をスクリプトで切り分けることにしました。
問題はいちおう解決しましたが、後学のためにもっとうまい方法があれば教えてください。

0944デフォルトの名無しさん

2009/05/19(火) 17:31:12

>>943
hg export 1:tip　とかは？

0945デフォルトの名無しさん

2009/05/19(火) 17:39:40

ブランチの一部のみから新たなブランチとして取り出すことってgit, bzr, hgどれでもできる？
Eclipseのためにソースコードのフォルダのみでブランチを切りたいんだけど、
これができなさそうで移行に踏み切れない・・・。

0946デフォルトの名無しさん

2009/05/19(火) 18:30:03

>>945
bzr なら bzr split + bzr join --reference と言いたいところなんだけど、
まだ bzr join --reference が未完成だから bzr join しかできない。

0947945

2009/05/20(水) 09:03:42

>>946
そっか、サンクス。
linuxならシンボリックリンク使う手があるんだけど、会社ではwindowsで開発してるんだよなあ。
windowsにもリンクのシステムがあるらしいから、調べてみるわ。

0948デフォルトの名無しさん

2009/05/20(水) 09:17:39

NTFSのリンクはエクスプローラが理解できないし、エクスプローラのリンクはエクスプローラ以外が理解できない罠。

0949デフォルトの名無しさん

2009/05/20(水) 09:21:18

VistaのXPに対する唯一の利点なんだよね＞シンボリックリンク

0950945

2009/05/20(水) 09:27:14

http://www.interq.or.jp/japan/s-imai/tcltk/symlink.html
ここに書かれてるようなシンボリックリンクなんだけど、無理？

0951デフォルトの名無しさん

2009/05/20(水) 09:47:00

>>950
そこに書いてあるように、エクスプローラで見分けがつかないから危なくてしょうがない。

0952デフォルトの名無しさん

2009/05/20(水) 11:28:28

>>950
そのサイト、記述がおかしい…。
Vista以前はWindowsではシンボリックリンクはないです。(cygwinは除く)
Vista以前はジャンクションとハードリンク。
そのサイトのシンボリックリンクは多分、XPなどのジャンクションで、これはディレクトリにしか貼れないもの。

Vistaはようやくシンボリックリンクが使えるようになった。
Vistaのはサイトの記述と違ってちゃんとファイル単体にも貼れる

>>951
Vistaだとエクスプローラーにもシンボリックリンクはちゃんとショートカットみたいなアイコンがつきますよ。
XPだとないですかね？
コマンドプロンプトでdirすればXPでもわかることはわかるけど。

0953945

2009/05/20(水) 11:40:11

ビスタか・・・。ビスタは俺の会社ではなかった事になってるんだが、どうしたものか。
PCのスペックも不安だしなあ。

0954デフォルトの名無しさん

2009/05/20(水) 14:00:02

Vista「以前」ってことはVistaにもシンボリックリンクはないことになるんだが。

0955デフォルトの名無しさん

2009/05/20(水) 14:25:38

>>954
まあ日本語では以上・以下、以前・以後がその値自体を含むかあいまいだからなあ。
未満、という単語に至っては以上と対応する言葉がない始末だし。
プログラマとしては突っ込みたくなる気持ちもわかるが、揚げ足とるのはやめようや。

0956デフォルトの名無しさん

2009/05/20(水) 14:31:52

Vista以前といったら、普通はVistaは含まれないよ

0957デフォルトの名無しさん

2009/05/20(水) 15:03:07

以上、以下、未満の違いは算数で習ったと思うんだが
最近はあいまいなの？

0958デフォルトの名無しさん

2009/05/20(水) 15:07:29

ついでに言えば、「～未満」に対応するのは「～を超える」だな。

0959デフォルトの名無しさん

2009/05/20(水) 15:13:31

>>957
文系のアホどもはそんな区別まったくしないがな。

>>958
初めて聞いたが、本当にそんな言葉使ってる人間いるのか？
大学まで数学習ったが一度も使ったことないぞ。

0960デフォルトの名無しさん

2009/05/20(水) 15:17:45

調べてみたら正しいみたいだ。
おかしいな、学生時代には以上、以下、未満しか習わなかったはずなんだが・・・。

0961デフォルトの名無しさん

2009/05/20(水) 15:23:14

有史以前
という言葉に有史時代は含まれるか否か

0962デフォルトの名無しさん

2009/05/20(水) 15:53:39

以前は基点を含む
前は基点を含まない

文型に混乱させられてんじゃねーよ。

0963デフォルトの名無しさん

2009/05/20(水) 16:20:18

>>960
算数ではやってないかもしれんけどまあそういう表現だよって程度

そういや最近30こえた人に以上、以下、未満の違いを図解で説明したわ
数十分にわたってな
エクセルって算数がわからないと難しいんだな・・・

0964デフォルトの名無しさん

2009/05/20(水) 16:30:25

そろそろバージョン管理とは関係がないことに気がつこうぜ。
以上、以下、未満と、以前・以後は別の話だからじっくりしたければViPでもいってきいてみな

0965デフォルトの名無しさん

2009/05/20(水) 21:21:24

（9）以前・以後・以降・前・後・以内・内・間
http://www.ek.tohmatsu.co.jp/word/c-word/01-10/09.shtml
「以下」⇔「以上」。では「未満」⇔？
http://science6.2ch.net/test/read.cgi/math/1078386274/

0966デフォルトの名無しさん

2009/05/21(木) 00:26:46

俺は「～未満」vs「～超」だと思ってた。

0967デフォルトの名無しさん

2009/05/21(木) 01:02:55

1時間強は1時間を越え、2時間のほうに近い。
1時間弱は1時間を越え、1時間のほうに近い。
と理解している後輩に遭遇した。

0968デフォルトの名無しさん

2009/05/21(木) 01:05:42

そういう誤解をしている人は存外いると思う。

0969デフォルトの名無しさん

2009/05/21(木) 10:44:35

>>956
含むだろ jk。
含まない言い方は「Vista より前」。

0970デフォルトの名無しさん

2009/05/21(木) 11:39:45

>>969
じゃ有史以前は現在も含むんだな

0971デフォルトの名無しさん

2009/05/21(木) 11:45:10

>>968
いるかアホ

0972デフォルトの名無しさん

2009/05/21(木) 11:51:50

>>971
そう熱くなるなよ。それに二度目だがスレ違いだしな。

んで結局>>945はGitやMercurialではできるの？
Gitはできると読んだことがある気はするけど、方法は知らない。

0973デフォルトの名無しさん

2009/05/21(木) 12:27:31

>>970
有史前つー言葉を知らないアホ？

0974デフォルトの名無しさん

2009/05/21(木) 12:37:56

>>973
邪魔

0975デフォルトの名無しさん

2009/05/21(木) 12:53:01

WindowsのTortoiseSVNで、LFの改行コードのテキストファイルを
チェックアウトすると、CRLFになっちゃってるんだけど、
TortoiseSVNが勝手に変換してるのかな。
どこで設定すれば、変換を止めてくれるんだろう？

0976デフォルトの名無しさん

2009/05/21(木) 12:54:17

svn:eol-style

0977デフォルトの名無しさん

2009/05/21(木) 12:59:18

>>976
あーわっかりました。
リポジトリのファイルの方で、svn:eol-style=native がセットされていたんですね。

0978デフォルトの名無しさん

2009/05/21(木) 14:09:39

>>973
有史以前は現在も含むかどうか答えろカス

0979デフォルトの名無しさん

2009/05/21(木) 14:22:48

>>978
有史以前は普通、現在は含まないのに、以前って言い方するよね。おかしいね。
これで満足か？

0980952

2009/05/21(木) 14:29:00

何で俺のレスでこんなにあれてんだよｗ

0981デフォルトの名無しさん

2009/05/21(木) 14:31:35

>>979
頭おかしいのか？

0982デフォルトの名無しさん

2009/05/21(木) 14:33:51

○○以前という表現で、○○を含む場合も含まない場合もあるんだから、文脈で判断しろよ。
判断できない場合は、言った奴に聞けばよろしい。
自分では書かないこと。

以上。

0983デフォルトの名無しさん

2009/05/21(木) 16:43:43

日本語って曖昧だよね～

0984デフォルトの名無しさん

2009/05/21(木) 17:01:34

あいまいみーまいん

0985デフォルトの名無しさん

2009/05/21(木) 17:40:49

>>984
ひとりでできるもんとか懐かしすぎる

0986デフォルトの名無しさん

2009/05/21(木) 20:22:52

<>
!=

使い分けに悩むの

0987デフォルトの名無しさん

2009/05/21(木) 21:12:52

>>986
Pythonだと意味が同じ。D言語だと意味が違う。

0988デフォルトの名無しさん

2009/05/21(木) 21:36:02

Pythonだと<>演算子は廃止されました(3.0以降)

0989デフォルトの名無しさん

2009/05/21(木) 22:12:03

>>945
Mercurialの場合、取り出すだけならhg convert --filemap=... でいける。
ただ、それだと変換後→変換前という風にソースを反映させたい時が面倒。
最初からそのつもりで構築しなきゃいけないけど、こんな方法もある。
ttp://www.selenic.com/mercurial/wiki/NestedRepositories
ttp://www.selenic.com/mercurial/wiki/ForestExtension

0990デフォルトの名無しさん

2009/05/22(金) 00:04:30

次スレ

バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/

0991デフォルトの名無しさん

2009/05/22(金) 00:23:25

>>967
震度かよ

0992デフォルトの名無しさん

2009/05/23(土) 00:02:01

うめ

0993デフォルトの名無しさん

2009/05/23(土) 00:04:15

埋め

0994デフォルトの名無しさん

2009/05/23(土) 00:06:32

うｍ

0995デフォルトの名無しさん

2009/05/23(土) 00:35:14

残り少ないのに何なんだが、おうぇｄｒｆｔｇｙふｊみお

0996デフォルトの名無しさん

2009/05/23(土) 00:40:19

うめ

0997デフォルトの名無しさん

2009/05/23(土) 00:41:10

うめ

0998デフォルトの名無しさん

2009/05/23(土) 00:42:39

次スレ

バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/

0999デフォルトの名無しさん

2009/05/23(土) 00:49:01

TortoiseSVNもCVSも入れてるがﾀﾞｳｿﾛｰﾀﾞ代わりにしか使ってないのは内緒だ

1000デフォルトの名無しさん

2009/05/23(土) 00:50:06

1000なら次は1001！

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。