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

>>40
master repository的な意味合いで行くとcvsからsvnに移行してる。
p4のrepositoryがmaster repositoryだったことはない。
好き勝手に開発したいけどcvsのbranch使いにくいってことでp4使い始めた人達がいたけど、
svnに移行した以上p4使い続ける意味はないはず。

47 ：デフォルトの名無しさん：2009/10/14(水) 10:08:26

単に「使ってる」って意味合いだけで挙げたんだが……まあいいか。

48 ：デフォルトの名無しさん：2009/10/14(水) 10:14:19

ああ、いいならいいや。
master repositoryがp4だった時期はないってことをはっきりさせときたかったんでね。

49 ：デフォルトの名無しさん：2009/10/14(水) 13:31:32

GitのC#実装「GitSharp」、バージョン0.1.3リリース
ttp://sourceforge.jp/magazine/09/10/14/0313228

50 ：デフォルトの名無しさん：2009/10/15(木) 10:48:44

>>49
C#でgit？はぁ誰得だよ、と思ってたら、
Windows用gitの救世主となるのかな。これは期待。

51 ：デフォルトの名無しさん：2009/10/16(金) 12:49:48

記事見るまで知らなかったけど java 実装の git なんてのもあるのか。
たしか ruby 実装のもあるって話が前スレであったと思うし、なんか色々乱立してかえってややこしいことになりそうだなぁ

52 ：デフォルトの名無しさん：2009/10/16(金) 14:01:54

前スレに出てたのはgitのpython実装であるdulwichのことでしょ。bzr-gitに使われてるやつ。

53 ：デフォルトの名無しさん：2009/10/16(金) 14:49:21

OpenOffice.org、ソースコード管理ツールを「Mercurial」に移行へ
http://sourceforge.jp/magazine/09/10/16/033250

54 ：デフォルトの名無しさん：2009/10/16(金) 16:38:29

>>53
これでまた暴動でも起こるんですかねwww

55 ：デフォルトの名無しさん：2009/10/16(金) 17:31:40

なんで？

56 ：デフォルトの名無しさん：2009/10/16(金) 17:56:58

うーんやっぱりMercurialが今後主流になるのですかねえ…
どれが主流になるか判らなかったんでずっと様子見してたけど
そろそろ使い方を勉強しても、無駄にはならないか…

57 ：デフォルトの名無しさん：2009/10/16(金) 17:58:31

OOoってCVSだったのか…未だにCVSのとこってけっこうあるんだねぇ

58 ：デフォルトの名無しさん：2009/10/16(金) 18:22:30

この一見だけで Mercurial って思えるのが不思議。
乗り換え先が git のほうがプロジェクト的に多いだろ。

59 ：デフォルトの名無しさん：2009/10/16(金) 18:38:04

SunがMercurial好きってだけじゃね？

60 ：デフォルトの名無しさん：2009/10/16(金) 18:41:34

>>59が正解。
でも太陽に陰りが見えるから、メルクリウス神がろくでなしになるのも時間の問題。

61 ：デフォルトの名無しさん：2009/10/16(金) 19:56:07

>>60
あはは。そんな馬鹿な

と言い切れないのが怖いです…
Sunって桃鉄で言うところの

62 ：デフォルトの名無しさん：2009/10/16(金) 22:10:16

ここまで来てGitとhgのどちらかが潰れるとは思えないがねぇ
そう思える人はよほど相手を潰したい人なんでしょ

63 ：デフォルトの名無しさん：2009/10/16(金) 22:21:35

誰もそんなこと言ってないが。
>>60はSunがOracleに買われて、hgからgitびいきに変わるだろうって予言しょ。

64 ：デフォルトの名無しさん：2009/10/16(金) 22:25:41

太陽に陰り→日蝕→Eclipse→IBM→Clear Case
やっぱりIBMに買われてた方が自然だったな>Sun

65 ：デフォルトの名無しさん：2009/10/16(金) 22:56:59

でも、IBM Rational ClearCaseになるのは勘弁

66 ：デフォルトの名無しさん：2009/10/16(金) 23:13:23

もう飽きたし面倒くさいからSubversionとRCSでいいや(´・ω・｀)

67 ：デフォルトの名無しさん：2009/10/16(金) 23:52:04

bzrにしようと思ってたんだが、人気ねー

68 ：デフォルトの名無しさん：2009/10/17(土) 00:38:42

TortoiseRCSがあったらいいというのに(´・ω・｀)

69 ：デフォルトの名無しさん：2009/10/17(土) 10:22:47

ローカルでしかバージョン管理しなくても、今や分散型を（限定的に）使えばいい時代だから、RCSがこれから顧みられることはないだろうなぁ

70 ：デフォルトの名無しさん：2009/10/17(土) 11:58:09

gentooだと/etc以下、設定ファイルなんかの世代管理ツールのバックエンドにRCS使ってたと思う。

71 ：デフォルトの名無しさん：2009/10/17(土) 14:14:38

みなさんに質問なのですが、
あるディレクトリ以下のバージョン管理を始めたあとに、
その親ディレクトリもバージョン管理しないといけなくなった場合、
どのようにしますか？

たとえば
$HOME/src/hogehoge.c を src を基点にバージョン管理を始めたあとに
$HOME/.bashrc のバージョン管理をしたくなったらどうしますか？

72 ：デフォルトの名無しさん：2009/10/17(土) 14:22:00

>>71
./hogehoge.cを./src/hogehoge.cに移動

73 ：デフォルトの名無しさん：2009/10/17(土) 14:22:04

できるだけ最初からディレクトリ構成を練っておく。
もしそうなった場合は移動するだけ。
CVSでもなければ移動は簡単でしょ。

74 ：デフォルトの名無しさん：2009/10/17(土) 14:49:34

>>71
みたいな例は.bashrcがそもそも移動できない例だけど、
逆にそういう実際の例が思いつかないな…。
unixやVista以降なら、ファイル単体のシンボリックリンク張ればいいのかね。

75 ：デフォルトの名無しさん：2009/10/17(土) 19:50:08

>>74
俺様は~/configの下に設定ファイルを集約してシンボリックリンクにしてる。
eg ln -s config/emacs .emacs

76 ：デフォルトの名無しさん：2009/10/17(土) 19:52:27

>>70
ファイル単位の履歴で十分な用途だとRCSでもいいかもね。
RCSだと余計なライブラリとか言語処理系は不要だし
いざというときのサルベージでは安心できる。

77 ：デフォルトの名無しさん：2009/10/18(日) 11:35:08

クリアケースの話題が定期的にあがるのでWikipedia貼っておく。

・Rational ClearCase
http://ja.wikipedia.org/wiki/Rational_ClearCase

＞欠点 [編集]
＞トランザクションがアトミックでない。
＞コードベースが古く、新規機能追加が遅い。
＞非常に複雑で、構成設定に注意を要する。
＞遅い。単純なコミットやチェックアウトが数分かかることも稀ではない。

個人的に、開発で使うには非常に致命的だと思うが。

78 ：デフォルトの名無しさん：2009/10/18(日) 13:20:01

RCSとか言ってるやつはネタだろ。
そんなマジレスしなくても

79 ：デフォルトの名無しさん：2009/10/18(日) 19:01:11

bzr-git用に開発されたPythonのgitライブラリdulwichを使った、
hg-gitの初期バージョンがリリースされた。
http://hg-git.github.com/

80 ：デフォルトの名無しさん：2009/10/19(月) 14:44:24

>>77
いやだからクリアケース使ってる人の大半は
そんな欠点は百も承知の上で IBM がらみで仕方なく使ってるんだってば

81 ：デフォルトの名無しさん：2009/10/19(月) 15:14:48

いいこと思いついた。
ClearCaseは使うふりにとどめて、実際の作業では別のVCS使えばいいんじゃね？
IBMが「ClearCaseを全ての場面で実際に動かしているか」なんて逐一チェックしているなら無意味だが。
(スパイウェアでも仕込まない限りは…ね)

82 ：デフォルトの名無しさん：2009/10/19(月) 20:31:05

Wikipediaの記事見たけど、これが1990年代に開発されたことを考えればすごく野心的だな。
「svn? git? それは我々が20年前に通過した場所だ！」とか何かのインタビューで豪語していた
のも分からんでもない。

最大の問題は、理論だけが先行しちゃった上にコードが古すぎるって事ではあるんだろうな。

83 ：デフォルトの名無しさん：2009/10/19(月) 22:09:49

で?

84 ：デフォルトの名無しさん：2009/10/20(火) 11:12:58

っていう

85 ：デフォルトの名無しさん：2009/10/20(火) 11:13:40

理論だけで役にはたたない。
それ何てタネンバウム？

86 ：デフォルトの名無しさん：2009/10/20(火) 12:04:05

astはちゃんと実装までやったし、その実装も教育用のものとしては依然として
使いものになるからその批判はまとまずれ。

87 ：デフォルトの名無しさん：2009/10/20(火) 12:11:04

ClearCaseと同じじゃん

88 ：デフォルトの名無しさん：2009/10/20(火) 12:12:20

実用 git, linux
--------- 越えられない壁 ----------
教育用 ClearCase, タネンバウム

89 ：デフォルトの名無しさん：2009/10/20(火) 12:14:16

犬のコードなんか教育用に使えたもんじゃないしな.

90 ：デフォルトの名無しさん：2009/10/20(火) 12:33:02

BSDは教科書どおりに無駄なフィールドあるしな。
プロセス構造体とかw
教科書とおりって意味では教育的だがw

91 ：デフォルトの名無しさん：2009/10/20(火) 13:55:13

task_structとか、mm_structとか、_struct付けるのはあたまわるいとしかおもえないんですが.

92 ：デフォルトの名無しさん：2009/10/20(火) 15:06:49

さあ、盛り上がってまいりました。

93 ：デフォルトの名無しさん：2009/10/20(火) 18:18:06

linuxは、頭が悪いやつがつくっても
目玉の数が多ければ大丈夫という開発モデルだからね。

94 ：デフォルトの名無しさん：2009/10/20(火) 18:33:47

BSDは頭のいいやつが考えるんだが、時間が掛るし頑固者が多いので
なかなか進まないという

95 ：デフォルトの名無しさん：2009/10/20(火) 19:20:22

http://www.microsoft.com/japan/msdn/vstudio/campaign/vsstotfs/
触った事がないんだけどコレって使いやすい？
てか、MSの中の人使ってんのかな。

96 ：デフォルトの名無しさん：2009/10/20(火) 23:00:30

ひとり７万ってなめてんの？

97 ：デフォルトの名無しさん：2009/10/20(火) 23:10:57

VSSからどの程度改善されてるんかね。
というか、どこの製品を買収したんだ。

98 ：デフォルトの名無しさん：2009/10/20(火) 23:16:35

　　　　　　　　ヤタ！朕が９８げっとだ！！お前等朕にひれ伏せ！クソ共が！
　　　　　　　￣￣￣￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　 /＼／＼　　／神＼/../
　　　　　　　 /　／＼　＼（´∀｀　）./
　　　　　　　（）)ノ__　○二○二⌒/../
　　　　　　／／||(二ニ) （＿＿_/../　几l
　　　γ ⌒ ／|Ⅲ||彡Ｖミ/⌒＿ノ二二ノl0
　　　l|　(◎).|l　|((||（(ﾟ )/⌒/||三三三・） ||　　(´⌒(´
＿＿ゝ_＿ノ　　　￣（_＿_）￣　　ゝ＿_ノ≡≡≡(´⌒;;;≡≡≡
　　　　　　　￣￣￣￣￣￣￣￣￣￣￣(´⌒(´⌒;;
朕は神なり！朕は神なり！朕は神なり！朕は神なり！朕は神なり！朕は神なり！朕は神なり！
朕　IS　GOD！朕　IS　GOD！朕　IS　GOD！朕　IS　GOD！朕　IS　GOD！

99 ：デフォルトの名無しさん：2009/10/21(水) 01:06:21

Windowsで立ち上げてるsvnservにMax OS Xからアクセスするときに、
ホスト名ってどうやって指定したらよいんでしょう・・・。

100 ：デフォルトの名無しさん：2009/10/21(水) 01:13:08

IPアドレスかNetBIOS名でいいんじゃないの

101 ：デフォルトの名無しさん：2009/10/22(木) 18:56:59

>>99
ネットワーク管理人に聞け。

102 ：デフォルトの名無しさん：2009/10/25(日) 01:30:46

現在研究室ではTortoiseSVNをローカルのリポジトリのみで使用しています。
作業コピー（orコピー）をUSBメモリに入れて自宅でもコーディングをしたいのですが
自宅PCなのでTortoiseSVNみたいにシェル統合されたくありません。
TortoiseSVNみたいにSubversion無しで（TortoiseSVN単体で）使用できるようなシステムは無いでしょうか。
欲を言えばUSBメモリでリポジトリ＋システム全部が持ち運びできるようなものがいいです。

103 ：デフォルトの名無しさん：2009/10/25(日) 02:36:11

>>102
> 自宅PCなのでTortoiseSVNみたいにシェル統合されたくありません。
> TortoiseSVNみたいにSubversion無しで（TortoiseSVN単体で）使用できるようなシステムは無いでしょうか。
Subversion無しでどうやってTortoiseSVNを使うんだよ・・・。
クライアントだけあってもしょうがないだろうに。

104 ：デフォルトの名無しさん：2009/10/25(日) 03:55:36

>>103
TortoiseSVNはスタンドアロンでリポジトリの作成～インポート～チェックアウト～Diff～コミットなどなどできるんよ

105 ：デフォルトの名無しさん：2009/10/25(日) 04:24:31

>>103
すげぇ～、実はTortoiseSVNの事、これっぽっちも知らなかったのに
この上から目線の「俺は何でも知ってるんだよ！カス！」口調。

さすが2chだ、何ともないぜ。

106 ：デフォルトの名無しさん：2009/10/25(日) 07:55:23

>>102
シェル統合が嫌なのはわかったが、CUIがいいのか、WinCvsみたいなスタンドアロンのGUIがいいのか。

107 ：102：2009/10/25(日) 10:15:50

TortoiseSVNみたいにGUIで出来たほうがいいです。

108 ：デフォルトの名無しさん：2009/10/25(日) 10:23:53

RApidSVNとかなんとかいうのあるはずだろ。
というかなんでぐぐらんの？

109 ：デフォルトの名無しさん：2009/10/25(日) 10:47:43

ググるのくらいお前らがやってくれよ

110 ：デフォルトの名無しさん：2009/10/25(日) 13:04:07

そもそもググる必要なくね？
subversionのウェブサイトへ行けば、殆ど必要な物すべてにリンクが通じてるぞ。

111 ：デフォルトの名無しさん：2009/10/25(日) 13:31:34

git svnがお勧め
GUIなし、svnが陳腐に見えて使えなくなること請け合いだが

112 ：デフォルトの名無しさん：2009/10/25(日) 14:24:11

ClearCaseは糞

113 ：デフォルトの名無しさん：2009/10/25(日) 14:28:40

>>102
svnやめてgitにしたらいいよ
hgでもいいけど

114 ：102：2009/10/25(日) 14:31:30

>>108
RapidSVNはGUIフロントエンドで結局Subversionも入れないとダメみたいな記事を見かけたもので、
一応ググったんですけど、TortoiseSVNみたいに単体で使えるものが見つからなかったのでここで聞いてみました。

>>110
subversion無しで使えるものが欲しいのです。

>>111-112
ありがとうございます。調べてみます。

115 ：デフォルトの名無しさん：2009/10/25(日) 14:40:10

>>114
君の使い方ならsubversionじゃない方がいいんじゃないか？
中央集権型のリポジトリと相性が悪そう。
分散リポジトリを検討するが吉

116 ：デフォルトの名無しさん：2009/10/25(日) 14:42:18

subversion不要ってのが意味不明だなw
リポジトリ自体が不要？
I/Fだけあってもしかたないのに

何の恩恵を受けてるか自覚が出るまで放置だな

117 ：デフォルトの名無しさん：2009/10/25(日) 14:51:57

TortoiseSVNのシェル拡張じゃないやつが欲しいんだろ
何でそんなつまらんことにこだわってんのかわからんけどさ

118 ：デフォルトの名無しさん：2009/10/25(日) 14:56:37

ようするにインストールの仕方がわかんないんだろJK

119 ：デフォルトの名無しさん：2009/10/25(日) 16:16:24

TortoiseSVNにもsubversionはいってるはずだがｗ

120 ：デフォルトの名無しさん：2009/10/25(日) 16:26:50

ようするにCUIは使えないってことか
分散は100年早いよw

121 ：デフォルトの名無しさん：2009/10/25(日) 18:35:22

別にSubversion入れればいいじゃんって思うけど入れるのがダメな理由なんなわけ

122 ：デフォルトの名無しさん：2009/10/25(日) 18:51:36

Rational ClearCase なんて使うならCVSの方がよっぽどまし。
つーか、Subversion使えよ。おすすめ。

ClearCaseなんぞIBM工作員しかマンセーしないから。

123 ：デフォルトの名無しさん：2009/10/25(日) 18:53:59

tortoiseSVNをインストールせずに、リポジトリの入ったUSBをさしたところで使いたいってことだと思う。確かに、制限ユーザーだとインストールできないし。

subversionのコマンドライン版を使う。
GUIが欲しいなら、Python版のGUIクライアントがあったと思うけど。

124 ：デフォルトの名無しさん：2009/10/25(日) 18:54:32

バージョン管理システム略してバーカン

125 ：デフォルトの名無しさん：2009/10/25(日) 18:55:54

バカシス

126 ：デフォルトの名無しさん：2009/10/25(日) 19:11:27

>>123
そんな時はsvnじゃなくてgitか水銀だろJK
リポジトリもワークも同じだからUSBで無問題。
しかし、GUIが欲しいＪＫには使いこなすのはムリポ

127 ：デフォルトの名無しさん：2009/10/25(日) 19:26:02

bzrはポータブル版（nonadmin?)があったような、、
bzr-svnでいけんじゃね？

128 ：デフォルトの名無しさん：2009/10/25(日) 19:28:31

話の限りではsvnじゃなくてbzrがベストなんじゃね
確かスタンドアロンのGUIが標準添付だったはずだし

伝聞だけで使ったことが無いもんだから、お勧めできる立場には無いけど

129 ：デフォルトの名無しさん：2009/10/25(日) 19:29:19

その前に学校で開発してて、windows使ってるのがありえない

最近の情報学科もゆとりなわけ？

130 ：デフォルトの名無しさん：2009/10/25(日) 19:30:49

>>129
ヒント:JK

131 ：デフォルトの名無しさん：2009/10/25(日) 19:32:08

そういえば、M$のOS上にリポジトリ置いたことないから
お勧めできる立場にないや

132 ：デフォルトの名無しさん：2009/10/25(日) 19:33:49

>>129
熱くなる気持ちは分からんでもないが、WindowsにVisual Studioの組み合わせが主流の学校は別に珍しくないよ

133 ：デフォルトの名無しさん：2009/10/25(日) 19:34:20

なんか盛り上ってまいりました

134 ：デフォルトの名無しさん：2009/10/25(日) 19:36:30

>>132
Visual Studioもいいが、そこでSVN使うの？
SourceSafeとかあったような

135 ：デフォルトの名無しさん：2009/10/25(日) 19:42:07

>>134
お前もゆとりなわけ？

136 ：デフォルトの名無しさん：2009/10/25(日) 19:44:55

JKがいると雰囲気変るよね

明るくなるっていうのは、おバカで明るくなる

137 ：デフォルトの名無しさん：2009/10/25(日) 19:52:05

>>134
SourceSafeだけはありえない

138 ：デフォルトの名無しさん：2009/10/25(日) 19:52:52

>>135
俺は学生の時からlinuxばっかりだな

139 ：デフォルトの名無しさん：2009/10/25(日) 19:55:12

>>137
Windowsで開発がありえない

140 ：デフォルトの名無しさん：2009/10/25(日) 19:56:45

M$製品使うなら統一しなきゃ
バージョン管理だけsubversionってw

141 ：デフォルトの名無しさん：2009/10/25(日) 19:56:57

おまえらVSSの話はかまわんがVSとWindowsの話はスレ違いだ

142 ：デフォルトの名無しさん：2009/10/25(日) 19:59:39

わかりましたー先生

143 ：デフォルトの名無しさん：2009/10/25(日) 20:03:57

VSSとかMS自身からも見捨てられた骨董品じゃねえか
今さら進んで選択する人なんているの？

144 ：デフォルトの名無しさん：2009/10/25(日) 20:09:11

教育に使うならM$と心中したらいいのにな
せめてsubversionでなくM$社内で使ってるものにしたら？

145 ：デフォルトの名無しさん：2009/10/25(日) 20:15:12

何やら過激派が紛れ込んでいる様子

146 ：デフォルトの名無しさん：2009/10/25(日) 20:43:43

そいでJKはまだ帰ってこないのか

147 ：デフォルトの名無しさん：2009/10/25(日) 22:56:37

>>143
ちょっと上にレスしてるWindows(笑)って馬鹿にしてる無知な奴らだろうね。
VSにSVNアドオンとか普通にあるのにｗ

148 ：デフォルトの名無しさん：2009/10/25(日) 23:02:29

svnも時代遅れだよ
無知なやつら

149 ：デフォルトの名無しさん：2009/10/25(日) 23:04:34

VSにはVSSがお似合い。プップッ

150 ：デフォルトの名無しさん：2009/10/25(日) 23:08:54

しかし、お前ら馬鹿にされ過ぎだぜ。
言い返す技量もないと見える

151 ：デフォルトの名無しさん：2009/10/26(月) 02:51:26

>>148
え？そこ？さすが有能な方は理解しがたい所を指摘しますなぁ・・・

152 ：デフォルトの名無しさん：2009/10/26(月) 13:27:09

bzr には bzr-explorer というシェル拡張じゃないGUIがあるよ。
標準のインストーラーでは、デフォルトでbzr explorer がインストールされて、
TortoiseBZRはデフォルトではインストールされない。

153 ：デフォルトの名無しさん：2009/10/26(月) 13:56:24

>>151
おまえ分散使ったことないだろ

154 ：デフォルトの名無しさん：2009/10/26(月) 14:03:38

そういう話じゃないだろうｗ

155 ：デフォルトの名無しさん：2009/10/26(月) 15:34:54

svnが最高と思ってる奴らに何を言っても無駄なようだ

156 ：デフォルトの名無しさん：2009/10/26(月) 15:38:02

個人なら好きなの使えるけどな
実際は他の人が変えたら無い訳で

157 ：デフォルトの名無しさん：2009/10/26(月) 15:40:10

普段使ってるツールが対応してるとかアドインがあるかどうかでも変わってくるしな

158 ：デフォルトの名無しさん：2009/10/26(月) 15:47:08

それは分るな。
gitにしたいけど周りのこと考えて無難にsvnをベースのリポジトリにしてる
自分だけはgit-svnで快適に暮す

159 ：デフォルトの名無しさん：2009/10/26(月) 16:15:30

他が安定してればsvnじゃなくてもいいんだけどな

160 ：デフォルトの名無しさん：2009/10/26(月) 16:31:31

gitやHGの使い方覚えるくらいなら他の事勉強するって10人に8人は答える

161 ：デフォルトの名無しさん：2009/10/26(月) 16:39:58

そしてその半分以上は勉強以外にその時間を使う

162 ：デフォルトの名無しさん：2009/10/26(月) 16:40:46

で、結局CVSやSVNで我慢する

163 ：デフォルトの名無しさん：2009/10/26(月) 16:45:09

一方、gitを覚えた奴は賢いマージ、軽いブランチなどにより
生産性があがり、自由な時間が増える

164 ：デフォルトの名無しさん：2009/10/26(月) 16:46:28

その自由時間で他の事も勉強できる

165 ：デフォルトの名無しさん：2009/10/26(月) 16:46:36

生産性あげても他の人の遅れをフォローするハメにあって結局

166 ：デフォルトの名無しさん：2009/10/26(月) 16:47:53

gitのおかげでハゲが治りました

167 ：デフォルトの名無しさん：2009/10/26(月) 16:55:25

その時間があるからこんなスレでくだらないことも書きこめるわけだな

168 ：デフォルトの名無しさん：2009/10/26(月) 17:28:17

そう!gitサイコー

169 ：デフォルトの名無しさん：2009/10/26(月) 20:18:48

ワラタｗ
このスレエディタでコーディングしてる奴多そうだな

170 ：デフォルトの名無しさん：2009/10/26(月) 20:26:36

そしてvim vs emacsまでこなせるのかこのスレは。優秀だな。

171 ：デフォルトの名無しさん：2009/10/30(金) 09:51:27

git より hg の方が良さげだ。

172 ：デフォルトの名無しさん：2009/10/30(金) 10:05:32

今月号 Software Design が git 特集なんだね

173 ：デフォルトの名無しさん：2009/10/30(金) 10:44:13

Windowsでgit-svn使おうとして絶望した

174 ：デフォルトの名無しさん：2009/10/30(金) 13:26:55

ギットギットにしーてやんよ

175 ：デフォルトの名無しさん：2009/10/30(金) 17:26:40

なんでgitはメンテナが日本人なのにWindowsでの日本語ファイル名扱いがうんこなの？

Windowsがウンコとか言われると反撃できないのでそれはやめてね

176 ：デフォルトの名無しさん：2009/10/30(金) 17:30:04

gitはLinuxの開発のために作られたから、Posix API にベッタリ依存しているだけ。
unicode cygwin使え。

177 ：デフォルトの名無しさん：2009/10/30(金) 22:47:24

ファイル名のローカルなエンコーディングの話は丁度この辺で話題になっているような。
首尾よく行けば将来のリリースに反映されるかもしれんね。

http://www.spinics.net/lists/git/msg115769.html

178 ：デフォルトの名無しさん：2009/11/03(火) 17:50:05

結局、svnの次は、hg,git,bzr 三強時代ということ？

179 ：デフォルトの名無しさん：2009/11/03(火) 18:29:26

>>178
bzrはないwww
Ubuntuに関わると必須になるのはただの悪夢

180 ：デフォルトの名無しさん：2009/11/03(火) 19:05:00

世界的にみると今さらbzrは無いだろうとは俺も思うが、日本じゃこれからbzrが主流になる可能性はまだある

181 ：デフォルトの名無しさん：2009/11/03(火) 19:11:00

この三強のどれかが今更廃れるとも思えないがな

182 ：デフォルトの名無しさん：2009/11/03(火) 22:16:37

Windowsの本命はGitSharpかもしれない…

183 ：デフォルトの名無しさん：2009/11/03(火) 22:20:13

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　　　　　　　 |
　　　　＿＿＿＿.＿＿＿＿　　 |
　　　　　|　　　　 | 　　　　|　　 |　　RationalClearCaseを
　　　　　|　　　　 | ∧＿∧　|　　 | 　　窓から
　　　　　|　　　　 |（　´∀｀）つミ | 　　投げ捨てろ
　　　　　|　　　　 |/ ⊃　ﾉ　|　　 |
　　　　￣￣￣￣'￣￣￣￣　　 | 　　ミRationalClearCase

184 ：デフォルトの名無しさん：2009/11/04(水) 01:46:00

英語圏の(マルチバイト文字不要な)奴らが実質主導という悲しい現実。

185 ：デフォルトの名無しさん：2009/11/04(水) 04:26:45

マックで濁音や半濁音が入ると文字化けします。
なんとかならんのでしょうか？

186 ：デフォルトの名無しさん：2009/11/04(水) 10:00:49

>>185
ttp://d.hatena.ne.jp/fujisan3776/20081231/1230700127
ttp://blog.yakitara.com/2007/11/subversion-precomposed-utf-8-patch.html

187 ：デフォルトの名無しさん：2009/11/05(木) 18:10:05

>>184
gitのリーダは日本人だぜ

188 ：デフォルトの名無しさん：2009/11/05(木) 18:58:41

結局 git と hg と bzr はどれがいいんだよ

189 ：デフォルトの名無しさん：2009/11/05(木) 20:25:04

gitが一番つぶしが効くと思う
githubとかあるし。
rubyかlinuxを良く使うなら一択じゃないかな

190 ：デフォルトの名無しさん：2009/11/05(木) 20:34:08

hgが一番つぶしが効くと思う
bitbucketとかあるし。
PythonかJavaを良く使うなら一択じゃないかな

bzrが一番つぶしが効くと思う
Launchpadとかあるし。
MySQLかemacsを良く使うなら一択じゃないかな

191 ：デフォルトの名無しさん：2009/11/05(木) 20:42:10

結局 git と hg と bzr はどれがいいんだよ

192 ：デフォルトの名無しさん：2009/11/05(木) 20:47:15

>>189-190
言語処理系の名前が挙がってると強く見えるふしぎ

193 ：デフォルトの名無しさん：2009/11/05(木) 21:03:42

自分が関わっているか関わりたいプロジェクトで使ってるやつを
選べばいいだろ

194 ：デフォルトの名無しさん：2009/11/05(木) 21:06:06

bzr-svn が 1.0 になり、 bzr-git もだいぶ動くようになってきて、 bzr-hg も開発が活性化してきた。
どんなVCSを採用しているプロジェクトに参加するときでもクライアントはbzrだけで済むようになれば、
一番「つぶしがきく」のはbzrだな。

195 ：デフォルトの名無しさん：2009/11/05(木) 21:15:24

バザールでござーる♪

196 ：デフォルトの名無しさん：2009/11/05(木) 21:58:53

みなさん darcs はもう眼中になしですか？

197 ：デフォルトの名無しさん：2009/11/05(木) 22:32:44

はい。

198 ：デフォルトの名無しさん：2009/11/05(木) 22:45:55

あれコンパイルするの異様に難しいし

199 ：デフォルトの名無しさん：2009/11/05(木) 23:00:23

200 ：デフォルトの名無しさん：2009/11/05(木) 23:01:11

>>196
何であんなとろくさいのを使わんといけんの？

201 ：デフォルトの名無しさん：2009/11/05(木) 23:03:54

理論的に明らかにdarcsはとろくさいじゃん。

202 ：デフォルトの名無しさん：2009/11/05(木) 23:57:13

darcsが一番つぶしが効くと思う
Patch-tagとかあるし。
haskellかhaskellを良く使うなら一択じゃないかな

203 ：デフォルトの名無しさん：2009/11/06(金) 00:30:29

>>202
そんなことないよ。
hgとかgitとか最近は多いよ。

204 ：デフォルトの名無しさん：2009/11/06(金) 10:37:22

IBM Rational ClearCaseが一番潰し甲斐があると思う。
ClearQuestとかあるし。
IBMかその下請けの仕事なら一択じゃないかな。

205 ：デフォルトの名無しさん：2009/11/06(金) 13:47:50

hgがいいお。いいんだお!!!

206 ：デフォルトの名無しさん：2009/11/06(金) 14:53:49

「Subversion」がApacheプロジェクトに
ttp://sourceforge.jp/magazine/09/11/06/0511211

207 ：デフォルトの名無しさん：2009/11/06(金) 15:06:17

ApacheはGitだったっけ？

208 ：デフォルトの名無しさん：2009/11/06(金) 15:09:08

svnをgitで管理するんですね

209 ：デフォルトの名無しさん：2009/11/06(金) 15:54:04

>>207-208
SVNだよ
ttp://www.apache.org/dev/version-control.html

210 ：デフォルトの名無しさん：2009/11/06(金) 19:18:30

ローカルでロールバック目当てに作業するならhgなんだけど、
会社で使うとなるとフォルダ移動が出来るsvnだな。

分散リポジかつフォルダ履歴管理が可能な国際化対応ツールがあればいうことなし。

211 ：デフォルトの名無しさん：2009/11/06(金) 19:34:56

>>210
分散かつフォルダを管理してUnicodeファイル名に対応したbzrをどうぞ

212 ：デフォルトの名無しさん：2009/11/06(金) 20:40:31

gitもあるじょ

213 ：デフォルトの名無しさん：2009/11/06(金) 23:00:51

>>211
分散でもなく集中でもなく意味不明なbzrはパス

214 ：デフォルトの名無しさん：2009/11/07(土) 00:43:57

いや、普通に分散だと思うが。

215 ：デフォルトの名無しさん：2009/11/07(土) 02:09:59

>>214
リポジトリをコピーするコマンドもないのに分散と言えるのか？

216 ：デフォルトの名無しさん：2009/11/07(土) 10:51:04

多少遅くてもいいんで、Javaポートしてくれと思ったり。

217 ：デフォルトの名無しさん：2009/11/07(土) 10:53:46

レポジトリをコピーする必要があるのか？

218 ：デフォルトの名無しさん：2009/11/07(土) 11:05:43

>>212
gitはフォルダを管理しないしUnicodeファイル名対応もまだだろ。

219 ：デフォルトの名無しさん：2009/11/07(土) 11:06:46

>>216
bzrはJythonで動かした報告があった。
今の bzr-eclipse とかは、外部プロセスとしてbzrを起動してるけど、
将来はJythonのbzrで動くかもね。

220 ：デフォルトの名無しさん：2009/11/09(月) 21:15:58

いい加減VSSとかやめて欲しいんだがうちの会社

221 ：デフォルトの名無しさん：2009/11/09(月) 21:22:39

VSS6cだかは死滅して欲しいな。

てかソースコードはUTF-8に統一して欲しい。
プラットフォームコード使って誰が幸せになるんだ。

222 ：デフォルトの名無しさん：2009/11/10(火) 02:20:11

UTF-8はダサイじゃん。
BOMの有無だの、それこそ「プラットフォーム特有」のエンディアンの違いを
サポートするだの、もうちょっと漢らしいスペックだったら、よかったのにね。
ちょいとばかり、女々し過ぎるスペックだよね＞UTF-8

223 ：デフォルトの名無しさん：2009/11/10(火) 07:57:03

ぼくのかんがえたさいきょうの国際化エンコーディング形式

224 ：デフォルトの名無しさん：2009/11/10(火) 08:03:48

TRONコードなんてなかった

225 ：デフォルトの名無しさん：2009/11/10(火) 10:23:27

UTF-8はもともとBOMいらないでしょ。
誰かが勝手に付け加えただけ。

226 ：デフォルトの名無しさん：2009/11/10(火) 11:16:09

BOMがないとシフトJISやEUCとの判別がつかないので、混在している今は必要悪でしょ。
たまに判別失敗して文字化けしてもいいなどという、いい加減なシステムはともかく。

FTPクライアントでBOMの有無を自動変換してくれると助かるんだが、俺が使っているのには
そういう機能がないな。

227 ：デフォルトの名無しさん：2009/11/10(火) 11:46:33

>>226
> BOMがないとシフトJISやEUCとの判別がつかないので、混在している今は必要悪でしょ。

Shift_JIS と EUC-JP と２つの時点で同じ問題があるのに BOM のようなものが必要に
ならなかったのはなぜでしょうか？

228 ：デフォルトの名無しさん：2009/11/10(火) 11:50:47

統計的判定や手動設定で妥協していただけで判別コードが必要なかったわけではない

229 ：デフォルトの名無しさん：2009/11/10(火) 11:56:18

でも実際にUTF-8のテキストファイルでBOMのせいで誤動作起こすケースがあるし
邪魔なことは邪魔。もともとミスで入れちゃったんじゃないの？
バイトオーダー関係ないのにBOMなんて・・・

230 ：デフォルトの名無しさん：2009/11/10(火) 11:57:39

美乳とか、な。

231 ：デフォルトの名無しさん：2009/11/10(火) 11:57:43

Winのメモ帳は強制的に入れてくるな

232 ：デフォルトの名無しさん：2009/11/10(火) 12:01:29

あるあるｗ
他の人がメモ帳で編集したjavaのソースがコンパイルで引っかかったっけな。
コンパイルの仕方もわからないのに編集してコミットすんなと。

233 ：デフォルトの名無しさん：2009/11/10(火) 12:45:47

>>226
gccじゃビルドできなくなるがな

234 ：デフォルトの名無しさん：2009/11/10(火) 13:07:39

UTF-8のBOMで酷い目にあったことは何度もあるが、BOMがあったおかげで救われたことはただの一度もないな。
必要悪ですらない。

235 ：デフォルトの名無しさん：2009/11/10(火) 13:14:29

VisualStudioは一応聞いてきたと思う。
BOMいれちゃってもいいのかい？と

236 ：デフォルトの名無しさん：2009/11/10(火) 13:18:15

ttp://pc12.2ch.net/test/read.cgi/tech/1236529563/359
359 名前：デフォルトの名無しさん[sage] 投稿日：2009/11/01(日) 18:37:16
EUCもSJISもJISも面倒見てくれるktermが、UTF-8以外は排除するxtermに駆逐されたのは納得いかない

↑わかるわかるｗ

237 ：デフォルトの名無しさん：2009/11/10(火) 19:48:52

BOM入れたときは、幸せになると思ったんだよ・・・
CPUにUnicodeネイティブで扱う機能がついたら幸せになるかもな。

って・・・もしかしてあったりするの？

238 ：デフォルトの名無しさん：2009/11/10(火) 22:03:21

JavaだとUTF-?の場合には8を除いてBOMを付ける。
BEだのLEだの付けるとBOMは付かない。合理的でいい。

239 ：デフォルトの名無しさん：2009/11/11(水) 05:49:57

40代2児の父親です。
上の娘がもうすぐ思春期を迎えるのですが、
結婚するまで傷物にしたくありません。
どのように管理すればよいでしょうか？

240 ：デフォルトの名無しさん：2009/11/11(水) 09:09:41

>>239
今すぐ結婚すればいいんじゃね?

241 ：デフォルトの名無しさん：2009/11/11(水) 09:26:15

>>239
こういうのって当人は面白いと思ってやってるのか？

242 ：デフォルトの名無しさん：2009/11/11(水) 12:23:51

場の空気を読めないやつって必ずいるよね

243 ：デフォルトの名無しさん：2009/11/11(水) 18:55:03

200レス分くらいスレをリロードしてなかっただけだから許してやれ

244 ：デフォルトの名無しさん：2009/11/11(水) 20:48:48

もっとファイルシステムに深くバインドされるべきだな。
ZFSだかはこの手のロールバックは得意らしいじゃん。
Windowsにシェル統合されるくらいならMSが統合しろよと。

245 ：デフォルトの名無しさん：2009/11/15(日) 13:55:31

>>129 >>132
うちの大学は、工学科だが(情報科もある)8年ほど前にクライアントマシンは全台
UnixのワークステーションからPCのWindowsに変わっちゃったぜｗ

行儀悪い学生のマシンにtelnetしてCD開閉できなくなって悲しす(どっちにしろ今はtelnetなんてふさぐだろうが)

>>194
しかしなんで、bzrをほめる時は、～～になれば一番、的な口調になるんだｗ
未来のことばっかｗ

246 ：デフォルトの名無しさん：2009/11/15(日) 13:58:49

実験室でWineつかってエロゲやってすみませんでした

247 ：デフォルトの名無しさん：2009/11/15(日) 14:09:37

>>245
現時点ではbzrの利点はUnicode対応とshared repositoryくらいのもんだな。

248 ：デフォルトの名無しさん：2009/11/15(日) 14:11:29

gitの運用上の質問があります。

例えば、下記のようなRailsアプリの雛形のようなリポジトリがあります。(リポジトリhogeとします)
psousa's baseapp-orange at master - GitHub
http://github.com/psousa/baseapp-orange

このリポジトリをforkして改変したい(例えば日本語リソースの追加など)(リポジトリmy_hogeとします)、
かつ、このmy_hogeリポジトリを雛形として新しいアプリを作りたいという場合(リポジトリmy_appとします)

もし、雛形を弄った変更をmy_appにも反映させたい場合は、
my_appをmy_hogeからcloneして、my_hogeを弄り、my_appでmy_hogeからpullすればOKですよね。

また、my_hogeの改変をぜひhogeに取り込んでほしいという場合には、
githubで言えば、pull requestして、pullしてもらえばいいわけですよね。

さて疑問があるのですが、my_appを作っているときに「あ、この機能は雛形にしておいたらいいな」と思った場合、
どうしたらいいものなんでしょうか？
つまり、my_appの機能の一部(もしくはあるコミット)をmy_hogeに適用したいという場合です。
単純に、my_appからmy_hogeにpushしてしまうと、全部適用されてしまうのですが、どうしたものでしょうか？
my_appでパッチを作って、my_hogeに適用、という原始的な形になるものでしょうか？

249 ：デフォルトの名無しさん：2009/11/15(日) 20:17:32

>>247
shared repositoryのどこがメリットなんだよwww

250 ：デフォルトの名無しさん：2009/11/15(日) 21:36:37

>>249
複数のブランチを分離しながら、共通するリビジョンをまとめて格納できるところ。

hgやgitは、複数のブランチがくっついた状態でリポジトリに格納されてしまっているから、
clone時に不要なブランチの分まで転送しないといけなかったり、
逆にある程度履歴が共通の別のブランチをcloneで持ってくるとすでに持っているリビジョンまで
転送したり格納したりしてしまって非効率。

251 ：デフォルトの名無しさん：2009/11/15(日) 22:38:42

>>248
＞もし、雛形を弄った変更をmy_appにも反映させたい場合は、
＞my_appをmy_hogeからcloneして、my_hogeを弄り、my_appでmy_hogeからpullすればOKですよね。
my_appをどこにも公開していないのなら、rebaseのほうが良いよ。

＞単純に、my_appからmy_hogeにpushしてしまうと、全部適用されてしまうのですが、どうしたものでしょうか？
＞my_appでパッチを作って、my_hogeに適用、という原始的な形になるものでしょうか？
どちらのブランチも自分で管理しているのなら、cherry-pickが使えると思う。

相手にpullリクエストするのなら、貰って欲しいコミットだけをまとめ直したブランチを
cherry-pickとかで作って、そこから貰ってもらう。

相手にパッチ送るなら、git format-patchで作れる（gitはパッチでやり取りするのは得意）

252 ：248：2009/11/17(火) 08:21:21

>>251
ありがとうございます。

my_appは公開しています。
my_appとmy_hogeは両方とも自分で管理しています。
rebaseと、cherry-pickを見てみます。

253 ：デフォルトの名無しさん：2009/11/17(火) 08:41:39

すみません
WindowsUpdate のような仕組みを
自作のプログラムにも入れたいのですが
どんなツールがありますか？

254 ：デフォルトの名無しさん：2009/11/17(火) 09:11:54

スレ違い

255 ：デフォルトの名無しさん：2009/11/17(火) 10:14:47

windowsとunix環境で使いたいのだけれど、コメントの文字コードは何にしたらいいですか？

256 ：デフォルトの名無しさん：2009/11/17(火) 10:38:58

使ってるバージョン管理システムによる

257 ：デフォルトの名無しさん：2009/11/17(火) 10:44:43

いやいやUTF-8の一択でしょ

258 ：デフォルトの名無しさん：2009/11/17(火) 10:50:29

コメントをバイナリでなく文字列として扱うシステムなら、そもそも文字コードをどうするかという概念すらないわけだが

259 ：デフォルトの名無しさん：2009/11/17(火) 11:34:19

bzr ってその場で古いバージョン取り出せないのか？
なんと不便な。

260 ：デフォルトの名無しさん：2009/11/17(火) 11:42:00

そんなアホなことあるかよ

261 ：デフォルトの名無しさん：2009/11/17(火) 11:46:52

>>253
バージョン管理以外にもCDNも必要だしね。

262 ：デフォルトの名無しさん：2009/11/17(火) 11:57:49

安易にアップデート機能つけるとUACではまる場合もある

263 ：デフォルトの名無しさん：2009/11/17(火) 15:09:29

>>260
bzrならあるかもねwww

264 ：デフォルトの名無しさん：2009/11/17(火) 15:28:24

どうしようもないばかだな

265 ：デフォルトの名無しさん：2009/11/17(火) 19:09:21

あふぃりえいとサイトでupdate配布して
そこにダウンロードしにいくプログラムを
大勢に配布するのが良いよ

266 ：デフォルトの名無しさん：2009/11/17(火) 19:45:49

>>253
VCS関係のプログラム作ってると解釈してマジレスしとく。
全て自前で揃えるとなると、ミラー鯖増やしたり、クライアント毎に更新に時間差を付けたり、公開鍵暗号使った改竄チェック付けたり、チェックサム検証付けたりと何かと大変。差分アップデートにするならバイナリdiffも必要。
オープンソースならcygwinのリポジトリにでも突っ込んどきゃおk。自前で作るにしてもGPLのソースならごろごろ転がってるし、ミラーの仕組みも整ってるから適当にガンバレ。
クローズドソースなら確実にセキュリティーの更新できるようにしろ、ただ勝手に自動起動するな、方法は知らんガンバレでFA。

267 ：デフォルトの名無しさん：2009/11/17(火) 22:52:17

なんだこいつ

268 ：デフォルトの名無しさん：2009/11/18(水) 07:04:03

IBMのClearCase使えよ
使いづらくておすすめだよ

269 ：デフォルトの名無しさん：2009/11/18(水) 08:15:06

執拗にClearCaseを攻撃してる奴は何をしたいんだ。

270 ：デフォルトの名無しさん：2009/11/18(水) 15:29:32

>>266
ありがとうございました

271 ：デフォルトの名無しさん：2009/11/18(水) 18:25:47

現在 svnが中心で、hgをちょっと試してみたいと思ってる身ですが
そこそこ hgで管理していった後に、やっぱり svnがいいなぁと思った場合は
hg → svn の移行をサポートしてくれるツールとかありますか？
svn → hg の移行はあるようなんですが...

272 ：デフォルトの名無しさん：2009/11/18(水) 23:40:17

>>271
svnは分散特有の名無しブランチ・マージを表現できないからhgからの移行は
厳しいんじゃないの

273 ：デフォルトの名無しさん：2009/11/19(木) 00:19:06

でも、bzrはsvkの形式でbzrのmergeをsvn上にpushできるぞ。

274 ：デフォルトの名無しさん：2009/11/19(木) 01:52:02

>>272
>svnは分散特有の名無しブランチ・マージを表現できないから
bzrは分散ではないということでいいですか？

275 ：デフォルトの名無しさん：2009/11/19(木) 01:57:14

えっ？

276 ：デフォルトの名無しさん：2009/11/20(金) 00:26:12

Activestateがtracベースのバージョン管理サービスを始めましたね

277 ：デフォルトの名無しさん：2009/11/20(金) 08:47:27

えっ？

278 ：デフォルトの名無しさん：2009/11/20(金) 14:03:37

>>276
https://firefly.activestate.com/
これ？

279 ：デフォルトの名無しさん：2009/11/20(金) 15:04:13

>>278
とりあえずプロジェクト作ってみたら、PublicになってPrivateにするやり方がわからない。
SCMはsubversionとMercurialが使える。
日本語使用が問題ないかどうかは試してない。
あと、truc糞重い。

280 ：デフォルトの名無しさん：2009/11/20(金) 17:02:58

>>279
金払わないとPrivateに出来ないけど払ったの？

281 ：デフォルトの名無しさん：2009/11/21(土) 06:38:45

>>280
もちろん払ってないよ。
とりあえずどんなものか見るためだけにプロジェクト作っただけだから。
あの重さじゃ、金払おうとは思わんね。

282 ：デフォルトの名無しさん：2009/11/21(土) 14:00:44

社命で来年度からClearCaseを導入することになってしまったんだけど、
使い勝手はどんなもんでしょうか？
>>1のテンプレートにものってないということは
かなりマイナーなソフトなんでしょうか？

283 ：デフォルトの名無しさん：2009/11/21(土) 14:10:49

>>282
ネタでないなら殺伐とするからやめれ
スレを検索しろ
ググレ
マジなら「ご愁傷様」の他にかける言葉がない

284 ：デフォルトの名無しさん：2009/11/21(土) 14:11:50

人によっちゃ「御愁傷様」って言われかねないレベルのソフト

285 ：デフォルトの名無しさん：2009/11/21(土) 14:13:01

あ、かぶったわ・・・

286 ：デフォルトの名無しさん：2009/11/21(土) 14:13:47

リロードしたら俺が無意識に2度書き込んだのかと思ったｗ

287 ：デフォルトの名無しさん：2009/11/21(土) 14:14:23

>>282
使ったことあるがウンコｗ

288 ：デフォルトの名無しさん：2009/11/21(土) 14:24:31

ﾜﾗﾀ

289 ：デフォルトの名無しさん：2009/11/21(土) 20:14:16

ワロタ
俺が書き込んだのかと思った

290 ：デフォルトの名無しさん：2009/11/21(土) 20:20:08

ClearCase使わされてる会社って「それ以外を排除しているかどうか」みたいな監査でも入るんか？
毎回思うんだけど。

291 ：デフォルトの名無しさん：2009/11/21(土) 21:53:13

IBMの営業から金を貰っているんじゃないだろうか

292 ：デフォルトの名無しさん：2009/11/21(土) 21:59:32

IBMもClearCaseの出来が悪いと分かっていながら（Wikipediaにもはっきり書かれちゃってるし）
取引先に使わせるとは酷だな。
仕事貰ってるとこが営業ってことで進んで買っちゃうのかもしれないけど。

293 ：デフォルトの名無しさん：2009/11/21(土) 22:09:50

仕事まわす代わりに自社のPCを買わせてるメーカもあるんだ。
それに比べりゃかわいいものさ。

294 ：デフォルトの名無しさん：2009/11/21(土) 22:53:00

ＰＣは壊れたときだけ差がつくが
Clearcaseは日常的にクソ

結構差は大きいと思うが

295 ：デフォルトの名無しさん：2009/11/21(土) 23:00:53

俺も毎回思うんだけど、ClearCase使わされてる会社って、普段はSVNなりなんなり
別のSCMを使っていて、たまに正式なコミットと称してClearCaseを使うっていうんじゃ
だめなのかね？

296 ：デフォルトの名無しさん：2009/11/22(日) 00:23:53

自分はローカルでrcsを使うことはある
ちょっとスナップショットを取りたいと思ったときに気軽に取れるから

297 ：デフォルトの名無しさん：2009/11/22(日) 05:37:52

>>292
バーターで無料にして無理やり(ry

298 ：デフォルトの名無しさん：2009/11/22(日) 05:39:32

>>293
凍斯波

299 ：デフォルトの名無しさん：2009/11/22(日) 18:42:22

>>296
mercurialとかの方がいいぞ。ディレクトリまるごと対象にできるし。/etc配下の管理なんかに使ってる。

300 ：デフォルトの名無しさん：2009/11/22(日) 20:56:49

分散型だけど完全ローカルでパーソナルユースにしか使ってなくても充分便利だよね

301 ：デフォルトの名無しさん：2009/11/23(月) 03:08:12

ClearCaseってIBMのRationalClearCaseのことで合ってるのかな？
それって評価版ってないの？
あればちょっと使ってみてレポートでもあげてみようかな。
どこまで屑なソフトなのかちょっと興味がある。

302 ：デフォルトの名無しさん：2009/11/23(月) 15:54:15

>>299
ディレクトリ全体でなく、ファイル一個だけ管理したい場合もある。
設定変更に自信がないときの一時バックアップとして、とか。

303 ：デフォルトの名無しさん：2009/11/23(月) 16:42:46

>>302
それだけならコピーしてリネームでいいんじゃね？とおもた

いや、バージョン管理するからには履歴が必要なんだろうけどさ

304 ：デフォルトの名無しさん：2009/11/24(火) 00:16:57

>>302
Mercurial はディレクトリは管理しない。強制的にすべてのサブディレクトリと
ファイルが管理対象になるわけじゃない。追加したファイルだけ。

前のデータサーバー(個人だけど)では/ etc の管理に CVS 使ってたけど、CVS は
ディレクトリ毎に管理ディレクトリができるから、apache の一部の設定など、ディレクトリを
再帰的に読んで、存在するすべてのファイルを設定ファイルとみなして処理しようとするような
ファイルの管理には不便だった。

Mercurial は、一番上に一つ管理ディレクトリができるだけだから便利。

305 ：デフォルトの名無しさん：2009/11/24(火) 01:18:58

>>301
IBMはもうRational Team Concertを押してる。
RTCのバージョン管理ツールがClearCaseの可能性もあるが知らん。

306 ：デフォルトの名無しさん：2009/11/24(火) 06:36:32

RationalClearCaseとRationalTeamConcerなんだけど

http://www.ibm.com/developerworks/wikis/pages/viewpage.action?pageId=106529021

よくわからんね

307 ：デフォルトの名無しさん：2009/11/24(火) 07:18:52

>>306
そこ見る限りもうClearCaseは過去の遺産のように思える。

308 ：デフォルトの名無しさん：2009/11/24(火) 14:11:21

amp
http://amp.carboni.ca/

これに期待

309 ：デフォルトの名無しさん：2009/11/24(火) 14:23:57

わざわざPythonで実装済みのものをRuby再実装する意味が判らない。
Pythonで開発すればmercurialやbzrとの100%互換性が手に入るし、
dulwichという高品質なgitライブラリもあるし、生産性は同等で、
起動速度もメモリ消費もPythonの方が有利だろうに。

310 ：デフォルトの名無しさん：2009/11/24(火) 15:59:54

Rubyで再実装することで、Rubyの他のプロダクトから使いやすくなるメリットが
ないわけではないかもね。

# dulwichがPythonで実装されてなかったら、bzr-gitはもっと大変だったはず。

311 ：デフォルトの名無しさん：2009/11/24(火) 16:15:35

逆逆。dulwichはbzr-gitのために作られたの。

312 ：デフォルトの名無しさん：2009/11/24(火) 17:26:29

なるほどそうなのか。Bazaar恐るべし。

313 ：デフォルトの名無しさん：2009/11/24(火) 17:54:13

開発陣のやる気だけは一流なんだよ＞Bazaar

314 ：デフォルトの名無しさん：2009/11/24(火) 18:57:48

>>313
だから将来に期待しとく。
いつになるかわかんないけど。ｗ

315 ：デフォルトの名無しさん：2009/11/24(火) 22:26:09

>>313
でもやる気だけだからねえwww

316 ：デフォルトの名無しさん：2009/11/24(火) 23:44:06

現在のBazaarには何が足りないの？
足りないのが人気だけなら、強力な機能を開発して人気Getは正しい戦略だと思うんだけど。

317 ：デフォルトの名無しさん：2009/11/25(水) 06:44:48

>>316
使えば分かるけど癖が強すぎる。

318 ：デフォルトの名無しさん：2009/11/25(水) 07:03:24

GoでGozaarを作ってみようと思う

319 ：316：2009/11/25(水) 07:25:34

>>317
使ってるけど癖が強いなんてこと全然無くて、何でこんなに人気無いのか不思議。

320 ：デフォルトの名無しさん：2009/11/25(水) 09:06:53

>>316
たんに後発だからでしょ。
ライバルはけっこう強力だしね。

オレは、bzrが普及したら使おうと
考えてるチキン。

321 ：デフォルトの名無しさん：2009/11/25(水) 13:25:50

>>316
>>213,>>263,>>274みたいなアホが多いから。

322 ：デフォルトの名無しさん：2009/11/25(水) 14:17:33

GUI付きだし、Windowsユーザーには一番向いてるよな
Ubuntu開発チームが生み出しただけのことはある

323 ：デフォルトの名無しさん：2009/11/25(水) 21:27:49

GUIは自分の環境だとダメダメだが、
SJISのダメ文字を扱えるだけで一択だわ

超頑張れ

324 ：デフォルトの名無しさん：2009/11/26(木) 01:07:08

>>319
update で任意のリビジョンを取り出せないとか十分使いにくいと思うけどな。
それに Tourtoise がプロジェクトに含まれてる割には完成度低いし。

325 ：デフォルトの名無しさん：2009/11/26(木) 01:53:23

>>324
update と完全に同じ挙動ってわけじゃないけど
任意のリビジョン取り出すだけなら revert -r revno じゃだめかな

326 ：デフォルトの名無しさん：2009/11/26(木) 02:17:06

まあ取り出せるけど、変更したことになるし。
大抵 update で任意のリビジョンが取り出せるから、
ほかのツールから移ってくると違和感おおありだね。
なんで合わせないのか不思議だ。今後実装されるんだろうか。

327 ：デフォルトの名無しさん：2009/11/26(木) 03:49:44

ググってみたら要望は以前からあるみたいだね。

https://bugs.launchpad.net/bzr/+bug/183559 とか見ると
pull --overwrite で代用できるのかな？

328 ：デフォルトの名無しさん：2009/11/26(木) 09:30:57

そもそも何のために過去のバージョンを取り出すのかによるけど、現行との差分を見たいならdiffだし、
逆に本当にスナップショットがほしいなら"export -r リビジョン番号"が正解。
過去の時点から分岐するなら "branch -r リビジョン番号" が正解。

「up -rリビジョン番号」というのは、目的に到達するために遠回りする過去の手法だと思ってる。
たいてい作業ツリーをまた最新版にもどすんでしょ？

329 ：デフォルトの名無しさん：2009/11/26(木) 11:48:36

なるほどねえ。理屈ではそうかも知らんけど、たとえば
コンパイルや実行にちょっとした準備が必要だったりする場合とか、
文書だったら、たかだか前のバージョンを取り出すためにテンポラリなディレクトリ
作りたくないとか、まあ好みかもしれないけど、意味はあると思う。

330 ：デフォルトの名無しさん：2009/11/26(木) 12:02:28

リモートリポジトリのブランチを指定してpullしようとすると
$ git pull origin foobar
fatal: Couldn't find remote ref foobar
というエラーがでて困ってます。
$ git branch -r | grep foobar
origin/foobar
というように、リモートリポジトリにfoobarブランチがあることは確認しています。
だれか助けて。

331 ：デフォルトの名無しさん：2009/11/26(木) 12:16:45

>>330
自己レス。
git clone し直してみたら、foobarなんてブランチはすでに消されてた。
つまりgit branch -rでは表示されるけど実際には存在していなかった。ｼｮﾎﾞｰﾝ
お騒がせしました。

332 ：デフォルトの名無しさん：2009/11/26(木) 13:34:21

>>329
作業ツリーの中で古いファイルを一時的に使いたい場合であれば、
bzr merge . -r-1..<戻りたいリビジョン>
で一旦古いバージョンに巻き戻して、必要な作業をした後、
bzr revert
で最新に戻すことで、一応できる。

もっと直接的な方法があるかどうかは不明。

333 ：デフォルトの名無しさん：2009/11/26(木) 23:12:41

>>328
よく使うのはちょっと前のリビジョンに戻してmakeして確認してみるという時
かなぁ。cvs→svn→hgと乗り換えてきたのでupdateが自然に感じるん
だが、gitやbzrはちょっと違っていて使い方がよくわからん。

334 ：デフォルトの名無しさん：2009/11/28(土) 09:30:29

何、bzrて任意のリビジョンとりだせないの？？？
マジで・・・

例えば、特定リビジョンで報告されたバグとか再現する時同じ環境用意するのどうすんだよ
片手落ちすぎる

335 ：デフォルトの名無しさん：2009/11/28(土) 10:05:36

bzr update -r revnoが実装されるまではbzr revert -r revnoとかbzr pull -r revnoとか使っとけ

336 ：デフォルトの名無しさん：2009/11/28(土) 15:05:29

exportでいいじゃん

337 ：デフォルトの名無しさん：2009/11/28(土) 16:57:27

>>332が答え言ってるじゃん。
revert や pull したら、最新リビジョンが古いリビジョンに設定されてしまうから、
また最新に戻すのが面倒。

338 ：デフォルトの名無しさん：2009/11/28(土) 19:31:29

どこかに各ツールのメリットデメリットの比較表とか機能別一覧表とかって
ありませんでしょうか？

339 ：デフォルトの名無しさん：2009/11/28(土) 21:02:55

>>338
どこかで巨大な比較表を見たことがあるような気がする。

340 ：デフォルトの名無しさん：2009/11/29(日) 00:05:35

これか？
ttp://www.atmarkit.co.jp/fjava/rensai4/devtool03/devtool03_5.html

341 ：デフォルトの名無しさん：2009/11/29(日) 00:34:08

そのページもいいね
記憶に残ってたのはこっちのほう
ttp://en.wikipedia.org/wiki/Comparison_of_revision_control_software
きっと見る気になれないと思う

342 ：デフォルトの名無しさん：2009/11/29(日) 00:50:30

>>341
MercurialのInternational Support (yes)とは何の冗談だろうか
Gitと同じくPartialが妥当だろう

343 ：デフォルトの名無しさん：2009/11/29(日) 01:04:35

>>342
日本人はみんな英語が使えるし、英語はインターナショナル語だし、Yesでいいんだよ。

344 ：デフォルトの名無しさん：2009/11/29(日) 06:37:49

>>340
>>341
トンクス

345 ：デフォルトの名無しさん：2009/11/29(日) 12:59:37

>>337
revert は最新リビジョンを古いリビジョンにすることはないよ。
作業ツリーの内容を書き換えるだけだから。
一時的にバージョン戻してビルドしたいという程度なら特に何も困らないと思うけど

346 ：デフォルトの名無しさん：2009/11/29(日) 18:37:35

>>345
うぉー、だとしたら>>332より直接的でいいな。
これあれば update -r イラネー。

347 ：デフォルトの名無しさん：2009/11/30(月) 00:44:16

でも状態は変更したことになってる。
以前の状態を完全に再現できているのか、ちょっと触っちゃってるのかまぎらわしい。

348 ：デフォルトの名無しさん：2009/11/30(月) 10:25:12

bzr pull -r使ったら-rで指定したリビジョンに戻ったけど指定したリビジョン以降のログが消えた。
どうやったらbzr pull -rを行う以前のリビジョンに戻せるんだ？リポジトリから消えたようにしか見えないが。
これじゃbzr pull -rがupdate -rの変わりになんてならないし、pullしてリポジトリの内容が消えるようなツールは使いたくない。

349 ：デフォルトの名無しさん：2009/11/30(月) 11:07:32

>>348
この流れでなぜ merge や revert じゃなくて pull を使うっ！？
全裸になって駅前で逆立ちしてから bzr heads --all で目的のリビジョンを見つけて、
その revision-id をメモって bzr pull . -r リビジョンID しろ。

350 ：デフォルトの名無しさん：2009/11/30(月) 17:45:14

bzrに手を出す奴ってどうしてバカばっかなの？
ろくにマニュアルも読まずに操作しといて「こんなツールは使いたくない」とか・・・

使わないのは勝手だが他人にまで愚痴んなよ

351 ：デフォルトの名無しさん：2009/11/30(月) 17:51:32

愚痴読みたくなきゃ来るな

352 ：349：2009/11/30(月) 19:00:17

>>350
いや、 >>349 の手順はマニュアルには書いてないから。
>>327 のところで同じハマり方した人がこの手順で復活してた。

353 ：デフォルトの名無しさん：2009/11/30(月) 21:52:31

gitも git checkout rev で戻すとrevの後のログが見えなくなるよね。
bzrも基本的には同じか。
hgは hg update -r rev で戻しても全部ログは残ってて、そこでcommitすると
ブランチができる。

354 ：デフォルトの名無しさん：2009/11/30(月) 21:59:11

ほかのツールがデファクトスタンダード的に統一しているところを
わざわざ変えてりゃそりゃ戸惑う。

Bazaar の実装がまともになるのが先か、Mercurial でエクステンション
レベルででもファイル名問題が解決するのが先かってところだが、
Mercurial(の日本ユーザー)の方が期待できそうだな。

355 ：デフォルトの名無しさん：2009/11/30(月) 22:00:47

ある程度のところで統一してくんねぇかな

356 ：デフォルトの名無しさん：2009/11/30(月) 23:55:47

>>354
Mercurialでファイル名の問題をエクステンションレベルでは解決できないので
Bazaarのコミッタになった。
update -r はマージ待ちの実装はあるから、 2.1 までには trunk に取り込まれると思う。

357 ：デフォルトの名無しさん：2009/12/01(火) 08:32:50

Bazaarは日本のコミッタが地道に頑張っているイメージｗ

358 ：デフォルトの名無しさん：2009/12/01(火) 17:20:18

>>354
fix-utf8でファイル名の問題は解決したはず。

359 ：354：2009/12/01(火) 17:27:56

>>358
fix-utf8 をいろいろ弄って、もう本家からforkするかbzrに移るしかないと決断した。

bzr はコマンドライン引数を GetCommandLineW() を使って取得するからUnicodeの
ファイル名を引数に受け取れるけど、hg はプラグインをロードする前に引数を利用しちゃうから
プラグインから sys.argv を utf-8 に置き換えても手遅れとか、plugin から wrap できる
範囲が足りなかった。

360 ：359：2009/12/01(火) 17:29:50

俺 354 じゃなくて 356 でした。

361 ：デフォルトの名無しさん：2009/12/01(火) 20:17:22

こればっかりはセンスの問題だからなあ．
主開発者が関心示さないとどうにもならん

362 ：デフォルトの名無しさん：2009/12/01(火) 23:59:28

>>361
ファイル名の問題とかセンスは関係ないと思うが…
日本語ファイル名を使わないという運用による対処もあるけど、ドキュメントとか資料の類は
日本語ファイル名使いたいときあるんだよなぁ。

363 ：デフォルトの名無しさん：2009/12/02(水) 00:20:23

gitのバグ報告にShift-JISのダメ文字問題がPOSTされてたが
「制御文字使う方が悪いよAhaha」みたいな返答されてたもんなあ
語学の定冠詞と同じで、ほぼ一生埋まらない認識のずれなのかもしれん

364 ：デフォルトの名無しさん：2009/12/02(水) 00:53:11

TOMOYO Linuxの開発者みたいにあきらめずにがんばればきっと・・・

365 ：デフォルトの名無しさん：2009/12/02(水) 01:10:07

既存のテストを全部パスするパッチを作るしかない、ぐらいの絶望感。

366 ：デフォルトの名無しさん：2009/12/02(水) 06:31:13

リリースする時にテストはやってるでしょうから、その中にマルチバイトのテストも書いてコミットしてやれば
人外どももテストできる。
問題はそれを通すコードも俺たちがかかないといけないかｗ

367 ：デフォルトの名無しさん：2009/12/02(水) 07:10:36

>>363
http://thread.gmane.org/gmane.comp.version-control.git/133963/
これ？

368 ：デフォルトの名無しさん：2009/12/02(水) 14:39:35

TortoiseHg 0.9.1来てるけど、インストーラがInternal error吐く……。
(インストール自体は中断せず終了)

なんか怖くなったからアンインストールしてしばらく様子見よう……。

369 ：デフォルトの名無しさん：2009/12/02(水) 20:16:19

>>368 と同じ症状になった。
Internal error: Expression error 'Runtime Error (at 1:229):
Internal error: Unknown constant "1"'

とりあえずインストールはできて使えてるようには見える。

370 ：デフォルトの名無しさん：2009/12/02(水) 20:48:51

>>367 Git本体じゃなくてTortoiseGitだった
http://code.google.com/p/tortoisegit/issues/detail?id=194&can=1&q=japanese

371 ：368：2009/12/02(水) 20:53:33

様子見と思ったんだけど、やっぱりバグ報告しときました。
でたらめ英語通じるかなぁ。

372 ：369：2009/12/02(水) 21:18:06

乙です

373 ：368：2009/12/02(水) 23:07:24

バグ報告にレスがありました。

>>368で書いたバグは、known problemでリリースノートにも書いてあるそうです。
(今見たらたしかに書いてある(汗)

インストールは問題なく完了しているそうです。

374 ：368：2009/12/02(水) 23:14:05

と思ったけど、よく読んだら、kdiff3が動かなくなっている原因がこれかもしれないらしい。
みたいな。(英語の読解自信なし)

ワークアラウンドとして、mercurial.iniを修正すればいいようなことが書かれてます。

375 ：デフォルトの名無しさん：2009/12/03(木) 00:15:44

TortoiseGit と EGit ってどこまで共存できるのかな。
EGit でコミットしても TortoiseGit からみるとまだ「変更あり」になってるし、
でもちゃんとコミットはできてるみたいだしで、よくわかんないことに。

加えて EGit だけではできないことあるから、TortoiseGit なり Git 本体なりを併用したいんだけど
TortoiseSVN と Subversive が大喧嘩して痛い目にあった経験があって、どうにも不安で併用に踏み切れない。

だれか併用したことのある人っている？

376 ：デフォルトの名無しさん：2009/12/03(木) 05:49:19

TortoiseGitの日本語マルチバイト周りはどこまで進展しておりますか？
個人的にgit使う分にはコマンドラインでcygwinのUTF8仕様を使えばいいのですが、
cygwin、UTF8DLLの導入、cygwin git、TortoiseGitと用意するものが多くて他人に勧めにくいです。(cygwinは嫌がるひとも多い)

これってどこに文句言えばいいもんですかね。TortoiseGit？git？msysgit？

いぜんsourceforge当たりでTortoiseGitを「実用になってきた」みたいな飛ばし記事書いたアフォもいましたが・・・。

Mercurial(TotoiseHg)の方は根本解決ができないようなので、見限りました orz

377 ：デフォルトの名無しさん：2009/12/03(木) 07:56:44

gitでこういう運用て可能ですか？

wikiみたいなアプリ(DB未使用アプリ)を共有レンタルサーバーにおいておいて、
ローカルでアプリテストを行いpushするとサーバー側に反映される、
pullして本番環境でのwikiのデータ編集などをローカルにマージ、といったような運用です。
どのようにすれば可能でしょうか？

デプロイとごっちゃになってますが、gitでできれば楽だなと思いまして

378 ：377：2009/12/03(木) 07:58:15

鯖側はsshのshellは開放されており、自前コンパイルはできる状態のようです。
.gitの隠蔽の問題は、httacessでできるか…。

ssh+gitでできそうな気がしてきた

379 ：デフォルトの名無しさん：2009/12/03(木) 14:23:10

ttp://www.kernel.org/pub/software/scm/git/docs/githooks.html
ttp://at-aka.blogspot.com/2009/05/git-push.html

hook書けばいいんじゃ？

380 ：デフォルトの名無しさん：2009/12/03(木) 18:19:24

>>377
その方法で出来ると思う。ネックは鯖側にもgitをインスコしないといけないこと
なんだけど、それはクリアできそうだね。

出来ればbareじゃないとこ（鯖とか）にpushするのは避けたほうが良いと思うけどね。

381 ：377：2009/12/03(木) 19:53:16

>>379
おお！こんな方法が試してみます！

>>380
bareじゃないとこにpushするのはマズイもんですかね？どこかドキュメントに記述などありますでしょうか？

382 ：デフォルトの名無しさん：2009/12/03(木) 20:13:02

>>381
pushした先でチェックアウトしてるブランチが伸びてしまう場合、突然差分が発生することになる。
pushされたワーキングツリーで変更してなければresetすればいいけど、変更がある状態だったりすると、
突然コンフリクトしてしまう可能性がある。
http://git.or.cz/gitwiki/GitFaq#non-bare

なのでGit1.7からは現在チェックアウトしてるブランチにpushするのはデフォルトで拒否するようになる予定。
まあやってみれば分かると思うんだけど、自分で何をやってるか分かっててやるなら、
問題ないんだけどね。

383 ：デフォルトの名無しさん：2009/12/12(土) 02:19:31

Gitのコミュニティーに参加して、国際化対応を推進できるような猛者は
いないのだろうか

やはり日本語ファイル名が扱えないのは不便すぐる

384 ：デフォルトの名無しさん：2009/12/12(土) 02:32:19

>>383
仕事でsvnと連携して使ってるけど、日本語ファイル名で困ったこと一度も無いよ

385 ：デフォルトの名無しさん：2009/12/12(土) 02:46:07

OSを跨ぐと化けるんだよ

386 ：デフォルトの名無しさん：2009/12/12(土) 03:06:05

へ？　相手はWindowsでこっちMacとかLinuxだけど。

387 ：デフォルトの名無しさん：2009/12/12(土) 09:13:29

>>383-386
環境を書こうぜ

388 ：デフォルトの名無しさん：2009/12/12(土) 10:06:04

svnを使っている時点で、ファイル名のUnicodeへの正規化ができてるんだよ。

389 ：デフォルトの名無しさん：2009/12/12(土) 10:24:39

>>387
環境って…これ以上何書けばいいの？
svnのバージョンは1.5とかだったような気はするけど。
たぶんWindowsの人はTortoise使ってそうかな。わかんないけど。

390 ：デフォルトの名無しさん：2009/12/12(土) 10:55:32

MacのFinderで濁点付きのかなを含む日本語の名前のファイルを作ると
裸のかなと濁点に分解された形で正規化される。
LinuxやWindowsは合成した形のまま使われる。

391 ：デフォルトの名無しさん：2009/12/12(土) 11:32:51

>>387
gitのバージョン、cygwin版か否か(UTF-8版かどうか)、svnのバージョン（は書いたか）、Tortoiseなんたら使っているならそのバージョン

ケチつけたいんじゃなくて参考にしたい。
git日本語どうもうまくいかん

392 ：デフォルトの名無しさん：2009/12/12(土) 12:09:48

384 = 386 = 389はMac/Linuxのgit-svnで、相手がWindowsのSubversionなんだからそりゃ化けないだろ。
問題なのはWindowsのgitを使ってLinux/Macのgitとやりとりする場合。

393 ：デフォルトの名無しさん：2009/12/12(土) 12:48:32

>>392
ああそういうことか。svnがリポジトリでクライアントがWindows以外なら大丈夫か。

394 ：デフォルトの名無しさん：2009/12/12(土) 15:23:49

>>392
cygwin(UTF-8)のGitを使うならLinux/Maxのgitとやりとりしても大丈夫なのですか？
Git使うためだけにcygwin入れるのは抵抗あるけど。

395 ：デフォルトの名無しさん：2009/12/12(土) 15:56:07

msysgitがSJISのダメ文字を扱える日をずっと待ってる

396 ：デフォルトの名無しさん：2009/12/12(土) 16:15:30

もともとmsys入れてる俺にとって
msysgitを別個で入れさせられるってのが気に食わない

397 ：デフォルトの名無しさん：2009/12/12(土) 18:58:51

Unicode API使ってUTF-8に変換してくれればだいたいOKなんだろうけどなぁ。
今のところ見込みありそうなのはUTF-8 cygwinしかないか。

398 ：デフォルトの名無しさん：2009/12/12(土) 21:25:56

運用で回避なんていやすぎる

399 ：デフォルトの名無しさん：2009/12/12(土) 22:17:43

いやだから日本語ファイル名使いたいならsvnかbzr使えばいいだろ。

400 ：デフォルトの名無しさん：2009/12/12(土) 22:49:15

お前に言われんでもｒｙ

いや実際svnはともかく、bzrとgitの違いなんてあんまない
だが、「gitはLinuxカーネルのソースコード管理に使われてる」という殺し文句は
非常に説得力があるのよ（主に管理職相手に）

401 ：デフォルトの名無しさん：2009/12/13(日) 00:20:41

というか、ソースコードのファイル名に日本語なんか使っているの？

402 ：デフォルトの名無しさん：2009/12/13(日) 00:24:10

>>401
ソースコード以外にもバージョン管理するものはありますよ

403 ：デフォルトの名無しさん：2009/12/13(日) 00:29:56

まあ、そうくるとおもったが、
2バイトコードのファイル名はなにかとトラブルのもとなので、使わないっていう運用してる。

404 ：デフォルトの名無しさん：2009/12/13(日) 00:32:16

>>401
そもそもプログラマだけ使うもんじゃないし、ソース以外も管理するから、
プログラマでソースだけ管理なら日本語気にしないでいいと思う、習慣的に

問題はグラフィッカが日本語普通に使ったり、ドキュメントが日本語名つけるのが当たり前になってたりする場合。

バージョン管理なんてただでさえ(面倒くさがりに覚えさせるのは)面倒なんだから、
下手な制限があると導入が難しいんだよね・・・

405 ：デフォルトの名無しさん：2009/12/13(日) 00:34:01

日本語ファイル名を当たり前に使う場に、日本語ファイル名が使えないんじゃなくて、使うとトラブル、なんてソフト導入不可能だよ、普通

406 ：デフォルトの名無しさん：2009/12/13(日) 00:51:01

バージョン管理システムを覚えさせることができるぐらいなら、
2バイトコード禁止は簡単そうなんだけどなあ。
これ乗りきっても、またほかのところで問題出て来ると思うよ。

407 ：デフォルトの名無しさん：2009/12/13(日) 00:53:33

日本語のファイル名付けるのなんて、どうせマージ不能のバイナリファイルだろ？
だったらそっちはそっちで別に管理すればいいんじゃね？ CVSなりSubversionなり。
プログラマは分散型使いたいだろうから、そっちもそっちで好きにやる。
ついでに言うとバカデカい本番用の動画コンテンツ郡とかも別リポジトリにしてくれれば
プログラマは嬉しいんだがなかなかそうならない。

408 ：デフォルトの名無しさん：2009/12/13(日) 00:57:47

皆SVNの使い方とか会社で勉強させられたの？

409 ：デフォルトの名無しさん：2009/12/13(日) 01:29:41

学生のときから知ってたよ

410 ：デフォルトの名無しさん：2009/12/13(日) 02:14:46

>>408
普通入れさせる側。

411 ：デフォルトの名無しさん：2009/12/13(日) 02:22:20

うちはそもそも使えるエンジニアしか採ってないな。

412 ：デフォルトの名無しさん：2009/12/13(日) 02:24:32

そんなもん教えりゃすぐ使えるようになるだろ

413 ：デフォルトの名無しさん：2009/12/13(日) 04:39:33

設計書とかのドキュメントや画像ファイルはsvnで管理して
ソースだけGitで管理
っていうのが現状だと一番いい選択肢かもしれない
仮にGitで日本語ファイル使えるようになっても、プログラマー以外のやつが
Gitを使いこなせるとおもえんし
へたするとプログラマーでもGitで挫折するやついるかもしらん

414 ：デフォルトの名無しさん：2009/12/13(日) 09:09:36

そんなバカ実在するのか

415 ：デフォルトの名無しさん：2009/12/13(日) 09:38:52

svnすら導入できないシステム開発会社もあるんだぜ
上場企業のシステム系子会社だけど
ソースはフォルダ名の変更（日付）で管理してるからしょっちゅうゴチャゴチャになる。
前の版で修正したのが、次の版では修正前に逆戻りとか。そりゃ客に怒られるわ
管理部門の人にsvnぐらい入れればって言ったら、難しくて理解できないだとさ

416 ：デフォルトの名無しさん：2009/12/13(日) 09:44:05

>>413
確かにそうだなー
TortoiseSVNがこなれているし、その他はsvnでもいいのかも。
バイナリの扱いも枯れてきているせいかそんなに悪くないし、というかトラブった覚えない。

問題はちょっとスタバで仕事したいとか、出張先でドキュメント書きたいと言うときか。
svkて終わってるんだっけ？
それこそ、git-svnとかbzr-svnつかえばいいのかｗこの辺ってsvnリポジトリにアクセスできなくても使えるんだよな？

417 ：デフォルトの名無しさん：2009/12/13(日) 13:43:16

>>400
bzrはGNUのプロジェクトだぜ

418 ：デフォルトの名無しさん：2009/12/13(日) 13:51:16

>>417
え？

419 ：418：2009/12/13(日) 13:52:20

失礼、これか。
http://lists.gnu.org/archive/html/info-gnu/2008-05/msg00012.html

420 ：デフォルトの名無しさん：2009/12/13(日) 13:54:04

>>417
スマン、真意がわからん
GNUプロジェクトだから、で話が済む管理職ならどんなに楽か

421 ：デフォルトの名無しさん：2009/12/13(日) 14:14:53

emacsとかMySQLとかはあるけど、Linuxカーネルのgit, JavaやSolarisのhg にブランドで対抗するには
gcc くらいほしいな。

422 ：デフォルトの名無しさん：2009/12/13(日) 14:16:36

>>417
ここ数年、GNUのプログラムの品質は決して高くないとおもうなあ。
20年前は、圧倒していたけど。
なんか、高尚な目標を立てても、中途半端で終わってる気がする。

423 ：デフォルトの名無しさん：2009/12/13(日) 14:25:21

「Linuxカーネルの開発に使われてます」だと「それはすごそう」ってなって、
「GNUプロジェクトです」だと「ふーん」ってなるのか。

まあ確かにGNUプロジェクトよりLinuxカーネルのほうが活発度は上回ってるだろうけど
たぶん「ふーん」ってなる人は単に知名度でそう思うんだろうな。

424 ：デフォルトの名無しさん：2009/12/13(日) 14:27:07

GNUのプロジェクトが何か分かってもらえないんじゃないの

425 ：デフォルトの名無しさん：2009/12/13(日) 14:36:04

組込み世界だといまだに
GPLすら知らない部長・マネージャクラスがいぱい

426 ：デフォルトの名無しさん：2009/12/13(日) 15:28:02

Linuxカーネルのソースを管理してるっていう実績の問題でしょ。
GNUプロジェクトだぞとか言われても話がかみ合ってない。
比較するなら、こういうプロダクトの管理に使われてるっていう例を持ってこないと。

427 ：デフォルトの名無しさん：2009/12/13(日) 15:41:26

>>425
それは訴訟リスクが高すぎないか?
現場がわかってれば大丈夫かも知れんけど
若い人はこぴぺでレポート作っちゃう世代だからなぁ

428 ：デフォルトの名無しさん：2009/12/13(日) 15:43:26

Gitなら、日本人がメンテしているという方向からもアピールできるな。

429 ：デフォルトの名無しさん：2009/12/13(日) 16:27:21

>>427
でも、そういう知識があるやつほど毛嫌いされる
サーバ、ネットワークもまた然り

古い人にとって、得体の知れないものは怖いのはどこでもいっしょ

まぁ表現の仕方次第なのかも知れんが

430 ：デフォルトの名無しさん：2009/12/13(日) 17:14:59

>>423
前者は使用された実績、後者は単なるブランドって事なんじゃね？

431 ：デフォルトの名無しさん：2009/12/13(日) 17:21:51

ブランドでも、Linux > GNU だよね。
Linus 自身が Linux のために作ったというのは、ブランドとして最強じゃないか？

432 ：デフォルトの名無しさん：2009/12/13(日) 17:45:10

まあストールマンの憤りの原因も、そういう状況に対してなんだろうな

433 ：デフォルトの名無しさん：2009/12/13(日) 18:41:12

さっさとHurd 1.0をリリースしろよと

434 ：デフォルトの名無しさん：2009/12/13(日) 19:10:17

誰得

435 ：デフォルトの名無しさん：2009/12/13(日) 19:24:33

darcs

436 ：デフォルトの名無しさん：2009/12/13(日) 21:32:03

>>431
あと、メンテナが日本人。
（もしかしたら、本人そういう持ち上げられ方嫌いかもしらんが）

437 ：デフォルトの名無しさん：2009/12/13(日) 21:33:38

メンテナが日本人でも成果物の多言語対応がうんこだから何の意味もない

438 ：デフォルトの名無しさん：2009/12/13(日) 22:11:02

x メンテナが日本人でも成果物の多言語対応がうんこだから何の意味もない
o メンテナが日本人でも成果物の多言語対応がうんこだったら何の意味もない

439 ：デフォルトの名無しさん：2009/12/13(日) 22:17:22

うだうだ言ってるけど結局TortoiseSVN最強というのは動かないみたいだな

440 ：デフォルトの名無しさん：2009/12/13(日) 22:32:46

お前にはTortoiseSVNがお似合いだ

441 ：デフォルトの名無しさん：2009/12/14(月) 00:19:21

最強つうか、現時点で一番マシって感じだな
マルチバイト文字に対応してて、馬鹿にも安心して使わせられるツールじゃなきゃ
導入なんかできないだろ

442 ：デフォルトの名無しさん：2009/12/14(月) 13:02:12

今更だけど…IBMさん何してはるんですかｗ
ttp://www.ibm.com/developerworks/jp/web/library/wa-git/index.html

443 ：デフォルトの名無しさん：2009/12/14(月) 13:11:44

>>442
え。developerWorks は、いいサイトだと思うけど。

444 ：デフォルトの名無しさん：2009/12/14(月) 13:47:09

>>442
関西人じゃないので
>何してはるんですか
のニュアンスが良くわからないのだが、いったい何を言いたいの？

445 ：デフォルトの名無しさん：2009/12/14(月) 13:59:53

>444
「何をしていらっしゃるのですか？」という意味。
語尾のwを考慮すると本人は多少の皮肉を込めているつもりらしい。

446 ：デフォルトの名無しさん：2009/12/14(月) 14:01:35

こういうあからさまなユーザー誘導は萎えるな。GIT陣営から一体いくらもらったんだ。
http://www.ibm.com/developerworks/jp/linux/library/l-git-subversion-1/index.html

447 ：デフォルトの名無しさん：2009/12/14(月) 14:12:52

Subversion ユーザーのための Rational ClearCase

448 ：デフォルトの名無しさん：2009/12/14(月) 14:31:17

>>446
http://www.ibm.com/developerworks/jp/
の左メニューにあげられてる製品・企業には言うこと無いの？

449 ：デフォルトの名無しさん：2009/12/14(月) 14:44:42

developerWorksのこと知らなかった奴が、IBMが唐突にGit押ししてると勘違いしてるんだろう。

450 ：442：2009/12/14(月) 15:16:16

言い訳しに来ました。

>>444-445
ナイナイ矢部風に読んでくれると助かる。

>>442 >>449
IBMが以前からオープンソースに多大な貢献をしてきたことは知ってる。
でも「Clearcaseを押し付けてくる」ってイメージがあったから、Gitについての記事書いていたのが意外だったわけよ。

451 ：デフォルトの名無しさん：2009/12/14(月) 15:50:16

ますます何を言いたいのかわからん

452 ：デフォルトの名無しさん：2009/12/14(月) 16:05:24

なんでｗなのか理解不能。

453 ：デフォルトの名無しさん：2009/12/14(月) 16:18:17

>>450
言い訳なんかしていい（ｒｙ

454 ：デフォルトの名無しさん：2009/12/14(月) 17:24:42

なにしてはるんですかって、やってはいけないことをやったときに言うのかと思ってた。
高菜食べたときとか。

455 ：デフォルトの名無しさん：2009/12/14(月) 17:48:12

この流れキモチワルイ

456 ：デフォルトの名無しさん：2009/12/14(月) 18:35:30

岡村さん、なにしてはるんですかー！ｗ
みたいなツッコミは、めちゃイケとかで
よく見るじゃん。

実はあんまり通じないのか？

457 ：デフォルトの名無しさん：2009/12/14(月) 18:50:59

まだテレビなんか見てるのか

458 ：デフォルトの名無しさん：2009/12/14(月) 21:06:57

今度はテレビ見てない自慢厨か

459 ：デフォルトの名無しさん：2009/12/15(火) 12:06:01

>>401
ソースファイル名にマルチバイト文字使ってるとこなんてないよなとか思いながら
手元のディレクトリ内を確認してたら、
「HogehogeServlet_ｲｯﾁｰが直すまで.java」なんてのがあったorz

>>415
ウチも去年までは、まさにそんな感じだった。
俺が独断で SVN（ソースコード）と VSS（ドキュメント類）入れて全部面倒見るようにしたよ。

SVNは基本的にリソースをロックせず競合が発生しうる点を嫌がったり、
ブランチとマージの概念が馴染みにくいって人が多いような気がするなー。

460 ：デフォルトの名無しさん：2009/12/15(火) 12:53:06

Visual Studio 2010リリースと同時期に、Team Foundation Serverも
追い銭無しで自由に使えるようになるみたいだぞ。MSDN会員向けの話だが。

461 ：デフォルトの名無しさん：2009/12/15(火) 23:47:31

皆自分のプログラムは趣味でもsvnで管理してるの？

462 ：デフォルトの名無しさん：2009/12/16(水) 00:04:58

プログラムじゃなくてもバージョン管理してるよ

463 ：デフォルトの名無しさん：2009/12/16(水) 00:36:34

出退勤のエクセルファイルもバージョン管理してるぞ

464 ：デフォルトの名無しさん：2009/12/16(水) 01:42:52

>>461
仕事で試して趣味で使う。常識じゃないか？JK

465 ：デフォルトの名無しさん：2009/12/16(水) 03:02:01

やっぱsvnとか使うのは仕事し始めてからだよね

466 ：デフォルトの名無しさん：2009/12/16(水) 08:55:07

オープンソース系のプロジェクトとかに触れてれば、学生時代からでも使う機会はあるはず

467 ：デフォルトの名無しさん：2009/12/16(水) 10:07:52

バージョン管理しないと何も書けない
変更点の差分とか取れないと落ち着かない

468 ：デフォルトの名無しさん：2009/12/16(水) 16:44:43

誰かが共有ディレクトリの.svnを全部消した
何が更新されてるかわからないので ~/foo/*/*/.svn を全部　/pub/foo/*/*/
にコピーしたいのだけど、何かいい方法ないのだろうか

469 ：デフォルトの名無しさん：2009/12/16(水) 16:55:28

がんがれ！
がんがって、全部人間が確認し直すんだ。
そして、Subversion管理してるからって共有ディレクトリに
なくなっても構わない物「以外」を置いた自分を呪うがいい。

470 ：デフォルトの名無しさん：2009/12/16(水) 17:01:09

>>468
別のディレクトリにチェックアウトして.svnがないディレクトリから上書きすれば

471 ：デフォルトの名無しさん：2009/12/16(水) 17:12:11

exportしてdirectory単位でdiff取れば？

472 ：デフォルトの名無しさん：2009/12/16(水) 17:39:26

>>468
% cd ~/foo/
% find . -type d -name .svn|xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -)
(スクリプトの中身はちゃんと理解して使ってね)

>>469
パスワードとか入れたファイルもsvnで管理するのが常識なのですね。わかります。

473 ：デフォルトの名無しさん：2009/12/16(水) 17:42:02

共有には入れないかな

474 ：デフォルトの名無しさん：2009/12/17(木) 00:41:22

> % find . -type d -name .svn|xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -)
> (スクリプトの中身はちゃんと理解して使ってね)

ヘタレなんで意味がわかりません
実行するとどうなりますか

475 ：デフォルトの名無しさん：2009/12/17(木) 00:44:22

いくらバージョン管理してても、アフォがリポジトリのフォルダ壊したら
全部パーだからな

俺は毎日、リポジトリを丸ごとzipに圧縮してバックアップ撮ってる

476 ：デフォルトの名無しさん：2009/12/17(木) 02:15:03

>>474

「find . -type d -name .svn」 --> .svnってディレクトリを検索
「xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -)」　-->　上の結果をなんかアーカイブにまとめてる
詳しくは知らないがたぶんこんな感じだろう

477 ：デフォルトの名無しさん：2009/12/17(木) 07:46:42

>>472
xargs 要らないんじゃない？

find . -type d -name .svn|tar -cf - -T -|(cd /pub/foo/;tar xvf -)

478 ：デフォルトの名無しさん：2009/12/17(木) 10:46:07

>>476
xargs tar -cf - -T -|(cd /pub/foo/;tar xvf -) がさらに2つに分かれて
「xargs tar -cf - -T -」 --> findで発見したディレクトリ以下を圧縮
「(cd /pub/foo/;tar xvf -)」 --> /pub/fooの下に展開

>>477
実験してみた。確かにxargsなしでも動いた。

479 ：デフォルトの名無しさん：2009/12/17(木) 12:25:39

tar に -C つければ cd も不要かと。

しかしよく考えれば、 rsync だけで事足りるような気がする...。

480 ：デフォルトの名無しさん：2009/12/17(木) 12:28:15

rsync は　. から始まるファイルをなぜか無視する
しかし _darcs はコピーする
なんで .dacrs じゃなくて _darcs　なんだろ

481 ：デフォルトの名無しさん：2009/12/17(木) 12:59:07

そもそも >>468 が作業コピーを共有しているなどという
運用方法には誰も突っ込まないのか。

482 ：デフォルトの名無しさん：2009/12/17(木) 13:31:16

>>481
テスト環境とかで複数用意するのが困難なのもあるので
(いまだど仮想マシンを使えるかもしれないけど)
共有することもあるかな。あとテストを複数人(チーム）で実施するときとか。
パケットをモニタしながら複数の機器を操作してとか
目玉の数と手の数が重要なテストもあるので。

483 ：デフォルトの名無しさん：2009/12/17(木) 15:08:27

>>482
そういうとき、うちでは linux で作業コピーを作り、
smb.conf で veto files = /.??*/ してる。

484 ：デフォルトの名無しさん：2009/12/17(木) 19:54:47

>>480
rsyncにコピーしてもらいたかったからだったりしてｗ

485 ：デフォルトの名無しさん：2009/12/17(木) 23:02:49

>>475
gitがMercurialを使えば？
自称分散型なbazaarは駄目だぞw

486 ：デフォルトの名無しさん：2009/12/17(木) 23:15:47

俺も Bazaar にはちょっと期待してたんだが、
未実装なのか考え方がズレてんのか、
とにかくこれは無いなと思った。

487 ：デフォルトの名無しさん：2009/12/17(木) 23:52:27

>>485
どの辺が自称なの？

>>486
仕事で他の人間と一緒に使うなら現状 subversion以外ありえんな。

488 ：デフォルトの名無しさん：2009/12/18(金) 01:05:39

うちの会社いまだにVSS使ってるんだが
その理由がロック方式のほうが安心だから。っていうしょうもない理由

みんな仕事でSubversionとか使ってるの？
コンフリクトの解消とか、バイナリファイルの扱いとかが
ややこしくなるのでPLがイヤがるんだが実際どうなの？

489 ：デフォルトの名無しさん：2009/12/18(金) 01:22:27

コンフリクトが発生する原因は、単純にプロジェクトの運営がまずいだけ。
要するにPLがクソ。

バイナリファイルの扱いがややこしくなるのは、単純にプロジェクトの運営がまずいだけ。
要するにPLがクソ。

結論、そんなPLは、どんなバージョン管理システムを使っていようがプロジェクトの
邪魔になるだけなので、クビにすべき。

490 ：デフォルトの名無しさん：2009/12/18(金) 02:37:11

真理すぎてワラタｗ

491 ：デフォルトの名無しさん：2009/12/18(金) 03:41:17

OSSみたいに誰がコミットするかわからないとかならまだしも
会社のプロジェクトでコンフリクトが発生するってどんだけー

492 ：デフォルトの名無しさん：2009/12/18(金) 08:01:57

⊂⌒⊃｡Д｡)⊃カジ速≡≡≡⊂⌒つﾟДﾟ)つFull Auto | セブンアンドワイ、今度はソースコードを流出させる。
http://www.kajisoku.net/1/archives/eid284.html

.svnディレクトリ大公開祭り
お前らも気をつけろよ！！

493 ：デフォルトの名無しさん：2009/12/18(金) 08:04:12

Bazaarローカルブランチないのに絶望した！
日本語ファイル名考慮すると頼みの綱はお前だけなのに

494 ：デフォルトの名無しさん：2009/12/18(金) 08:16:44

>>488
ロック機能も一応あるんで、
必要なら使えば。

495 ：459：2009/12/18(金) 09:32:07

>>489
>>491
うーん、ウチの会社で SVN 使ってるけど、競合起きたことあるよ……orz

こっちが業務ロジックの追加を行う案件（事前に計画済み）を実施してる途中で、
DBコネクションのリークが原因の本番系ダウンが起きて緊急にコード修正したんだけど、
計画案件ブランチのコードを trunk へマージする際に、先にコミットされた障害対応コードと
競合しちゃったんだよなー。

本来なら、いったん障害対応コードを計画案件ブランチ側へ取り込んで（マージして）から
trunk へ持って行くべきなんだろうけど……

あと、どーでもいーけど、>>492の先に置いてある魚拓見たら svn:needs-lock が入ってるね……

496 ：デフォルトの名無しさん：2009/12/18(金) 10:44:10

それは知らなかった

497 ：デフォルトの名無しさん：2009/12/18(金) 11:23:05

>>485
またアホが湧いてきたか

498 ：デフォルトの名無しさん：2009/12/18(金) 11:26:04

>>493
ローカルブランチあったら便利だけど、無くても困らないよ。
んでもって、今開発進んでるから、半年後までに公式プラグイン登場、1年後には標準搭載
されてるんじゃないかな。

499 ：デフォルトの名無しさん：2009/12/18(金) 12:26:46

>>480
>rsync は　. から始まるファイルをなぜか無視する
>しかし _darcs はコピーする
>なんで .dacrs じゃなくて _darcs　なんだろ
FAQ Why doesn't darcs use a hidden directory like .darcs for metadata, rather than the visible _darcs?
http://wiki.darcs.net/FrequentlyAskedQuestions#why-doesnt-darcs-use-a-hidden-directory-like-darcs-for-metadata-rather-than-the-visible-darcs
Issue 129 _darcs/ to .darcsrepo
http://bugs.darcs.net/issue129

500 ：デフォルトの名無しさん：2009/12/18(金) 12:41:09

質問なんですが、こういう時どういう運用すればいいもんでしょうか？

Subversionで特定の新機能をブランチ切ってで開発し一段落したら、
開発し終わったらtrunkに切り替えて、ブランチを指定して(もしくはブランチのリビジョン範囲指定して)マージしてます。

問題は分担作業してて、相方のブランチ作業が長い時に
こちらがtrunkで作業したりマージしたりした成果物を相方のブランチの方へも適用したいときは
どうしたもんでしょうか？
(相方のブランチの方を最新版へ追従したい)

gitとかだとmasterのリポジトリからpullったら自動でmasterでの変更の差分が
branchへ(というか手元のリポジトリの作業しているソースへ)うまいこと適用されますよね？たしか

分散とも双方とも理解が曖昧なので、間違いやこうしたらいいよというのを指摘ください。

>>498
マジカ！サンクスbzrにも期待

501 ：デフォルトの名無しさん：2009/12/18(金) 13:17:34

よくわかんないな。
相方の branch 側が trunk を適当なタイミングで merge するのじゃダメなのかしら?
変更点が入り組んでたりすると、面倒といえば面倒だけどね。

502 ：デフォルトの名無しさん：2009/12/19(土) 00:49:59

大規模なプロジェクトなんで、ファイル数が30万くらいでトータルサイズが500Gくらいあるんだけど、gitだとサクサク管理できますか？

503 ：デフォルトの名無しさん：2009/12/19(土) 02:09:33

>487
git-svn で自分は git 使うってのもありだと思う。

>500
Subversion なら >501 の通り merge するしかないんじゃね？
git なら rebase するところのような気がする。
  d-e
/
a-b-c
を
        d'-e'
       /
a-b-c
にするのが rebase

504 ：デフォルトの名無しさん：2009/12/19(土) 02:33:14

>>500
svnだとやっぱり>>501が言うように相方がこまめにtrunkをbranchへマージするしかないと思う。
何にせよtrunk追従は相方側の責任になるので自分（trunk保守側）がやれることはあんまりないかと。
新規開発みたいなbranchの作業が絶対にコンフリクト起きないようなものなら、
branchが落ち着いたあと一気にtrunkへmergeするってのも手といえば手かもしれない。

>>503
まさにgit rebaseの面目躍如ってシチュエーションだな。

505 ：デフォルトの名無しさん：2009/12/19(土) 03:33:37

新機能を開発するbranchにtrunk(master)の変更をmergeするのって
Gitなんかだと御法度なんだけどな
新機能を追加するbranchには新機能以外のノイズを入れないのが正しいと思うが。

Subversionではtrunkの変更を新機能branchへマージして
その後、新機能branchをtrunkへマージするとどうなるの？
trunkの変更分が2重に適用されたりする？

506 ：デフォルトの名無しさん：2009/12/19(土) 03:39:06

試したことないから知らんが、500GBもあるとハッシュ値とってリポジトリと
比較するだけでも膨大な処理が必要になるし使い物にならないんじゃね？

まずはバージョン管理する必要のあるファイルとないファイルに分離するといいと思う。
まさかソースコードが500GBあるわけないし

507 ：デフォルトの名無しさん：2009/12/19(土) 09:03:27

>>505
そんなルール聞いたことないが。
Junioが言ったのか？

508 ：デフォルトの名無しさん：2009/12/19(土) 09:18:11

>505
>新機能を開発するbranchにtrunk(master)の変更をmergeするのって
>Gitなんかだと御法度なんだけどな
Git だと branch や merge の手間が小さいし、分散だとなるだけ独立した形で新機能を
作っとくと色々なところで merge も管理もしやすくなって意義があるんだろう。

Subversion とかだと常に feature branch を切るって運用はあまりされなくて、
複数の branch で並行して開発が進められて、時たまクロスで merge されるという運用は
結構ある気がする。Git 本でも Subvesrion を使ってた人は御法度をよくやるが、みたいな
書き方だったような。

Subvesion book の例だと
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.stayinsync
branch に trunk から複数回 merge して最後に trunk に merge し直してる。
trunk に merge し直す際に --reintegrate オプションを付けると >505 の二重適用を避けようとするみたい。
ただし、--reintegrate 使うとその先 branch が使えないらしいので再度 branch を作れということみたい。
--reintegrate なんてオプション知らなかったよ。

509 ：デフォルトの名無しさん：2009/12/19(土) 16:10:44

>>500
ブランチの再統合の事かな。？
>>508と同じ操作だと思うけどtortoiseSVNの場合、その長いブランチにはtrunkから何度でも「リビジョンの範囲をマージ」でマージができるのでtrunkに追従できる。
そして、trunkからマージしてしまったブランチをtrunkにマージしたいときは「ブランチの再統合」でtrunkに１回だけマージできる。
そのブランチの変更はすべてとtrunkに含まれるのでブランチは削除できる。というか、２度とマージができないブランチになるのですぐに消そう。

練習してから試してみよう。

510 ：デフォルトの名無しさん：2009/12/20(日) 06:15:59

>>507
ほかの方が回答してくれていますがJunio本に、そんなことが書かれてた。

個人的には、きっちり理想的な使い方を常にできるかというと
難しい気もするが。

> trunk に merge し直す際に --reintegrate オプションを付けると >505 の二重適用を避けようとするみたい。
> ただし、--reintegrate 使うとその先 branch が使えないらしいので再度 branch を作れということみたい。
> --reintegrate なんてオプション知らなかったよ。

Subversionのmergeは制約が多くて面倒ですね・・
まあ、mergeが終わった時点でそのbranchが不要になる使い方なら
全然問題なさそうですけど。

511 ：500：2009/12/20(日) 09:27:03

>>501-510
うおお、皆さんありがとうございます！
参考になりました。聞いてみるものですね。

ぜひ試してみます。
Subversion bookのも読んでみます。
--reintegrate てTortoiseSVNでもできるかな・・・。て調べたら確かにブランチの再統合ていうやつなんですね。

512 ：500：2009/12/20(日) 09:29:41

あれもしかして、Merge trackingが必要？ということは1.5のリポジトリじゃないと駄目？
svn mergeinfo
http://www.asahi-net.or.jp/~iu9m-tcym/svndoc/svn_mergeinfo.html

リポジトリ1.4のままなので変換しないといけないな…

513 ：デフォルトの名無しさん：2009/12/20(日) 12:21:18

>>512
本家の表の「Merge tracking」を見る限り、そうみたいだね。
ttp://subversion.tigris.org/svn_1.5_releasenotes.html#compatibility

514 ：デフォルトの名無しさん：2009/12/20(日) 13:38:52

>>512
マージをよく使うなら1.5のほうがいいと思うよ。merge trackingだけならリポジトリのアップグレードはsvnadminで一瞬で終わる。

515 ：デフォルトの名無しさん：2009/12/20(日) 13:39:54

いまからアップグレードするなら 1.6 だろ。

516 ：デフォルトの名無しさん：2009/12/20(日) 13:40:28

そだねw

517 ：デフォルトの名無しさん：2009/12/20(日) 13:53:32

bzr-svnが1.6だと使えない罠

518 ：デフォルトの名無しさん：2009/12/20(日) 20:31:24

>>512
svnmerge.pyを使え

519 ：デフォルトの名無しさん：2009/12/21(月) 11:03:03

Subversion の 1.6.5 はマージが微妙に怪しいような気がする。
1.6.6 は試してない。

git だと、オレブランチを持って、基本的にそこで開発。
みたいなのは御法度なのかしら?

520 ：デフォルトの名無しさん：2009/12/21(月) 21:52:02

>>519
gitだとそれが基本というかそれしか出来ない。
Subversionのマージトラッキングは調子どうなんだろう？
それ以前のマージは貧弱すぎてかなり疲労したが。。。

521 ：デフォルトの名無しさん：2009/12/23(水) 09:02:28

>>520
調子いいよ

522 ：デフォルトの名無しさん：2009/12/23(水) 12:13:17

>>520
Subversionのマージトラッキングは自動でマージするリビジョンを判断してくれるからかなり快適。

523 ：デフォルトの名無しさん：2009/12/23(水) 13:25:22

Subversionの1.4から1.5にリポジトリにアップグレードしたいのですが、
svnadmin upgrade でも問題ないでしょうか？
どれもリビジョンは200くらいの小さなプロジェクトばかりです。

524 ：デフォルトの名無しさん：2009/12/23(水) 13:41:08

>>523
アップグレードの目的による。
ほんとうにバージョンを上げたいだけなら svnadmin upgrade が早くていいかもしれない。

525 ：デフォルトの名無しさん：2009/12/23(水) 13:47:45

>>523
upgradeだとリビジョンを1000ごとにフォルダーにまとめる変換がされない。
マージトラッキングが欲しいだけで気にしないならupgradeでOK。

526 ：デフォルトの名無しさん：2009/12/23(水) 19:15:43

質問。git add でバイナリファイルを追加するときって、何かオプションいる？

527 ：デフォルトの名無しさん：2009/12/23(水) 19:26:39

それタイプして質問する間にググれ馬鹿

528 ：523：2009/12/23(水) 21:47:39

サンクソ
新機能使いたいだけなのでupgradeでいってみます。

ふと聞くのですが、後から1000ごとにフォルダーわけして欲しかったら、
変換後にあとでdump/loadしても間に合う(というか分けてくれる)もんでしょうか？

529 ：デフォルトの名無しさん：2009/12/23(水) 22:45:37

>>527
ググってもよくわかんなかったんだよね。いるならいるって書くだろうけど、いらなきゃ書かないかもと思ってオプションなしで試してみたら、うまくいったみたい。

530 ：デフォルトの名無しさん：2009/12/24(木) 01:21:12

>>528
後からできるよ

531 ：523：2009/12/24(木) 10:46:36

>>530
ありがとう。これでこころおきなくupgradeできる。

532 ：デフォルトの名無しさん：2009/12/24(木) 20:09:18

皆さん仕事で使ってる人なんですか？
個人で使うぶんには、バックアップ代りみたいなもんですよね。

533 ：デフォルトの名無しさん：2009/12/24(木) 20:36:22

>>532
改良したつもりがおかしくなった、みたいなときに原因を探るとか。

534 ：デフォルトの名無しさん：2009/12/24(木) 21:01:25

最初の「ひとまず完成バージョン」を作るまではたしかにバックアップみたいな
感じだけど、そこから使いながら機能追加やらコードのクリーンアップとかする
場合には手放せないな。

自分だけかもしれないけど、自分しか使わないコードだとクリーンアップとか
言いながら安易に変更してよく壊すしｗｗｗ

535 ：デフォルトの名無しさん：2009/12/25(金) 00:31:01

>>532
プログラムを改造したりするときに、いつでも昔のバージョンに戻せるのは心強いぞ。

536 ：デフォルトの名無しさん：2009/12/25(金) 02:04:33

コミットを小さな作業単位として考えると、ダラダラと変更を続けてしまって
「さっきは動いてたのに・・・」みたいな状況に陥らなくなったよ。
仕事でも趣味でも重宝してる。

537 ：デフォルトの名無しさん：2009/12/25(金) 08:39:10

gitはインデックスがあるからさらに良いぞ。

たぶん人によっていろんな使い方が出来ると思うけど、
例えば、ソース編集→コンパイル→動かす→修正→コミットって感じなら、
まずコンパイルが通った時点で全部インデックスに突っ込んでおく。
そうするとその後、コンパイル通過後にやった差分、前回コミットから今の差分、
両方個別に確認しながら作業ができる。
コンパイル成功後にいじりすぎてぶっ壊し状態になってしまい、
「俺はいったいなにをやってこうなってしまったんだ、ついさっきまでは
いい感じでいけそうだったのに。。。」ってなった時に助かる。

あとけっこう沢山のファイルを触らないといけない場合、コミットの時にまとめて
分散した差分を確認するのは骨が折れるので、ちょっとずつ差分を追い出してく
感覚で使えるのもいい感じだ。

538 ：デフォルトの名無しさん：2009/12/25(金) 13:58:55

俺は年賀状ソフトの宛名データすらバージョン管理してる。

539 ：デフォルトの名無しさん：2009/12/25(金) 14:16:01

データベース使ってないの？

540 ：538：2009/12/25(金) 14:31:09

>>539
具体的には「筆まめ」を使っているけれど、
宛名データのファイル（*.fwa）をそのままバージョン管理に突っ込んでる。
いつでも過去に戻れる安心感から、宛名を心置きなく修正したり削除したりできるようになった。

541 ：デフォルトの名無しさん：2009/12/25(金) 15:00:36

*fwaが何者なのかわからないけど、斬新すぎて衝撃を受けた

542 ：デフォルトの名無しさん：2009/12/25(金) 15:59:39

>>541
何が斬新なんだ？
管理するファイル形式に縛りはないんだから、別に何を監理してもいいんだぜ？

543 ：デフォルトの名無しさん：2009/12/25(金) 18:04:51

Accessの .mdb ファイルをそのまま VSS へ突っ込むような感じか。

544 ：541：2009/12/25(金) 18:18:19

>>543
そうそう。まさにそれ。

545 ：デフォルトの名無しさん：2009/12/25(金) 20:41:56

まぁ普通にバイナリファイルだろうとなんだろうとHgで使ってるけどね。
ただ、マージとか発生するとおかしな状況が生み出されて困る

546 ：デフォルトの名無しさん：2009/12/25(金) 21:34:56

たまに設定ふっとぶとか、設定いじったら動かなくなったことがあるフリーソフトはexeとか関係なくバージョン管理に突っ込んでるｗ

547 ：デフォルトの名無しさん：2009/12/25(金) 21:51:13

>>532
github使ってるよ。
他人のオープンソースなライブラリとか、バグ直して本家に反映してもらったりとかが
gitの仕組みとwebサービスのサポートがあって簡単にできる。
もうバージョン管理はそれ単体(ソフトだけでってこと)で語れないと思う。

548 ：デフォルトの名無しさん：2009/12/25(金) 21:52:44

> もうバージョン管理はそれ単体(ソフトだけでってこと)で語れないと思う
ちょっと嫌味な言い方で書いてしまったんだけど、
ようするにバージョン管理＝ソフトだけってことはないよってことです。
githubみたいにオープンソースのインフラになりうるサポートするwebサービスもあるのでってことです。

549 ：デフォルトの名無しさん：2009/12/29(火) 23:07:27

いまさら感あふれるニュースだが

GNU Emacs、CVSからBazaarに「スイッチ」 - スラッシュドット・ジャパン
http://slashdot.jp/developers/article.pl?sid=09/12/29/0621224

550 ：デフォルトの名無しさん：2010/01/08(金) 02:07:13

一方 Vim は Mercurial へ

551 ：デフォルトの名無しさん：2010/01/08(金) 17:54:38

このスレの総意はMercurialってことでよろしく。

552 ：デフォルトの名無しさん：2010/01/08(金) 18:15:38

やかましい

553 ：デフォルトの名無しさん：2010/01/09(土) 16:05:21

>>551
誰が総意をまとめろと言った。
このスレのいいところは様々なSCMについて横断的な情報が集まるところだぞ。

554 ：デフォルトの名無しさん：2010/01/09(土) 19:19:57

ところで Software Configuration Management System なのに
SCMS じゃなくて SCM なのはなぜなん？

555 ：デフォルトの名無しさん：2010/01/09(土) 19:36:08

DOSの拡張子が3文字だから

556 ：デフォルトの名無しさん：2010/01/09(土) 19:40:32

>>554
お前にとって最後のSystemはそんなに重要なのか？

557 ：デフォルトの名無しさん：2010/01/09(土) 19:56:39

>>555
納得した！
考えてみれば当然の事やんな。

558 ：デフォルトの名無しさん：2010/01/09(土) 20:13:10

VSS以外で、VSSで言うところの「ファイル共有」機能が実装されているバージョン管理システムはありますか？

559 ：デフォルトの名無しさん：2010/01/09(土) 23:52:48

>>558 昔は俺もVSS使いでした。
Subversion/TortoiseSVNではexternalsが良く似た機能になる。VSSは完全に共有になるが、externalsは参照になる。
違いは、VSSは単純に共有になるので参照元のような概念が無くて平等なので、変更箇所が他の共有先に意図せず反映されてはまることがある。
externalsはtagバージョンで参照させれば、参照元のバージョンを管理できたり、参照しているライブラリを間違えてコミット使用としたときに警告を出させたりできる。

560 ：デフォルトの名無しさん：2010/01/10(日) 01:05:30

>>559
なるほど、似たようなのがあるんだね。

5年ほど前にCVS使った時はvファイルのシンボリックリンク張って
無理矢理対応したりしてたけど。
やっぱ不満が出てたんだね。時代は廻るものですな。

561 ：デフォルトの名無しさん：2010/01/14(木) 21:23:04

>>532
やね氏はsvnとか使わずにwinrarで圧縮してftpでどっかにうｐするだけらしい。
エロいPGでも個人じゃ不可欠ってわけでもないのか。

自分は二か所にチェックアウトして日常の細かい修正用と冒険用に分けるのが便利で一応使ってるけど。
trunk, tags, branchなんて面倒だからやってない。
仮にtagsにバージョン切ってもライブラリ側との整合性が取れないから
雑な運用じゃ古いバージョンのビルドなんてほとんど不可能だな…

562 ：デフォルトの名無しさん：2010/01/14(木) 21:59:47

svnはtagとbranchがふざけてんの？って言いたくなる形式だから、
既存のプロジェクトがsvn使ってるから以外の理由で使う気にならない

563 ：デフォルトの名無しさん：2010/01/14(木) 22:23:16

別にsvnでも全然困ってないぜ

564 ：デフォルトの名無しさん：2010/01/14(木) 22:27:16

チェックアウトして修正したまま1週間以上放置してあるファイルがあったら
幼女が怒ってくれる転覆MODが欲しい今日この頃

565 ：デフォルトの名無しさん：2010/01/14(木) 22:56:05

subversionは .svn フォルダがあちこちに出来るから嫌い

566 ：デフォルトの名無しさん：2010/01/14(木) 23:02:27

>>561
VCSは個人がバラバラに持ってた管理ノウハウをシステム化したって色が濃いツール。
そもそも昔はVCSなしでなんでも管理してたわけだし、経験のある人ほど冗長性だとか
スナップショットだとか、VCSが確保してくれるものを自分のやり方でやれていて
必要性が感じられないんだと思う。

567 ：デフォルトの名無しさん：2010/01/15(金) 21:07:27

そういうこと言うと、スーパーハカー気取りの素人が
「バージョン管理なんて素人のやることさ！」とか思い込むからやめてくれ。
ノウハウがソフトウェアとして定型化・自動化されたことのメリットはやはり大きいわけだし。

568 ：デフォルトの名無しさん：2010/01/15(金) 21:33:22

個人的に使うなら何でもいいけど
共同作業するためにはシステム化する必要があると思う

569 ：デフォルトの名無しさん：2010/01/16(土) 09:03:07

>>567
ハカー気取りなら、Linusが1週間プロトタイプ作ったうんぬんsvnはクソだ！とか言い出してgit使うだろJK

570 ：デフォルトの名無しさん：2010/01/17(日) 21:15:23

Linusを信奉しちゃうあたりがハカー「気取り」にすぎないって話ですね

571 ：デフォルトの名無しさん：2010/01/17(日) 21:30:16

そうだねー、真のハカーはBSDだよねー

572 ：デフォルトの名無しさん：2010/01/17(日) 21:31:52

夏真っ盛り

573 ：デフォルトの名無しさん：2010/01/17(日) 22:18:22

南半球在住ですか。

574 ：デフォルトの名無しさん：2010/01/17(日) 23:10:58

まあ、linuxのコードでlinusの書いた部分を少しでも読んでりゃ、あれっと思うわな

575 ：デフォルトの名無しさん：2010/01/18(月) 02:19:58

どう思うの？
あまり良くない設計だったり？

576 ：デフォルトの名無しさん：2010/01/18(月) 15:44:22

linuxはどうかしらんが、GitのCUIはクソ

577 ：デフォルトの名無しさん：2010/01/18(月) 15:48:02

で、クソじゃないのはTortoiseSVN

578 ：デフォルトの名無しさん：2010/01/18(月) 16:19:55

なんでもGUIにしてもらわないと使えないとは...

579 ：デフォルトの名無しさん：2010/01/18(月) 18:08:55

>>578
＞使えない
と、誰が言ったのか？

580 ：デフォルトの名無しさん：2010/01/18(月) 20:20:58

GitのCUIはLinusじゃないんだが。。。

581 ：デフォルトの名無しさん：2010/01/18(月) 20:29:36

linusのオリジナルだとハッシュ値を直接登録とかだからもっとひどい

582 ：デフォルトの名無しさん：2010/01/18(月) 20:37:32

このスレの総意はMercurialってことでよろしく。

583 ：デフォルトの名無しさん：2010/01/19(火) 00:04:29

gitはnativeな操作だけ用意して、インターフェイスはそれらを組み合わせて作られてきたもの。
だから直接登録でも問題ない。

584 ：デフォルトの名無しさん：2010/01/19(火) 01:32:32

Linusは自分のことが分かってて、ユーザインタフェースは俺にはムリだからって他の人に頼んだ。
Gitの内部設計は斬新でカッコイイよ。

585 ：デフォルトの名無しさん：2010/01/19(火) 04:20:36

かっこいいが斬新ではないだろう

586 ：デフォルトの名無しさん：2010/01/19(火) 04:41:48

斬新さなどあって無かろうなのだァーッ！

587 ：デフォルトの名無しさん：2010/01/19(火) 05:55:23

>>585
差分取らずにコミットまるごと保存でファイルシステムみたいなリンク構造って
斬新だなーと思ったんだけど、そんなことないのか。

588 ：デフォルトの名無しさん：2010/01/19(火) 13:58:10

>>582
ハゲドウ!!

589 ：デフォルトの名無しさん：2010/01/19(火) 17:43:36

>>587
じゃあ、ファイルシステムをそのまま使えばいいじゃん。
リンクに循環がないわけだし。
圧縮ファイルシステムもあることだし。

590 ：デフォルトの名無しさん：2010/01/19(火) 18:39:41

>>587
つ　CVS -k

だっけか。バイナリのやつ。
最近は使わないから忘れた。

591 ：デフォルトの名無しさん：2010/01/20(水) 00:11:20

>>587
それって履歴の一覧を見るのが大変じゃないの？てか、どんな金持ち

592 ：デフォルトの名無しさん：2010/01/20(水) 18:50:26

>>587
GIT

593 ：デフォルトの名無しさん：2010/01/20(水) 19:44:00

>>592
いや、>>585あたりのがまさにGITの話だから。

594 ：デフォルトの名無しさん：2010/01/20(水) 20:56:57

pdumpfs だって同じだし、構想的には目新しい物ではないな。

595 ：デフォルトの名無しさん：2010/01/21(木) 10:38:38

>>549
GNU って言ったら arch ってのがあったような気がするんだが、
どうなったのだろう...

596 ：デフォルトの名無しさん：2010/01/21(木) 10:48:36

Linusはファイルシステムを書き始めたけど
使い物になりそうにないのでバージョン管理システムにしたてた、ってのが真相。
もし完成してたらbtrfsみたいなのが出来上がっていたかもね。

597 ：デフォルトの名無しさん：2010/01/21(木) 14:33:55

>>596
>Linusはファイルシステムを書き始めたけど
>使い物になりそうにないのでバージョン管理システムにしたてた、ってのが真相。

ソースきぼん

598 ：デフォルトの名無しさん：2010/01/21(木) 17:36:07

windowsのCドライブをUSB HDDにドラックドロップで単純にコピーしたものが
４つぐらいあります。どれも微妙に食い違っててて単純に日付の新しいものに
上書きしただけじゃ、全部最新にはなりません。

多分、目視で１つ１つ違うファイルを確認することになると思うのですが
大部分は同じファイルです

全部のファイルを見るのは嫌なのですが、何かいいツールはないのでしょうか

599 ：デフォルトの名無しさん：2010/01/21(木) 19:54:34

>>598
すれ違い

600 ：デフォルトの名無しさん：2010/01/22(金) 14:56:04

git で、あるコミットだけをパッチの形で取り出すにはどうしたらいいでしょうか。
git format-patchだと、一連のパッチができてしまいます。
そうじゃなくて、指定したコミットだけを取り出すことがしたいです。

601 ：デフォルトの名無しさん：2010/01/22(金) 15:10:44

>>600
git show コミット > hoge.patch

602 ：デフォルトの名無しさん：2010/01/23(土) 11:23:51

>>600
git diff commit^..commit

603 ：デフォルトの名無しさん：2010/01/23(土) 16:22:34

>>598
ファイルごとにMD5でハッシュ値を計算し、比較してみたらいいんじゃないかな。
Rubyだったらこんなかんじのコードで。

## ファイル名: C:¥hoge.rb
require 'digest/md5'
filenames = Dir.glob("**/*") ## ファイル名をすべて列挙
for filename in filenames ## それぞれのファィル名について
　if File.file?(filename) ## それがファイルのときだけ
　　s = File.open(finename, 'rb') {|f| f.read() } ## 中身を読み込んで
　　digest = Digest::MD5.hexdigest(s) ## MD5でハッシュ値を計算し
　　puts("#{filename}¥t#{digest}") ## ファイル名と共に出力する
　end
end

## コマンドプロンプトで
C:¥> cd dir1
C:¥dir1> ruby C:¥hoge.rb > ..¥list1.txt
C:¥dir1> cd ..¥dir2
C:¥dir2> ruby C:¥hoge.rb > ..¥list2.txt
C:¥dir2> cd ..
C:¥> diff list1.txt list2.txt

いや、diffコマンドが使えるなら、diff -r dir1 dir2 でいいのか。

604 ：デフォルトの名無しさん：2010/01/24(日) 07:22:53

gitで複数行のログを一覧表示する方法ってないの？
git log --pretty=format:"%s" ^^HEAD...HEAD
みたいのだと１行目しか表示されません・・・

605 ：デフォルトの名無しさん：2010/01/24(日) 08:41:31

>>604
よくわかんないけどこういうこと？
git log --oneline

606 ：デフォルトの名無しさん：2010/01/24(日) 08:57:59

>>605
fatal: unrecognized argument: --oneline
とか言われる。

607 ：デフォルトの名無しさん：2010/01/24(日) 09:07:03

>>606
うちだとこんな感じになる。
$ git version
git version 1.6.5.6
$ git log --oneline
27b34ed IEマター
133ffa8 起動オプションのGUI
29ccecd bodyのスタイル
62a778b 見た目調整
(略

608 ：デフォルトの名無しさん：2010/01/24(日) 16:20:00

>>607
git古いせいかもバージョンアップしてくるわ

609 ：デフォルトの名無しさん：2010/01/25(月) 00:06:45

うちのgit 1.5.4.3だとgit log --pretty=onelineだな。

610 ：デフォルトの名無しさん：2010/01/26(火) 00:43:52

はい、Mercurialきましたー

米MicrosoftのCodePlex、分散型バージョン管理システム「Mercurial」のサポートを発表
2010年01月25日 11:37AM

　米Microsoftは1月23日、オープンソースのプロジェクトホスティングサービスCodePlexで
分散バージョン管理システム（DVCS）「Mercurial」をサポートすることを発表した。既存
プロジェクトもMercurialに移行できる。

ttp://sourceforge.jp/magazine/10/01/25/0241213

611 ：デフォルトの名無しさん：2010/01/26(火) 22:43:50

TortoiseGit 1.3.2.0出た。日本語言語ファイルもSF.jpに上がってる。
1.2.1.0からアップグレードしようとしたらいろいろ変なことになったので、
アンインストール→ログアウト→ログイン→1.3.2.0インストール
ってやった方がいいと思われ。
個人的には「ログメッセージ表示の際に一番最初のリビジョンが表示されない」というバグが直って嬉しい。

それはそれとして、GitCheetahって何？

612 ：デフォルトの名無しさん：2010/01/26(火) 23:15:21

GitCheetahはmsysGit同梱だった気がする。

たしかGitCheetahの方が先に始まったんだけど、Tortoiseというネームバリューの
せいなのか後発のTortoiseGITが有名になっちゃったという・・・。
TortoiseGITはTortoiseSVNをベースに作ってるけどGitCheetahは違うんかな。

613 ：デフォルトの名無しさん：2010/01/27(水) 21:00:20

>>612
なるほど。GitChiitahの方が先だったのかぁ。

614 ：デフォルトの名無しさん：2010/01/28(木) 15:50:11

微妙に異なる3ファイルの差分を表示してくれるツールってないですか。
TortoiseSVNのDiff, WinMergerでは出来ないっぽいです。

615 ：デフォルトの名無しさん：2010/01/28(木) 16:02:05

diff3

616 ：デフォルトの名無しさん：2010/01/28(木) 16:45:03

KDiff3というGUI版がよさそうな感じです。
ありがとうございます。

617 ：デフォルトの名無しさん：2010/01/28(木) 17:16:43

vimも３ペインできるよ

618 ：デフォルトの名無しさん：2010/01/28(木) 20:20:34

WinMergeもできるよ

619 ：デフォルトの名無しさん：2010/01/29(金) 08:56:24

GoogleもMicrosoftもMercurial採用するみたいだけど、
多言語全然考えないっていう表明なんかね？これは
それとも今後解決するという希望の元になんだろうか？

620 ：デフォルトの名無しさん：2010/01/29(金) 08:57:07

>>614
Windowsならp4mergeはどうかな？p4merge自体はフリーで入手できたはず

621 ：デフォルトの名無しさん：2010/01/29(金) 19:10:20

だからといってBazaar採用するわけにゃいかんだろう

622 ：デフォルトの名無しさん：2010/01/29(金) 20:35:51

>>621
なぜ？GNUだから？

623 ：デフォルトの名無しさん：2010/01/29(金) 20:54:30

Ubuntuの開発元で作ってるから？

624 ：デフォルトの名無しさん：2010/01/29(金) 21:14:04

Mercurialって多言語うんぬんの問題はあるけど、
政治的な立場がわりと中立だから採用しやすいのかなぁ。

そういえばSunが運営してたProject Kenaiが公開停止らしい。

625 ：デフォルトの名無しさん：2010/01/29(金) 23:36:28

このスレの総意はBazaarってことでよろしく

626 ：デフォルトの名無しさん：2010/01/30(土) 01:31:14

ClearCaseがクソらしいというのだけは総意と言える

627 ：デフォルトの名無しさん：2010/01/30(土) 07:27:47

gitで手元でgit init したunkoserviceリポジトリを、
サーバー(ファイル共有でもなんでもいいけど)側に置いておきたいのですが、
どうしたらいいんでしょ。

単純コピーとか、手元からサーバーへcloneとか？

例えば、ファイルサーバー上にうｐしときたい場合はこんなんでよろし？
cd remote-unkoservice
git init

cd unkoservice
git remote add origin /remote/remote-unkoservice/.git
git push origin master

すごい基本的なことなんだけど、こういうちょっとした当たり前の運用tipsはどっかにまとまってないのかな？

628 ：デフォルトの名無しさん：2010/01/30(土) 12:33:08

>>627
http://www8.atwiki.jp/git_jp/pub/git-manual-jp/Documentation/gittutorial.html

629 ：デフォルトの名無しさん：2010/01/31(日) 00:05:05

ウンコサービスっておまえ・・・w

630 ：デフォルトの名無しさん：2010/01/31(日) 02:09:54

unkoをpushしないでください！

631 ：デフォルトの名無しさん：2010/01/31(日) 15:50:03

初心者でVisualSourceSafe2005を使っています。
拡張キーワードの$Histor:$で日本語コメントが10文字程度しか反映されません。
たとえばチェックイン時にコメントで「コメント反映テスト」と入力しても、
Comment:コメント反映　までしか置換されません。

ググってもそれらしい話題にいきつかなかったのですが、どなたかご存知ないでしょうか。

632 ：デフォルトの名無しさん：2010/01/31(日) 16:04:06

>>631
$Histor $

633 ：デフォルトの名無しさん：2010/01/31(日) 16:06:45

>>631 スペースを入れてみたらどう？ >>632はスペースが消されてしまった。
$Histor $

634 ：デフォルトの名無しさん：2010/02/01(月) 15:07:30

趣味グラマなんですけど、今はバージョン番号や日付でフォルダ作って、
丸々バックアップって感じで、バージョン管理しています。
個人用途でもバージョン管理システムを使えばハッピーになれる？

635 ：デフォルトの名無しさん：2010/02/01(月) 15:15:59

なれる。
なんで今まで使ってなかったんだろう、と思うことうけあい。

636 ：デフォルトの名無しさん：2010/02/01(月) 15:49:12

darcs冷遇されすぎ

637 ：デフォルトの名無しさん：2010/02/01(月) 16:36:28

エミュのステートセーブみたいなもんだよ

638 ：デフォルトの名無しさん：2010/02/01(月) 17:38:54

一人で使うならリポジトリって実ファイルと同じディレクトリに.svnrepositoryとか作って格納したほうが幸せに慣れそうな気がしてきた。
もちろんバックアップは別系統できっちりとって。

639 ：デフォルトの名無しさん：2010/02/01(月) 17:43:12

そして HDD あぼーん

640 ：デフォルトの名無しさん：2010/02/01(月) 17:46:43

あ、バックアップはするのか。すまそw

641 ：デフォルトの名無しさん：2010/02/01(月) 18:28:02

>>638
そんなあなたにbzr。

642 ：デフォルトの名無しさん：2010/02/01(月) 21:58:44

>>638
そんなあなたにMercurial。

643 ：デフォルトの名無しさん：2010/02/01(月) 23:45:58

>>638
そんなあなたにRCS。

644 ：デフォルトの名無しさん：2010/02/02(火) 08:53:55

ファイルを以前の版に戻したいけどどの版が目当ての内容なのか判らないって時どうする？

645 ：デフォルトの名無しさん：2010/02/02(火) 09:22:03

>>644
annotate

646 ：デフォルトの名無しさん：2010/02/02(火) 12:46:58

>>644
もちろんコミットメッセージなんかあてにできないんだろうが、
「この処理はいつ消えた？」とかなら Diff していけばわかるだろ。

647 ：デフォルトの名無しさん：2010/02/02(火) 13:00:43

どこの変更が原因でおかしくなったか分からない場合は
確実に動く版と現在の版の間で二分探索。
そのための機能がついてるシステムもあるな。

648 ：デフォルトの名無しさん：2010/02/02(火) 13:06:23

順番にdiffとってそれを1ファイルで表示するって機能でもあればいいのかも

649 ：デフォルトの名無しさん：2010/02/02(火) 13:25:37

TracとかRedmineとかと連携させればできるね

650 ：デフォルトの名無しさん：2010/02/02(火) 14:14:01

>>648
hg log -p filename
のこと?

651 ：デフォルトの名無しさん：2010/02/02(火) 14:54:20

>>646「この処理はいつ消えた？」とかなら Diff していけばわかるだろ。
むかしCVS annotateに行ごとにどのリビジョンで消えるかを出すパッチを書いたことがある。
テストスクリプトを書かないと受け付けてくれなくて、面倒になって捨てた覚えが。

652 ：デフォルトの名無しさん：2010/02/02(火) 14:55:52

>>647
git bisect こないだ初めて使ってみたんだが、
ひどく便利だった。

653 ：デフォルトの名無しさん：2010/02/02(火) 16:25:18

これはひでー

654 ：デフォルトの名無しさん：2010/02/02(火) 16:42:31

分散バージョン管理システムMercurial 1.4.3/TortoiseHg 0.9.3リリース
ttp://sourceforge.jp/magazine/10/02/02/0556226

655 ：デフォルトの名無しさん：2010/02/02(火) 17:54:40

Mercurialはゴミ
日本人に紹介すんな

656 ：デフォルトの名無しさん：2010/02/03(水) 22:25:08

>>655
日本人でなければいいのか？

そういう外国人には何してもいいという考えは、
歴史上数々の国際紛争を引き起こしてきた一因ではないのか？

657 ：デフォルトの名無しさん：2010/02/04(木) 05:05:57

そういうことは学校で議論しようね

658 ：627：2010/02/04(木) 07:51:07

ベアリポジトリを作る方向性にしました。
(source_path) 手元のリポジトリとソース
(dest_path) リポジトリをおいておく先

git clone --bair (source_path) (dest_path)
mv (source_path) (source_path).old
git clone (dest_path)

みたいな感じで無事に手元のをサーバーへおいておけました。
サーバー側へのpushも無事いけました。

このへんとかも参考になりました。
分散型の Web 開発の様相を変える Git
http://www.ibm.com/developerworks/jp/web/library/wa-git/index.html

あまりにも基本的なことを聞いてしまったようで失礼いたしました。
レスくださった方々ありがとうございました。

659 ：デフォルトの名無しさん：2010/02/04(木) 12:06:26

>>656
Mercurialの日本語サポートに難があるから日本語には他のを勧めろという話だよ
外国人を差別していいという話じゃない

660 ：デフォルトの名無しさん：2010/02/04(木) 15:07:01

>>659
難があるなら直せばいいじゃない

661 ：デフォルトの名無しさん：2010/02/04(木) 15:12:06

直してから薦めればいいじゃない

662 ：634：2010/02/04(木) 15:27:07

>>635
ありがとう。使ってみます。
Mercurial使ってみようかと思ったんですが、
ゴミとか言ってる人がいるんで、gitかbazaar使ってみます。

663 ：デフォルトの名無しさん：2010/02/04(木) 16:11:40

>>660
パッチがMercurialのMLに送られていたので wktk しながら見守っていたら、
「ファイル名はバイト列なんじゃい」と突き返されていたのを見て、
Bazaar に乗り換えました。

664 ：デフォルトの名無しさん：2010/02/04(木) 16:23:44

まぁ仕事では使えんわな

665 ：デフォルトの名無しさん：2010/02/04(木) 17:02:25

日本人の水銀に対するアレルギーは異常
いつまで引きずってるんだよ

666 ：デフォルトの名無しさん：2010/02/04(木) 17:18:07

日本語に難がないのってBazaarだけじゃないの？
でもBzrってうんこじゃね

667 ：デフォルトの名無しさん：2010/02/04(木) 17:40:30

>>663
勝手に日本語版を作ればいいじゃない

668 ：デフォルトの名無しさん：2010/02/04(木) 19:33:45

bzrは何でもできるようにしたいって姿勢はわかるけど、なんか現時点で揃ってる機能のバランスが悪い

669 ：デフォルトの名無しさん：2010/02/04(木) 20:48:09

>>668
なにが足りてなかったっけ?

670 ：デフォルトの名無しさん：2010/02/04(木) 22:16:05

>>667
すっごい基本的な部分が変更されるから、いろんなプラグインや
外部ツールが動かなくなるのに？

>>666
どこがうんこ？

671 ：デフォルトの名無しさん：2010/02/04(木) 22:42:29

名前が挙がるたびに即否定されるBazaar……

真っ当な理由のついてるレスを見たことがないんだが

672 ：デフォルトの名無しさん：2010/02/04(木) 23:19:29

>>671
svkみたいなところ

673 ：デフォルトの名無しさん：2010/02/04(木) 23:30:29

SVNから移行するには一番受け入れ易いんじゃないかな？Bazaar
ただgitやhgからならシンプルさ故に物足りない感じもするBazaar
現在絶賛拡張中でもあるし、特にgitやhg由来の機能についてはUIが
まだまだこれからという感じ。
ただgitやhgを使っている人でBazaarに期待を寄せている人も少なからず
いるということの裏返しとも言える。

674 ：デフォルトの名無しさん：2010/02/04(木) 23:31:22

とはいえ日本語まともに使いたいとbazaarなんだよなぁ

675 ：デフォルトの名無しさん：2010/02/04(木) 23:33:03

>>670
そうなの? Linuxでは問題なく使えているから、Windowsでもファイル名扱うと
ころだけ直せばいいんじゃないの。Pythonなおしたほうが早いのかもしれんが

676 ：デフォルトの名無しさん：2010/02/04(木) 23:37:10

Windowsって本当に国毎に違うからな
unicode使ってるアプリでも他言語じゃ動かなくなることもあるし

677 ：デフォルトの名無しさん：2010/02/04(木) 23:51:59

>>675
Pythonの問題じゃなくて完全にMercurialの設計思想の問題。
Python は Unicode でのファイルアクセスを許可しているし、
現にBazaarはファイル名をUnicodeで扱っている。

Linux で問題なく使えているのは、そのリポジトリにアクセスしているのが
全員 locale=utf-8 だからだよね？
一人でも euc の人が混じると、誰かのファイル名が文字化けする。

678 ：デフォルトの名無しさん：2010/02/04(木) 23:59:51

>>677
そう、全員utf-8だからだね。
つまりhg専用のpython-jpを用意して、バイナリファイル名でのアクセスを勝
手にUnicodeでのファイルアクセスに置き換えるようにすればいいんだな。

679 ：デフォルトの名無しさん：2010/02/05(金) 00:12:46

結局、あーだこーだといろいろ考えるよりも、ポッとインストールして
気軽に日本語が使える Bazaar が好きです。

680 ：デフォルトの名無しさん：2010/02/05(金) 00:19:23

TortoiseBzrもだいぶ機能が入ってきたしね。
コミットメッセージの改行問題は地味に痛いが

681 ：デフォルトの名無しさん：2010/02/05(金) 01:05:35

svnで何も困ってない　　けど
こんなにsvnが話題にならないってことは
きっと他のは凄いんだろうな
svnとCVSとRCSしか使ったこと無いからよく分からんけど

RCSはローカルのWindowsマシンでちょっとファイルを編集するときに未だに使ってる

682 ：デフォルトの名無しさん：2010/02/05(金) 01:14:41

svnは機能的にも実装的にも安定し過ぎててあまり話す事がない。
専用スレもあるし。

683 ：デフォルトの名無しさん：2010/02/05(金) 07:55:00

svnはテメエで trunk/ tags/ branches/ を作れっていう考えなのが嫌い
内部の実装はそれでもいいけど、ユーザにそれを見せるなって思う

684 ：デフォルトの名無しさん：2010/02/05(金) 08:01:56

>>669
今のbzrにはもうgit branchとかhg branch相当の機能って入ってる？

685 ：デフォルトの名無しさん：2010/02/05(金) 12:07:09

>>681-682
仕事で少人数でTortoiseSVN開発してるけど、
ちょっとしたことでうちで開発したくなった時以外、あまり困ったことない。

gitとかも憶えようと使っているけどsvnで困ってないのはgitをまだ全然理解できてないせいだと思うけどｗ

>>684
マジか、bzrってbranchないのかよ！どうやって枝分かれして開発寸の？毎回リポジトリcloneすんのかな？

686 ：デフォルトの名無しさん：2010/02/05(金) 12:08:02

x うちで開発したくなった時
o 家で開発したくなった時

紛らわしかったすまそ

687 ：デフォルトの名無しさん：2010/02/05(金) 12:15:54

>>685
いや、普通にbranchあるよ。
git や hg に比べると、操作の主体がリポジトリじゃなくてブランチになってるから
移行組には判りにくいだけ。
むしろ、初心者にとってはディレクトリパスやURLが直接ブランチを指すのは
判りやすいんじゃないかな。

>>684
今はまだプラグイン。

688 ：デフォルトの名無しさん：2010/02/05(金) 12:17:32

人数が多くなってくると分散型でもないと気軽にbranchとか作れないからな

689 ：デフォルトの名無しさん：2010/02/05(金) 12:43:13

フレームワーク型のプロジェクトで、
プロジェクトのルートディレクトリ以下は公式からもらってくるupdateオンリーで、
そのサブディレクトリ以下に手元で更新するファイルを独自に管理したいんだけど、
こういうのができるバージョン管理システムってあるのかな。
Subversionではうまくいかないみたい。

690 ：デフォルトの名無しさん：2010/02/05(金) 13:19:25

>>689
Bazaar の scmproj プラグインでできると思う。
scmproj プラグインは、Bazaar以外のVCSとも連携できる。

691 ：デフォルトの名無しさん：2010/02/05(金) 19:54:10

>>689
boostとか最新版のzipのダウンロードを展開してSubversionにぶち込んでるけど、うまくいかないってどんな風になの？

692 ：デフォルトの名無しさん：2010/02/05(金) 21:18:17

>>690
ども。試してみる。
>>691
大雑把に言えばこんな感じ。
framework/
　/bin
　/usr
　/projects(*)
　/shared
　/plugin
こんな構成でprojects以下を独自に管理したいとき、
別のリポジトリからチェックアウトしたものでサブディレクトリを上書きすると、
ルートディレクトリ（framework）からupdateがかけられない。

693 ：デフォルトの名無しさん：2010/02/05(金) 21:56:35

>>692
チェックアウトしたものを上書きするってことは.svnを上書きしたな。それならupdateできないな。
マージで上書きするか、エクスポートして上書きするほうが良いんじゃないか。

ところで(*)ってファイル名？

694 ：デフォルトの名無しさん：2010/02/05(金) 22:14:53

svn的に言えば、svn:externalsを使うのかな。

/projects を特別扱いするんじゃなくて、逆に
/bin, /usr, /shared, /plugin を他リポジトリから持ってくる。

695 ：デフォルトの名無しさん：2010/02/06(土) 00:32:40

>>687
URLでブランチということはsvnみたいってこと？

696 ：デフォルトの名無しさん：2010/02/06(土) 08:13:17

>>689 じゃないけど、Redmineみたいにフレームワークやアプリの基本ソースが常にアップデートしていく場合、
そのシステムに対する変更をする場合、gitだとうまく管理するにはどうしたらいいのかな？

redmineの公式リリースをredmine_releaseリポジトリで管理して、
そこからcloneしてmy_redmineリポジトリで管理、
my_redmineを自分の好みに弄る。
redmineがバージョンアップしたのでredmine_releaseリポジトリを更新、
my_redmineはredmine_releaseからpull、
という感じですればパッチを適用しつつ、公式に追従できるのかな？

もっとやりやすい方法有る？
branchでもできるのかもしれないのだけどよくわからない・・・。branch間のpullてできるの？
この辺に関連するドキュメントってどこら辺に有りますか？

697 ：デフォルトの名無しさん：2010/02/06(土) 08:30:05

>>696
branch間はmergeじゃないかな。cloneでやってもいいけど。

698 ：デフォルトの名無しさん：2010/02/06(土) 09:55:21

>>696
git remote add origin redmine.gitしてpull
git checkout -b myredmine origin/masterとかして以後はmyredmineブランチで作業しつつ
公式の変更を取り込みたいときはpullなりfetchなりしてorigin/masterをmyredmineにmergeかなあ

699 ：デフォルトの名無しさん：2010/02/06(土) 15:45:15

>>685
cloneする

>>695
branch自体ない

700 ：デフォルトの名無しさん：2010/02/06(土) 16:14:28

>>683
それは強く思う

701 ：デフォルトの名無しさん：2010/02/07(日) 09:44:03

>>699
だからbranchあるって。むしろ今はcloneが無い。
今はcloneコマンドはbranchコマンドのエイリアスになっているけど、
次のバージョンではエイリアスを解除して、さらに次のバージョンでcloneが作られる。

>>699がレポジトリだと思っている物は実際はブランチだから。
hgとgitとはブランチをどう扱うかに違いがあるだけで、ちゃんとブランチはある。
hgやgitと同じ扱い方をする為のプラグインもあるし、将来メインに統合される予定。

>>695
svnと比較すると、 tags/ が各ブランチの中で管理されて、各URLが指すのが
ブランチのみになる。

702 ：デフォルトの名無しさん：2010/02/07(日) 10:05:19

>>697-698
おおそれでいいのか。branchで十分て感じなのね。
やってみるっす！ありがとう。git便利ね！

703 ：デフォルトの名無しさん：2010/02/08(月) 10:48:38

個人開発でよさげなのって何かないすか？

704 ：デフォルトの名無しさん：2010/02/08(月) 11:39:18

rcs
svn file://

705 ：デフォルトの名無しさん：2010/02/08(月) 11:49:50

>>703
WindowsユーザーならTortoiseSVN

706 ：デフォルトの名無しさん：2010/02/08(月) 18:55:38

Subversionを使っててMercurialに乗り換えてしばらくした後、
どうしてもSubversionじゃないといけないプロジェクトで再び使ってみたら
あまりの遅さにビックリした。何をするにも中央リポジトリと通信するから
もうアホみたいに遅い。特にTortoiseSVNと使うと余計遅い。

707 ：デフォルトの名無しさん：2010/02/08(月) 19:06:50

winユーザにはSVNが一番薦めやすいのが現実

708 ：デフォルトの名無しさん：2010/02/08(月) 19:20:08

比喩的な比較。

Bittorrent: Subversion
Winny, Share: Mercurial
WinMX: git

709 ：デフォルトの名無しさん：2010/02/08(月) 19:29:04

どういう要素をどう比較した喩えなのか全然分からん

710 ：デフォルトの名無しさん：2010/02/08(月) 19:40:47

MS-IME: Subversion
一太郎: Mercurial
Google日本語入力: git

711 ：デフォルトの名無しさん：2010/02/08(月) 20:04:09

そういうのいいから

712 ：デフォルトの名無しさん：2010/02/08(月) 21:10:01

TortoiseSVNがあったからここまでバージョン管理が一般化したってのはある。
でももうSubversionはレガシーな気がしてならない。

713 ：デフォルトの名無しさん：2010/02/08(月) 21:14:08

RabbitGitが出たら乗り換える

714 ：デフォルトの名無しさん：2010/02/08(月) 22:26:59

>>713
GitCheetahには期待しないということですね。わかります。

715 ：デフォルトの名無しさん：2010/02/08(月) 23:02:47

gource
http://code.google.com/p/gource/

716 ：デフォルトの名無しさん：2010/02/09(火) 11:51:44

>>710
そんな感じだなｗ
x 一太郎
o ATOK

717 ：デフォルトの名無しさん：2010/02/11(木) 16:09:47

VSSがダメなのってなんで？
VSと連携できるバージョン管理システムって他になんかある？

718 ：デフォルトの名無しさん：2010/02/11(木) 16:16:14

>>717
ダメってことはないよ。ダメだといっている人は
文字コードをうまく扱えない人が多いんだと思う。

719 ：デフォルトの名無しさん：2010/02/11(木) 17:29:52

>>717
プラットフォームが限定されるとかクソ高いとかそんなところだろ。
プロジェクト間でファイルを共有できる機能はいいよねえ。
ほかのツールでも実装されると嬉しいんだがな。

720 ：デフォルトの名無しさん：2010/02/11(木) 17:32:03

チェックアウトしないと編集できない
他の人がチェックアウトしてるとチェックアウトできない
というのは相変わらずなの？

721 ：デフォルトの名無しさん：2010/02/11(木) 17:39:16

>>720
変えることは無いと思う。
一元管理を徹底することが主眼になってるから
その前提を覆す実装は今後もないんじゃないかな。

722 ：デフォルトの名無しさん：2010/02/11(木) 17:39:27

>>717
svnやhg等でもVSに組み込めるよ。

723 ：デフォルトの名無しさん：2010/02/11(木) 18:04:34

>>717
Visual Studioと連携できるのっていうと、
MS謹製なら Visual Studio Team Foundation Server かな。
あれはソース管理だけじゃなくてITS/BTSとか
ビルドサーバとか色々抱き合わせになってるけど。

VS2010が出るタイミングで、MSDN契約者ならタダで使える下位版が
出るって話をどこかで聞いたような覚えがあるような無いような。

724 ：デフォルトの名無しさん：2010/02/11(木) 18:35:28

ビルド作業をサーバー側にやらせないといけないような規模の案件には
あいにくお目にかかったことがないのでどうでもいいっちゃいいな。

725 ：717：2010/02/11(木) 18:44:41

>>718
逆に言うと文字コード周りで不具合があるんでしょうか？
試しに使っている分ではUTF-8で問題なさそうです。

>>719
VSで開発って時点でサブスクリプションに入っているので、その辺はクリアです。

>>720
VSS2005ですが、DB(リポジトリと言うべき？)の設定で変えられます。

>>727
調べてみます。

>>723
だがしかし、サブスクリプションの最上位ではなかったorz

726 ：デフォルトの名無しさん：2010/02/11(木) 20:41:21

>>712
でもまぁ、巷では枯れてから始めて本格的に使い始めるようなところも多いしね。

727 ：デフォルトの名無しさん：2010/02/11(木) 20:57:12

VSからbazaar使う方法ありますか？あれば教えてください。

728 ：デフォルトの名無しさん：2010/02/11(木) 21:00:44

>>727
いちおうプロジェクトはあるみたい
http://wiki.bazaar.canonical.com/VisualStudioIntegration

でも、Visual Studio のアドオンを作るのにも使うにも Standard
以上が必要だから、あんまり開発進んでないと思う。

729 ：デフォルトの名無しさん：2010/02/12(金) 13:59:08

>>725
> >> 720
> VSS2005ですが、DB(リポジトリと言うべき？)の設定で変えられます。

多重チェックアウトのことをいってるなら、VSS の 5 あたりからできてたはず。
それより前のバージョンは知らない。
これ設定できるの知らないやつ結構多いね。
(VSS の)admin 権限で操作すれば、他人のチェックアウトを強引に取り消すこともできるから、
チェックアウトしたまま蒸発したり氏んでしまったりしても大丈夫。
管理者が蒸発したり氏んだりしなければ。

730 ：デフォルトの名無しさん：2010/02/12(金) 14:54:11

チェックアウトしないと編集できないというのが致命的。

731 ：デフォルトの名無しさん：2010/02/12(金) 21:32:23

クリアケースつかえねぇわ

732 ：デフォルトの名無しさん：2010/02/13(土) 11:04:04

>>730
分岐してマージはできるから問題ないけどな。

733 ：デフォルトの名無しさん：2010/02/13(土) 15:03:53

>>683
tool側で何とでもしろ、っていうことじゃないのかな？
例えばSubversiveだったら意識させないような作りになってるけど。

734 ：デフォルトの名無しさん：2010/02/13(土) 16:20:31

>>376
hg は根本解決ができないっていうなら、gitもだよ。
utf-8 cygwin 入れたら使えるのは hg も git も同じ。

hg はcygwin無しでもがんばれば utf-8 化できるけど、そこをがんばれる人材
(PythonでUnicode使いたい人)はbzrを選んじゃう

735 ：デフォルトの名無しさん：2010/02/13(土) 16:22:57

>>683
内部の実装には、trunk/tag/branchesは関係ない。
ただの運用上の指針じゃないか。だたそれに従っておけば、totoisSVNだとtagに変更をコミットしようとしたときに警告が出たりリビジョングラフが分りやすくなったりするメリットはあるね。

736 ：デフォルトの名無しさん：2010/02/13(土) 16:52:05

>>734
根本的、っていうのは>>663みたいなプロジェクトの方針みたいなのも含まれるのかなあ、と。

737 ：デフォルトの名無しさん：2010/02/14(日) 00:18:38

>>683
svnにtag branchなんていらないと言ってるんだからあきらめろ

>>734
branchなくても困らないならbzrでいいんじゃないの?
branchがないと言ったらまたbzr厨が暴れるかwww

738 ：デフォルトの名無しさん：2010/02/14(日) 00:27:18

bzrにbranchが無いとかほざいてる方が頭おかしいと思うが。

739 ：デフォルトの名無しさん：2010/02/14(日) 01:46:22

知ってるつもりって番組あったよな

740 ：デフォルトの名無しさん：2010/02/14(日) 10:30:51

試してガッテンというのもあったな

741 ：デフォルトの名無しさん：2010/02/14(日) 10:38:17

>>738
Bazaar の実装は少し変わってるけど、そこをきちんと説明しないからいけない。

742 ：デフォルトの名無しさん：2010/02/14(日) 10:46:14

>>741
なんでいきなり説明責任を押し付けられるんだよ
ブランチが明示的なディレクトリになっているのなんて、svnも一緒じゃん。変でもなんでもない。
hgやgitと違うからってだけで、ブランチが無いとか決め付けてる>>699がいるから
ブランチあるよと言っただけなのに、なんでbzr厨呼ばわりされなきゃならんのだ。

743 ：デフォルトの名無しさん：2010/02/14(日) 12:48:31

「ブランチ」という名前の何かを作れるということと、
gitみたいな機能や使い勝手を実現していることとは別問題じゃね。

744 ：デフォルトの名無しさん：2010/02/14(日) 12:53:35

>>743
そう。それを >>687 で説明済みなのに、>>695 に対して >>699 みたいな
回答をするアンチがいるだけ。

745 ：デフォルトの名無しさん：2010/02/14(日) 14:31:45

>>742
すまんな、お前に押し付けたつもりはない。Bazaar の説明全般に言えることだ。
だが >>738 の書き方もほめられたもんじゃないがな。

746 ：デフォルトの名無しさん：2010/02/14(日) 15:02:20

>>745
Bazaarの説明全般って、
http://doc.bazaar.canonical.com/bzr.2.0/ja/user-guide/core_concepts.html
http://doc.bazaar.canonical.com/bzr.2.0/ja/user-guide/organizing_your_workspace.html
に十分書いてあると思うけど。

どのVCSを選んでも、ブランチの扱いについてはある程度の勉強が必要。
gitかhgを使ってた人がちょっとbzrを触って今までと同じ使い方ができなかったからって、
「bzrにブランチは無い」なんて間違った情報を書き込み、間違いを指摘されたら
>>737みたいな言い方をするんだ、あきれて >>738 みたいな返し方しかできない。

747 ：デフォルトの名無しさん：2010/02/14(日) 15:45:21

どうでもいい事で引っ張りすぎ

748 ：デフォルトの名無しさん：2010/02/14(日) 16:51:34

頭のおかしなキチガイをのさばらせることの、
どこがどうでもいい事なんだ

749 ：デフォルトの名無しさん：2010/02/14(日) 17:07:15

cvsしか使ったことのない人間に薦めるならgitとbzr、どっちがいい？
どうせ性能は拮抗しているだろうから操作感覚がコンパチな方を教えろ。

750 ：デフォルトの名無しさん：2010/02/14(日) 17:13:09

git

751 ：デフォルトの名無しさん：2010/02/14(日) 17:30:47

cvs からならどっちでもいいんじゃね?
svn からなら bzr だろうけど

752 ：デフォルトの名無しさん：2010/02/14(日) 18:43:38

>>750-751
ありがとう
svnは個人的に思想が嫌いなので、bzrはやめてgitにします。

753 ：デフォルトの名無しさん：2010/02/15(月) 05:51:35

>>752
思想的にはsvnよりかはgitの方が嫌らしいと思うが。

754 ：デフォルトの名無しさん：2010/02/15(月) 07:13:21

いやらしいのが好きです

755 ：デフォルトの名無しさん：2010/02/15(月) 08:19:06

gitなんて使ったらボク妊娠しちゃう；；

756 ：デフォルトの名無しさん：2010/02/15(月) 10:46:42

>>753
どんな風に？

svnはやたらとCVSをディスってて気分が悪くなったものだが

757 ：デフォルトの名無しさん：2010/02/15(月) 10:56:21

CVS はディスられてもしょうがないじゃん。
(歴史的事情とかはあるけどね

git つか Linus の svn へのディスりようも相当だったけれど
これも言われて当然じゃね?

758 ：デフォルトの名無しさん：2010/02/15(月) 17:26:16

そうか・・・gitも悪い子だったか・・・
cvsを使い続けようかな

759 ：デフォルトの名無しさん：2010/02/15(月) 17:32:22

それはないわ

760 ：デフォルトの名無しさん：2010/02/15(月) 17:52:25

困ってなさそうだから
それはそれでいいのでは?

761 ：デフォルトの名無しさん：2010/02/15(月) 22:18:24

>>757
svnはBitKeeperの代替にはなれないのでは

762 ：デフォルトの名無しさん：2010/02/15(月) 22:44:59

しかし現状では安牌と言わざるを得ないのが現実。

763 ：デフォルトの名無しさん：2010/02/15(月) 22:47:20

冷凍庫の中もバージョン管理したいよな・・・
このコロッケはいつのだろうか・・・

764 ：デフォルトの名無しさん：2010/02/15(月) 22:57:18

Linus の批判はもっともな点があると思うけど、
実際問題、ブランチとかマージとかって、みんなそんなに頻繁にやる事なの？
たとえば、非プログラマのユーザに、文書ファイルの管理を
TortoiseSVNでやらせる、みたいなファイル共有+差分バックアップ+α　の機能しか
使わないような分野もけっこうあるのでは？
というか、最終的には全体としてはそういうプログラム開発以外での使用が
大多数を占めて、プログラム開発というのは、特殊な一用途に過ぎなくなる
かもしれない（まあ、こんなことまで考えるのは板違いかもしれんけど。）。

765 ：デフォルトの名無しさん：2010/02/15(月) 23:00:30

>>764
ブランチは結構するかな。
すぐ本家に反映して、ブランチはぶらぶらさせたまま放置するけど。

ハッ！　だからブランチっていうのか！

766 ：デフォルトの名無しさん：2010/02/15(月) 23:28:40

>>764
svnだとめんどくさいんであんまりやらないけど、gitだとまずブランチ切って作業って手順が体に染みついてるなあ。
リモートにpushしないローカルだけのブランチは、なんというか俺の部屋って感じで好き勝手できて気が楽だｗ

767 ：デフォルトの名無しさん：2010/02/15(月) 23:32:16

>>761
今更「なれないのでは」って…
SVNの中の人もとっくの昔に「無理です」って言ってたのに

768 ：デフォルトの名無しさん：2010/02/15(月) 23:44:38

Linusの場合はLinuxの開発フローに対して使えるか使えないかに
最も興味があって、その場合頻繁なマージが容易にできるという
のがキーになる。それだけのことだろう。
一般的にそのようなケースがレアであろうと、彼にとってはどう
でもいいはず。

769 ：デフォルトの名無しさん：2010/02/16(火) 03:00:18

>>746
わかった
bzrにはbranchがあります。
ただしリポジトリに対してlogを見たりtagを打ったりはできませんでいいか？

770 ：デフォルトの名無しさん：2010/02/16(火) 04:55:26

それでもあえてdarcsを使いつづける

771 ：デフォルトの名無しさん：2010/02/16(火) 09:32:01

>>767
Linusの選択基準の想定をしたまでで、指摘されなくても知ってます。

772 ：デフォルトの名無しさん：2010/02/16(火) 09:58:36

>>764
プログラム開発でも、おいらのまわりでは残念だけど一部だけかなぁ、
ブランチとか使ってるのって。

ネット界隈を見てると、みんな使いこなしているように思えるけれどね。

773 ：デフォルトの名無しさん：2010/02/16(火) 11:12:39

>>769
そうですね。bzrではブランチが一連の変更履歴、リポジトリはリビジョンを格納する場所と
明確に分かれているので、 log の対象はブランチになります。
git や hg では、リポジトリに対するログは、リポジトリのデフォルトのブランチに対するログ
ではなくて、リポジトリ内の全ブランチに対するログになるのでしょうか？
bzr では複数ブランチに対するログは qlog などの GUI やプラグインで可能ですが、
標準コマンドでは一つのブランチに対してしかログができませんね。

774 ：デフォルトの名無しさん：2010/02/16(火) 11:17:45

ブランチって切るものだったのか

775 ：デフォルトの名無しさん：2010/02/16(火) 12:38:16

ブランチって食べるものじゃね？

776 ：デフォルトの名無しさん：2010/02/16(火) 12:53:16

uncommit

777 ：デフォルトの名無しさん：2010/02/16(火) 13:10:22

Hgではコミットごとにブランチができる感じ。
マージすればブランチが網の目のようにつながる。
どのリビジョンからも新しいブランチを作れる。

778 ：デフォルトの名無しさん：2010/02/16(火) 13:12:33

どのリビジョンでもいじってコミットすれば新しいブランチができてる
です。

779 ：デフォルトの名無しさん：2010/02/16(火) 13:23:19

>>768
そういう点では、Linux の偉大さを除外して考えると、
自分の業務には使えない・合わない、
みたいな理由で、特定の製品を屑だとかゴミだとか
叩いてる、2ch でよく見かけるアンチ君たちと、
メンタリティ的には変わらないんだよね。

780 ：デフォルトの名無しさん：2010/02/16(火) 16:58:15

Git 1.7.0登場、一部に後方互換性なし
ttp://journal.mycom.co.jp/news/2010/02/16/031/index.html

781 ：デフォルトの名無しさん：2010/02/16(火) 17:14:56

>>779
ゴミばかりだから自分で作る
という所までいかないと

782 ：デフォルトの名無しさん：2010/02/16(火) 17:32:17

>>781
ああそうか、Linus の根本的に違うところはそこか。
どんなにわがままな事いう奴でも、
それを自分で実現しちゃう奴は、けなしようがないもんな。

783 ：デフォルトの名無しさん：2010/02/17(水) 04:04:09

msysGitで早く1.7.0出ないかなー。

784 ：デフォルトの名無しさん：2010/02/17(水) 08:26:55

msys使うのは糞

785 ：デフォルトの名無しさん：2010/02/17(水) 14:42:34

Bazaar 2.1.0リリース
ttp://sourceforge.jp/magazine/10/02/17/0426233

>Bazaar 2.1.0は機能のブラッシュアップとバグフィックスを中心としたリリースで、
>Bazaar 2.0系から機能面での大きな変更は加えられていない。
>主な改善点としては「bzr+ssh://host/?/」といったスタイルでの
>リポジトリ指定に対応したほか、メモリ消費量の削減やWindows環境における
>ワイルドカードを利用したファイル名指定サポートの改善などが挙げられている。

>Bazaar 2.1系では今後バグフィックスのみが行われ、新機能の追加等は
>次期版となるBazaar 2.2系に対してのみ行われる予定だ。

786 ：デフォルトの名無しさん：2010/02/17(水) 16:22:51

ttp://dsas.blog.klab.org/archives/51639672.html
>updateコマンドに-rオプションがつきました。
やっとか。

787 ：デフォルトの名無しさん：2010/02/17(水) 22:32:44

おお、ついに Mercurial を捨てるときが来たか。

788 ：デフォルトの名無しさん：2010/02/18(木) 11:40:38

>>764
仕事がsvnだが一個機能実装するときはまずブランチ切ってるよ。

>>786
指定のリビジョンに更新ができるようになったってことか。ようやくまともに使えるようになるなｗ

789 ：デフォルトの名無しさん：2010/02/18(木) 11:52:39

>>788
実装が終わったらブランチは消してる？そのまま？

790 ：788：2010/02/18(木) 12:18:23

ブランチそのままだわ。普通はtrunkにマージしたら消すもんなのかな？

791 ：788：2010/02/18(木) 12:19:54

当たり前だけどブランチのディレクトリ消しても、リビジョンやコミットの情報は残るんだよね？
過去のを参照できなくなる訳ないよな。見た目上ブランチのディレクトリがないから消したら参照しにくいだけで・・・

792 ：デフォルトの名無しさん：2010/02/18(木) 14:01:33

>>788
> 指定のリビジョンに更新ができるようになったってことか。ようやくまともに使えるようになるなｗ

戻すだけなら revert とかでもできたけどね。

793 ：デフォルトの名無しさん：2010/02/18(木) 16:37:50

外部公開用ファイルと自分の秘密ファイルの混合運用できるのってないの？
公開リポジトリに秘密ソースの痕跡は絶対残したくない

794 ：デフォルトの名無しさん：2010/02/18(木) 18:02:43

>>793
mq

795 ：デフォルトの名無しさん：2010/02/18(木) 18:05:03

>>791
残る。削除したディレクトリと同じ扱い。
削除してないということは、ブランチはみんな別の名前がついてるんだね。

796 ：デフォルトの名無しさん：2010/02/18(木) 18:27:57

>>794
これのこと？
http://d.hatena.ne.jp/dayflower/20090520/1242794877

797 ：デフォルトの名無しさん：2010/02/18(木) 21:29:18

>>796
pbranchとかもあるよ

798 ：methane：2010/02/18(木) 21:33:30

あちゃー、bzr-2.1 で WinMerge とかで日本語ファイル名のdiffを見ようとすると止まる。
qdiff しか使えない。

799 ：デフォルトの名無しさん：2010/02/19(金) 02:25:49

>>793
gitならstgit
あるいはそういうの使わなくても、分散型ならリポジトリ分ければ出来るような。

800 ：788：2010/02/19(金) 09:24:36

>>795
そっかサンクス。消したディレクトリと同じ扱いか、わかりやすいな。
確かにブランチは全部別の名前つけてるねｗ

よく考えたら消したブランチとかの名前もリビジョングラフとか見たらわかるからまあいいのか

801 ：デフォルトの名無しさん：2010/02/21(日) 03:09:21

なぜdarcs使いがあまりいないんだ

802 ：デフォルトの名無しさん：2010/02/21(日) 05:24:47

布教してみてよ

803 ：デフォルトの名無しさん：2010/02/22(月) 00:08:58

Haskellerだからdarcs使ってるが、そうじゃなかったら多分使ってないな

804 ：デフォルトの名無しさん：2010/02/22(月) 17:22:52

ver A-> ver B->ver C
と改良していって
ver Bの変更が気に入らないのでそれを抜かして
ver A -> ver C
にできるのがdarcs

805 ：デフォルトの名無しさん：2010/02/22(月) 20:44:22

>>804
リバースマージ機能？
それだけだと他のVCSに対する優位性が分からないかと…

806 ：デフォルトの名無しさん：2010/02/22(月) 22:38:14

17日(米国時間)にSubversionプロジェクトがApacheプロジェクトのもとでトッププロジェクトとして認定されたと発表されている。

名称が『Subversion』から『Apache Subversion』となるほか、ホームページもhttp://subversion.apache.org/へ変更となる。

Subversionは2009年11月にApacheプロジェクトへ提案されている。4
ヶ月ほどでトップレベルプロジェクトへと昇格したことになる。

SubversionはOSSで開発されているバージョン管理システム。
CVSの問題を解決するべく開発されたシステムで、CVSにおける問題のいくつかが解決している。
操作方法がCVSを踏襲していることからCVSから乗り換えるプロジェクトも多く、発表当時は次期バージョン管理システムとして人気があった。

現在、バージョン管理システムはSubversionではなく、Subversionが抱える問題を解決した新しい分散型のバージョン管理システムGitや
Mercurialなどに人気があり、Subversionから乗り換えるプロジェクトも多い。

http://journal.mycom.co.jp/news/2010/02/22/004/index.html

807 ：デフォルトの名無しさん：2010/02/22(月) 23:07:15

>805
良く分からんけど、最初っから verB が存在しなかったかのように扱えるってことじゃないの？
git なら rebase -i でできると思うけど。

808 ：デフォルトの名無しさん：2010/02/22(月) 23:20:02

svn roadmapの

Long-term Goals

*

hybrid distributed/centralized VC model

ってどゆこと？

809 ：デフォルトの名無しさん：2010/02/22(月) 23:40:59

>>804
たとえば、verBではクリスマスになったらウィンドウを真っ赤にするコードが
入っていて、それを取り除くことが出来るってこと？

810 ：デフォルトの名無しさん：2010/02/22(月) 23:56:34

>>809
うん

811 ：デフォルトの名無しさん：2010/02/23(火) 00:40:55

ver A-> ver B の変更箇所をさらに ver B->ver C でも変更してた場合はどうなるの？
パッチベースでもさすがに ver B をなかったことにはできないと思うんだけど。

812 ：デフォルトの名無しさん：2010/02/23(火) 20:22:24

その場合は競合になるけど？
何が問題？

813 ：デフォルトの名無しさん：2010/02/24(水) 02:01:36

しかし、どうやってver Bを取り除いてるんだ？
行番号の整合性とかどうしてるんだろう
まさかそれ以降のコミットの行番号をすべてずらしてるとか？

814 ：デフォルトの名無しさん：2010/02/24(水) 12:47:02

>>813
行番号の整合性くらいはどうとでもなるでしょw

815 ：デフォルトの名無しさん：2010/02/24(水) 13:00:54

とりあえず同じことはgitでもできるってことでいいのかな?

816 ：デフォルトの名無しさん：2010/02/24(水) 19:22:32

殆どのバージョン管理システムではできるはずだよ。

817 ：デフォルトの名無しさん：2010/02/25(木) 10:11:00

>>816
DAGで合流のところはマージを表しているけど、
unmargeってどう表現するの?
できるっていっても、逆差分だったり履歴の改変だったりしない?

818 ：デフォルトの名無しさん：2010/02/25(木) 10:32:18

「VersionControlTools」
http://martinfowler.com/bliki/VersionControlTools.html

ファウラーたんがClearCaseとTFSにダメ出し。
あと、VSSは論外とか書いてるね。
英語が分からんので、詳しいところまで読めてないけど。

819 ：デフォルトの名無しさん：2010/02/25(木) 18:32:01

>>818
bazaarも論外ですかね？

820 ：デフォルトの名無しさん：2010/02/25(木) 19:06:57

TFSも2010のは気になるんだけどね。
アレと同じ事をOSS組み合わせてやるのも大変かなーと思って。

821 ：デフォルトの名無しさん：2010/02/25(木) 20:03:47

でもお高いんでしょ？

822 ：デフォルトの名無しさん：2010/02/25(木) 20:43:08

>>819
Bazaarの評判は時々聞くが、gitやMercurialほどの頻度でもないから省いた、とある

823 ：デフォルトの名無しさん：2010/02/25(木) 20:52:29

>>818
判断基準が解らないなあ

824 ：デフォルトの名無しさん：2010/02/25(木) 21:09:16

>>821
これを見ると、VS2010 Pro with MSDNを買えば、サーバもCALもついて$1,199(更新$799)。
VS2010での開発もできるし、MSDNもつくし、2008の価格に比べれば導入も現実的な価格じゃないかな。
http://blogs.msdn.com/slange/archive/2010/01/26/it-s-official-vs-2010-branding-pricing.aspx

825 ：デフォルトの名無しさん：2010/02/25(木) 22:02:43

VSSは昔は文字コードおかしいだけでリポジトリ飛んだりとかかなり糞だったけど
今は普通に使えると思う
得にCJK環境においては、ファイル名化けないってだけでもアドバンテージでかい

826 ：デフォルトの名無しさん：2010/02/28(日) 17:32:07

gitみたいな分散型って、
　一人svnで使ってるリポジトリ間でマージやコミットもできる
みたいなノリなの？

827 ：デフォルトの名無しさん：2010/02/28(日) 19:37:57

出張前に、ノートパソコンに出張用svnリポジトリ作って会社svnリポジトリからコピーさせて、帰ってきたら会社のsvnリポジトリにマージさせてるけど、そんな感じなのかな？

828 ：デフォルトの名無しさん：2010/02/28(日) 19:43:07

>>826-827
つ分散バージョン管理入門 (イラスト入り) - tcha.org
http://tcha.org/2010/intro-to-distributed-version-control-illustrated/

829 ：デフォルトの名無しさん：2010/03/03(水) 22:07:27

ソースコード管理システム「Darcs 2.4」リリース
ttp://sourceforge.jp/magazine/10/03/03/0326231

830 ：デフォルトの名無しさん：2010/03/04(木) 01:49:51

今の時代は、ＶＳＳからＳＶＮに移行してるんじゃないの？
悲観的ロックって時代遅れ？

831 ：デフォルトの名無しさん：2010/03/04(木) 02:03:45

>>830
今時svnはないな。CVSのままか、gitに移行してるかの二択だろ。

832 ：デフォルトの名無しさん：2010/03/04(木) 02:24:52

え？

833 ：デフォルトの名無しさん：2010/03/04(木) 05:30:12

gitでgitignoreの書き方がイマイチわからんです。
例えば、cacheディレクトリのdotfile以外(.htaccessとか)を無視するにはどう書けばいいんでしょ
.gitignoreにて、
　cache/
などと指定しておいて、
　git add cache/.htaccess -f
でもまあいいんですが、みなさんこんなことしているのかな、と思いまして。

834 ：833：2010/03/04(木) 06:13:04

cache/*.*
!.htaccess
のように.gitignoreを記述したら上手く行きました。
cache/
!.htaccess
ではダメでした。この辺の違いがイマイチわからんですが、できたのでよしとします。

しかし思うのですがgitでgitignoreを記述した時やファイル含むディレクトリを追加するときに、ただgit statusした場合、
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# cache/
などと表示されcache/以下が結局どうなるか？というのがイマイチわからず、
git add . してgit statusして初めて詳細がわかる、というのはこんなものなのでしょうか？

835 ：デフォルトの名無しさん：2010/03/04(木) 06:51:20

>>834
cache/以下はUntrackedだから、その下がどうなってようと表示する意味もないし、それで合ってるんじゃない？

836 ：デフォルトの名無しさん：2010/03/04(木) 09:11:26

>>831
オプソと非オプソで状況は違う。

プロプライエタリなソフト開発の現場では
リポジトリは開発者個々人のものではなく、会社の資産になるので、
分散型の場合は管理し辛い。

そもそも会社組織つーのはバザールモデルの対極にあるわけだから、
最初から分散型がうまく適合するなんていうところはむしろ稀だと思うよ。

837 ：デフォルトの名無しさん：2010/03/04(木) 14:47:55

Mercurialの一人勝ちだな。Git(笑)
http://www.google.co.jp/trends?q=vss%2Crs%2Ccvs%2Csvn%2Cgit%2Cmercurial&ctab=0&geo=all&date=all&sort=0

838 ：デフォルトの名無しさん：2010/03/04(木) 15:01:12

rsって何?

839 ：デフォルトの名無しさん：2010/03/04(木) 15:13:05

6 つ目以降のキーワードは除外されています

840 ：デフォルトの名無しさん：2010/03/04(木) 16:11:23

http://www.google.co.jp/trends?q=cvs%2Csubversion%2Csvn%2Cgit%2Cmercurial
MercurialよりGitの方が多いですね。
アメリカではCVSが、日本ではSubversion=SVNが主流のようです。

841 ：デフォルトの名無しさん：2010/03/04(木) 21:32:50

CVSって同音異義語が多くね？

842 ：デフォルトの名無しさん：2010/03/04(木) 21:43:30

Mercurialはhgの別名もあるから、キーワードが分散してるかもね。
Subversionよりもsvnの方が多いし、別名がないgitはやや有利か？

843 ：デフォルトの名無しさん：2010/03/04(木) 23:26:33

>>838
ロマサガじゃね

844 ：デフォルトの名無しさん：2010/03/05(金) 00:00:43

>>840
Mercurialハナクソだな

845 ：デフォルトの名無しさん：2010/03/05(金) 00:06:18

SVNったらスロベニアが出てくるぞたくさん
スポーツなんかはみんなSVN表記だしな

846 ：デフォルトの名無しさん：2010/03/05(金) 00:08:37

gitもたくさんあるじゃん
http://en.wikipedia.org/wiki/Git

847 ：デフォルトの名無しさん：2010/03/05(金) 00:09:40

同じ条件で検索しないと
+developerとか+"source code"とか

848 ：デフォルトの名無しさん：2010/03/05(金) 03:31:52

svkだとスロバキアになるのか

849 ：デフォルトの名無しさん：2010/03/05(金) 05:27:15

>>840
CVSってCVS/pharmacyのことだろ？

850 ：デフォルトの名無しさん：2010/03/05(金) 10:37:40

アメリカじゃあんまりCVSとは言わんよ

851 ：デフォルトの名無しさん：2010/03/05(金) 11:38:14

じゃ何と言ってるんだろう？

852 ：デフォルトの名無しさん：2010/03/05(金) 17:05:55

ちょっとした質問。

現在、Subversionからローカルにチェックアウトしたソースがある状態で、
svnリポジトリが閉じた社内LANにあるなどアクセスできない状態で、
ちょっとだけ外で開発したくなった場合、一時的にローカルで分散バージョン管理など使って管理しつつ、
開発した後、パッチ出力して後でsvn側にマージするようなことってできますか？
ちょっとわかりにくいですが。

本当はbzr+svnなりgit+svnなりで最初にsvnリポジトリから分散バージョン管理ソフトで
持ってこれたらよかったんですが、現地で環境整えられなかったので。

853 ：デフォルトの名無しさん：2010/03/05(金) 17:21:25

>>852
> 現在、Subversionからローカルにチェックアウトしたソースがある状態で、
> svnリポジトリが閉じた社内LANにあるなどアクセスできない状態で、
リポジトリにアクセスできない所へは、どうやって持って行ったの？
逆にアクセスできる所へ(更新したディレクトリツリーを)持って行けば
いいんじゃないの？

854 ：デフォルトの名無しさん：2010/03/05(金) 17:53:20

>>853
ありがとう。
ええっと、現在アクセスできないsvnリポジトリから事前にチェックアウトしたソースがあって、
後でアクセスできる場所へ行ってsvnコミットしたいという話です。

ただ、それだとその場所でしか開発しにくいのでどうしたものかと。
都合により内部には鯖たてるのはいいんですが、外部にsshとか公開できないのです。(将来はわかんないけど)

現在ローカルにあるテスト的なソース郡でgit試してたんですが、
(1)ソース変更→gitでコミット→1から繰り返す→(svnコミットできるLAN内に移動)→(2)過去のバージョンにgit checkout→svnコミット→(2)を繰り返す
というのでいけるかな、と。ちょっと不毛な気がしますが。

gitのコミットごとにパッチ作って、svnでコミットできるようになったら、順にパッチを当てる方法も考えました。
ただgit diffでパッチを出力してみて、古いリビジョンにcheckoutで戻してpatchコマンドでパッチあてたり試してたんですが、
テキストの変更はいいのですが、git mvで変更した場合にうまくパッチあてられないですね・・・うーん。

それはそれとして >>852 の様な根本的な問題解決には将来的には多分以下になるかと思います。
その他にも何かよい方法あったら教えて欲しいです。

・外部にVPSとか立てておいてリポジトリそこにおいてsvn
・git-svnとかbzr-svnでsvnリポジトリのまま分散管理で扱う
・分散管理バージョン管理系に移行(git、bzr等)
・VPNでLANないsvn（とかって外部に鯖公開でない状態でできるのか調べてない・・・）

855 ：デフォルトの名無しさん：2010/03/05(金) 17:58:19

>>854 のgit checkoutで編集中に戻れる状況なら、
途中のパッチ作ってパッチあてる方法って意味ないか・・・。

面倒だからさっさと、分散系の環境整えた方がいいな。
日記見たくなってスマソ。

856 ：デフォルトの名無しさん：2010/03/05(金) 18:41:36

>>854
> gitのコミットごとにパッチ作って、svnでコミットできるようになったら、順にパッチを当てる方法も考えました。
> ただgit diffでパッチを出力してみて、古いリビジョンにcheckoutで戻してpatchコマンドでパッチあてたり試してたんですが、
> テキストの変更はいいのですが、git mvで変更した場合にうまくパッチあてられないですね・・・うーん。
hg でもだめだったのでしょうか?

857 ：デフォルトの名無しさん：2010/03/05(金) 18:54:27

# 作業ブランチでの作業を記録
bzr-svn プラグインをオフにしておく
bzr init
bzr ignore .svn
bzr add .
bzr commit -m "initial import"
あとはbzrで作業。

# bzr の cherrypick merge を使って svn に書き戻し
bzr-svn を有効にしておく
bzr branch http://svnブランチのパス/ work
cd work
bzr merge ../作業ブランチ -r1..-1
bzr dpush http://svnブランチのパス/

858 ：デフォルトの名無しさん：2010/03/05(金) 19:03:58

ローカルのリポジトリにはメモ的に細かくコミットして、
共有リポジトリには大きな粒度でまともなコミットログを付けてコミット。
共有リポジトリ見てる同僚には、ローカルリポジトリでやった間抜けな試行錯誤や
ゴミコメントは見られないようにする。

これをMercurialでやろうとすると案外めんどくさいみたいだね。ややこしい。
こういう作業をやりやすいのは、どのバージョン管理システム？

859 ：デフォルトの名無しさん：2010/03/05(金) 19:15:52

>>858
git で rebase -i とか使ってコミットをまとめたり分割したり。

860 ：デフォルトの名無しさん：2010/03/05(金) 19:20:15

>>854
たまにLANにノート持ち込んでそこからならsvn接続出来る、的な感じ
なんでしょ？
なら次に繋げる時にgit-svnすればオールオッケーだと思う。
それまでの分のコミットはこっちに溜めておいても、git-svn init後にrebaseすれば良い。

861 ：デフォルトの名無しさん：2010/03/05(金) 19:35:22

>>857 >>860
bzr-svn、git-svnて後からリポジトリ作っても既存のsvnに突っ込めるんですね。なにそれすごい・・・
やってみます！

>>856
ごめんhgはちょっと・・・

862 ：デフォルトの名無しさん：2010/03/05(金) 21:02:50

>>852
ローカルにSVNリポジトリ作ってそこで作業して、帰社したらマージすればいいし

863 ：デフォルトの名無しさん：2010/03/05(金) 23:54:03

つかbzr,git,hgどれも集中型連携はググれば出てこないか？

864 ：デフォルトの名無しさん：2010/03/06(土) 05:30:23

>>862
一回しかコミットしないとか、何回のコミットを最終的に一回のマージですます、ならいいんだけどね。
複数のコミットを全部順番にマージしたいとかだと面倒だよね

865 ：デフォルトの名無しさん：2010/03/06(土) 05:31:24

>>863
最初に分散型から集中型リポジトリにアクセスしてとってこないとできないと思ってました・・・。

866 ：デフォルトの名無しさん：2010/03/06(土) 06:44:45

>>861
git svn dcommit を後からやるんならちょっと細工というか工夫が必要だけどね。
いろいろなやり方が考えられるけど、ようはsvnから切り離した時点でのコミットの後に
ローカルなコミットが続くような状態になれば、git-svn-idを見て処理してくれるようになるから、
rebase --ontoとかcherry-pickとか使ってそういうブランチを作って、その状態で
git svn rebase、そしてdcommitする。
てか初回はそういう意味で面倒だから、ローカルなのは１つのコミットにまとめてしまって
やったほうが楽だと思うな。

867 ：デフォルトの名無しさん：2010/03/06(土) 11:24:23

>>865
cherrypick merge は本当のマージじゃなくてパッチを順番に当てていく
イメージだから、 >>857 みたいなことができる。
もちろん、最初から bzr-svn, git-svn, hgsubversion でチェックアウトしておいた
方が良いのは変わらないけど。

868 ：デフォルトの名無しさん：2010/03/06(土) 11:50:20

cygwin gitのgitkってUTF-8のテキストファイルも化け化けなんだがなんでだぜ？
gitのせいなのか、gitkのせいなのか、cygwinのせいなのかどこで聞けばいいかわからん。

git version 1.6.6.1 cygwin 1.7

869 ：868：2010/03/06(土) 11:57:25

git config --global gui.encoding utf-8
したら、gitkのdiffは化けなくなった。マルチバイトのファイル名は化け化けだが。これはなんとかならんもんなのかな

870 ：デフォルトの名無しさん：2010/03/06(土) 13:21:01

事務のおねーちゃんが読むExcel本みないなバージョン管理システム本書いてくれよ
「TortoiseSVNでひとりsvn」ぐらいのレベルでさ

いろんなExcelファイルを使ってるから履歴管理させてあげたいんだけど
「リポジトリ」とか、「コミット」とか、説明するのがメンドーなんだよ

871 ：デフォルトの名無しさん：2010/03/06(土) 14:14:13

>>850
http://en.wikipedia.org/wiki/Concurrent_Versions_System

872 ：デフォルトの名無しさん：2010/03/06(土) 15:00:47

>>870
そういうレベルなら、ファイルサーバの共有フォルダに
シャドウコピーの設定をしてるだけで十分な場合が多い。

873 ：デフォルトの名無しさん：2010/03/06(土) 16:37:28

>>870
僕の亀も(ry

874 ：デフォルトの名無しさん：2010/03/06(土) 17:04:25

gitの質問いいでしょうか？

git chekcout HEAD^ した後に、うっかりそこで作業して何度かコミットしまくってしまい、
名無しのブランチ(?)のようなものを作ってしまいました。

変更しているのにgit pushでEverything up-to-dateといわれてようやくこの状態に気づいたのですが、
その後、あわてて、git pullしてgit checkout masterしてしまいました。

名無しのブランチでの作業が、gitkなどで履歴を見てもどこにも見当たらないのですが、
とりだしてmasterにmergeすることってできますでしょうか？
git branchで見てもmasterしか見当たりません。

875 ：デフォルトの名無しさん：2010/03/06(土) 17:25:56

>>870
「できる！Subversion」
全頁フルカラー！豊富な図解で分かりやすい！

みたいな感じ？

876 ：デフォルトの名無しさん：2010/03/06(土) 17:41:13

>>875
フルカラーなはずなんだけど、「TortoiseSVN」ではなくあくまで「Subversion」なので、
ほぼすべてがコンソールのスクリーンショットになってフルカラー涙目な状況。

877 ：874：2010/03/06(土) 17:44:25

解決しますた

$ git fsck --lost-found
して表示できないコミットを表示して、表示されたIDを
$ git log (ID)
で新しいか確認して、
$ git merge (ID)
したらmasterにマージいけました。

878 ：デフォルトの名無しさん：2010/03/06(土) 17:48:24

>>876
viの設定がカラーになってるから見栄えはいい

879 ：デフォルトの名無しさん：2010/03/06(土) 17:50:45

>>878
いや、viの時点でもう初心者向けではないだろう・・・

880 ：デフォルトの名無しさん：2010/03/06(土) 17:56:39

git log -gで、以前にHEADだったコミットが見られるから、必要なコミットを探してチェックアウト。
あらためて名前をつけてブランチにするのがいいと思う。

881 ：デフォルトの名無しさん：2010/03/06(土) 17:57:39

解決してましたね。失礼

882 ：デフォルトの名無しさん：2010/03/06(土) 19:11:23

じゃあvimで
入力モードでもカーソルキー使えるぞ

883 ：デフォルトの名無しさん：2010/03/06(土) 19:34:50

nanoじゃだめなの？

884 ：デフォルトの名無しさん：2010/03/06(土) 20:20:08

表紙は萌えキャラsvnちゃん

885 ：デフォルトの名無しさん：2010/03/06(土) 20:28:03

LinuxじゃなくてWindows向けの解説だからviはないだろ
EDLINじゃね？

886 ：デフォルトの名無しさん：2010/03/07(日) 02:25:19

>>870 いっそ、msofficesvn じゃだめ？
ttp://code.google.com/p/msofficesvn/wiki/Introduction_ja

887 ：デフォルトの名無しさん：2010/03/08(月) 13:30:25

gitって名無しブランチを作れるの?

888 ：デフォルトの名無しさん：2010/03/08(月) 23:08:26

>>887
gitにゃ無理だう！

889 ：デフォルトの名無しさん：2010/03/09(火) 00:16:25

むしろgitは名無しブランチの先に旗立ってる特別な奴が名前付きブランチ

890 ：デフォルトの名無しさん：2010/03/09(火) 03:19:21

>>889
1つの名前つきブランチが枝分かれしているという状況はないってことであってる?
hgだと普通に起こり得るけど。

891 ：デフォルトの名無しさん：2010/03/09(火) 07:57:25

>>890
hgはよくわからないんだが、gitは特定のコミットに名前を付けるとブランチだし、
同じ親を持つコミットが複数あれば枝分かれしてるってことになる。シンプルだと思うが。

892 ：デフォルトの名無しさん：2010/03/09(火) 12:42:55

>>890
gitも基本は同じだが、ブランチの名前をつけずにコミットしたら、そのコミッ
トは別のブランチをcheckoutすると見えなくなるから、名無しのブランチに戻
るにはその時のコミットIDを覚えておいて直接checkoutに指定するしかないら
しい。不便なので普通は名前を付けるんだと思う。

893 ：874：2010/03/10(水) 14:01:43

>>892
俺がついこの前そんな感じになったよｗ

894 ：874：2010/03/11(木) 13:42:32

各分散バージョン管理のかなり詳細な比較記事

InfoQ: 分散バージョン管理システムの詳細なガイド
http://www.infoq.com/jp/articles/dvcs-guide

895 ：デフォルトの名無しさん：2010/03/11(木) 14:35:42

>>894
中身が滅茶苦茶
全く役に立たない

896 ：デフォルトの名無しさん：2010/03/11(木) 15:03:56

>>895
「滅茶苦茶」じゃなくて「ごちゃごちゃ」なだけだろ
ちゃんと読めば役に立つ

897 ：デフォルトの名無しさん：2010/03/11(木) 15:24:10

>>895
どこが間違ってるのかちゃんと書けカス

898 ：methane：2010/03/11(木) 15:38:59

>>897
>>895 じゃないけど、 TortoiseBZR のメンテナをやってます。
去年の1月頃から停滞していたのを、去年の7月頃から私が引き継いだので、現在は
そこらへんの説明無しにTortoiseBZRへのリンクだけ張ってもらえば良い状況ですね。

あと、olieve という GTK系のＧＵIが紹介されていますが、どちらかといえば推奨されて
いるのはQt系のGUIの方で、WindowsにおいてGTKよりも良いルックアンドフィールを
提供しています。

899 ：methane：2010/03/11(木) 15:41:27

Mercurialも、リポジトリフォーマットがNTFS向きじゃないと解説されているけれど、
その後リポジトリフォーマットが変更されたんじゃなかったかな。

良い記事だけど情報が古いので、最新の情報に同じような記事が出ると良いですね。

900 ：デフォルトの名無しさん：2010/03/11(木) 15:53:35

そもそも原文が微妙に古いし(2009/08/19)、評価したバージョンが古すぎ。

> 2008年3月24日にリリースされたMercurial 1.0(Edgy用のIssue 1050パッチを適用)
> 2008年4月8日にリリースされたGit 1.5.5
> 2008年4月10日にリリースされたBazaar 1.3.1

901 ：デフォルトの名無しさん：2010/03/11(木) 16:25:02

tortoiseGitも未リリースだったのか

902 ：874：2010/03/11(木) 23:01:12

>>894
TortoiseHgもUI古いバージョンだな
古い比較記事はるな。氏ねよ

903 ：874：2010/03/11(木) 23:01:59

あ、あ、、、、、

904 ：874：2010/03/11(木) 23:11:27

オッス！オラ874！！

905 ：デフォルトの名無しさん：2010/03/12(金) 22:03:26

>>894 svnについても古くないか？
＞ブランチ間でマージされたリビジョンの追跡を行う必要があります(Subversionにはこのような機能がありません)。
1.5以降でマージ追跡ができるようになってマージが簡単になりました。
＞ファイルやディレクトリの名前が変更されていたら、マージが失敗してしまいます。
普通にできるし

あとの、externals,trunk,branch,tagsとかは好みの問題だろうし。

906 ：デフォルトの名無しさん：2010/03/12(金) 22:49:10

>>894 http://www.infoq.com/jp/articles/dvcs-guide
この記事ダメダメだな。
＞1986年、初めてCVSが使われ、
最初から間違いで始めるなよ、最初は由緒正しきSCCSだろ。

http://ja.wikipedia.org/wiki/Source_Code_Control_System
＞Source Code Control System（SCCS）は、世界初のソースコードバージョン管理システム。
＞1972年、ベル研究所の Marc J. Rochkind が IBM System/370 上の OS/MVT 向けに開発した。

907 ：デフォルトの名無しさん：2010/03/12(金) 23:03:18

SCCSって分散バージョン管理システムだったのか。

908 ：デフォルトの名無しさん：2010/03/12(金) 23:20:42

>>907
該当段落は、分散なしのものから話を始めている。

909 ：デフォルトの名無しさん：2010/03/12(金) 23:28:58

翻訳が駄目だってだけだよ

910 ：デフォルトの名無しさん：2010/03/13(土) 11:39:31

>>905
＞ファイルやディレクトリの名前が変更されていたら、マージが失敗してしまいます。
マジ？
手元のでできないんだがリポジトリ古いせいかな…upgradeするか

911 ：デフォルトの名無しさん：2010/03/13(土) 16:51:11

>>910
http://pc12.2ch.net/test/read.cgi/tech/1254838551/302-

912 ：デフォルトの名無しさん：2010/03/13(土) 18:37:43

>>911
リネームしたほうをAとして、リネーム前に編集したほうをBとしてBをAにマージしたいのか。
もし、うまくいかないのなら、AをBにマージしてBからAにブランチの統合すればよくね？

913 ：デフォルトの名無しさん：2010/03/19(金) 20:20:38

バイナリーファイルも差分で記録してくんないかな
ディスクたりなくなるかもしんないし

914 ：デフォルトの名無しさん：2010/03/19(金) 20:28:10

subversionはバイナリー差分を圧縮してリポジトリに格納する。

915 ：デフォルトの名無しさん：2010/03/19(金) 20:35:00

分散バージョン管理の中でバイナリーの差分とってくれるのは
monotone
だけってことで合ってる?

svnはwordの差分表示するアドオンなんてあるのね

916 ：デフォルトの名無しさん：2010/03/19(金) 21:25:53

winmergeのプラグインにそんなのがあったようななかったような

917 ：デフォルトの名無しさん：2010/03/19(金) 22:29:33

>>915
それは差分表示ソフトの問題であって、
Subversion以降の世代のバージョン管理システムは
バイナリの差分保存はどれもできるはずだ。

918 ：デフォルトの名無しさん：2010/03/20(土) 08:28:26

>>917
そういうことじゃなくて
svnみたいに差分でリポジトリに保存しているって意味では？
hgもgitもbzrも差分では保存してないはずだし

919 ：デフォルトの名無しさん：2010/03/20(土) 08:33:24

他は知らんけどbzrは一応差分。というかリポジトリ内部ではテキストファイルとバイナリファイルを分けてない。

920 ：デフォルトの名無しさん：2010/03/20(土) 09:06:42

bzrは差分だったか、それは失礼した。聞いた情報だけで適当に言ってしまった

921 ：デフォルトの名無しさん：2010/03/20(土) 11:16:12

hgも保存は差分と聞いたけど、バイナリかどうかは知らない。

922 ：デフォルトの名無しさん：2010/03/21(日) 00:42:19

複数の svn リポジトリ間で同期を取る方法って、何か良いの無い？

なんで今の開発環境、svn リポジトリが３本もあるんだろう。
ブランチが３本じゃなくてリポジトリが３本……一体何があったんだろう。

923 ：デフォルトの名無しさん：2010/03/21(日) 01:01:31

>>922
それはSubversionリポジトリの運用概念を理解できてないだけ。
Subversionの世代のリポジトリは、全世界で１個でいい。
git以降の分散系ではまた話が変わってくるだろうが。

924 ：デフォルトの名無しさん：2010/03/21(日) 01:09:48

質問に答えてやれよ

925 ：デフォルトの名無しさん：2010/03/21(日) 01:27:12

リポジトリ自体はSubversionのままで、クライアントをhgに切り替えればいいんじゃね。
ローカルのリポジトリがhgで中央がSubversionなら、適時マージかけて同期していくことは可能。

926 ：デフォルトの名無しさん：2010/03/21(日) 10:15:11

>>922
どういう状況で分かれたのか知らないけど、別のリポジトリのリビジョンの範囲を指定してもマージはできるから、がんばってマージするんだ。
そして運用方法を見直したほうがいいぞ。

927 ：デフォルトの名無しさん：2010/03/22(月) 13:07:48

>>922
一台をマスターにして、それにだけコミットするようにして、残りをスレーブにしてsvnsyncするしかないだろ…。

複数のリポジトリに好き勝手にコミットして同期したいなんて要望はsubversionでは狂気すぎる。

928 ：デフォルトの名無しさん：2010/03/22(月) 14:16:16

>>922
それぞれのレポジトリを別のバージョン管理システムで管理すればおｋ

929 ：釣られてみる：2010/03/22(月) 14:38:14

>>928
それは殆ど無意味。

930 ：デフォルトの名無しさん：2010/03/22(月) 15:12:37

レポジトリ

931 ：デフォルトの名無しさん：2010/03/22(月) 23:30:43

そんなの表記法の違いじゃ

932 ：デフォルトの名無しさん：2010/03/23(火) 00:00:43

realのことレアルって言わないだろ

933 ：デフォルトの名無しさん：2010/03/23(火) 00:04:57

でもmachineをミシンって言ったりするじゃん

934 ：デフォルトの名無しさん：2010/03/23(火) 00:44:55

なに君は江戸時代の感覚を大事にしたいの？

935 ：デフォルトの名無しさん：2010/03/23(火) 00:55:53

>>933 >>934勉強になったｗ

936 ：デフォルトの名無しさん：2010/03/23(火) 08:02:38

reportがレポートだったりリポートだったりするからどうでもいいよ。

937 ：デフォルトの名無しさん：2010/03/23(火) 09:02:42

レーベルのラベルにレッテル貼り

938 ：デフォルトの名無しさん：2010/03/23(火) 10:17:06

フォルダだったのがいつの間にかフォルダーになっちまったしな

939 ：デフォルトの名無しさん：2010/03/23(火) 10:22:17

駅でホームをHomeと書いてあるのを見たときは頭を抱えた。
20年くらい前だが。

940 ：デフォルトの名無しさん：2010/03/23(火) 11:29:24

ぷらっとHome という店は実在する

941 ：デフォルトの名無しさん：2010/03/23(火) 11:53:18

アイロンのこともたまには思い出してあげてください

942 ：デフォルトの名無しさん：2010/03/23(火) 12:46:56

HDDのことをハードと略す一般人は心中許せじ

943 ：デフォルトの名無しさん：2010/03/23(火) 12:51:58

雑談する奴も許せないな

944 ：デフォルトの名無しさん：2010/03/23(火) 15:31:02

USBメモリーがUSBだけで通じる電気店

945 ：デフォルトの名無しさん：2010/03/23(火) 16:33:13

そもそも初期の携帯の略称は携電だった

946 ：デフォルトの名無しさん：2010/03/23(火) 21:24:17

レム文

947 ：デフォルトの名無しさん：2010/03/23(火) 21:36:34

レットしようぜ

948 ：デフォルトの名無しさん：2010/03/24(水) 00:51:08

ちゃー

949 ：デフォルトの名無しさん：2010/03/25(木) 03:07:12

$ svn update -r 929 1255241922.dat
$ svn commit -m "dokkaike" 1255241922.dat

950 ：デフォルトの名無しさん：2010/03/25(木) 08:17:29

ヴァーチャー

951 ：デフォルトの名無しさん：2010/03/25(木) 08:26:06

マイコン→パーコン→パソコン→マイコン

952 ：デフォルトの名無しさん：2010/03/25(木) 08:27:04

ガラパゴスケータイをガラケーと略(ry

953 ：デフォルトの名無しさん：2010/03/27(土) 21:18:15

コンフリクトの自動解消を一番賢くしてくれるのはどれ？

954 ：デフォルトの名無しさん：2010/03/27(土) 22:49:51

コンフリクトを自動で解決してくれるのなんてあったか？

955 ：デフォルトの名無しさん：2010/03/27(土) 22:55:27

そもそもマージ(自動)を捌ききれなかったのがコンフリクトでしょ。

で、コンフリクト解決ツールがいちばん充実してるのは…Tortoiseだったりしてw

956 ：デフォルトの名無しさん：2010/03/28(日) 11:29:01

じゃあ自動マージが一番賢いのはどれ？

957 ：デフォルトの名無しさん：2010/03/28(日) 13:24:22

バカなマージってあるか？
うまくいかないのは、大抵が利用者の理解不足によるミスだが。

958 ：デフォルトの名無しさん：2010/03/28(日) 13:47:31

patchコマンドの不出来によるんじゃないの？

959 ：デフォルトの名無しさん：2010/04/03(土) 00:40:07

リポジトリって1個でよかったのか

トータスSVNの右クリックに「ここにリポジトリ作成」みたいなのがあるから、きがるにプロジェクトごとに作るのかと思ってしまった

複数あると何か問題でもあるの？
個人でローカルで使ってるとそれをzipで固めて保存とかできるから便利かなと思ったけど。

960 ：デフォルトの名無しさん：2010/04/03(土) 00:56:44

>>959
言っておくが、一プロジェクトに一つでいい、ってことだぞ
わかってるな
わかってるよな

961 ：デフォルトの名無しさん：2010/04/03(土) 01:00:48

>>959
それであってると思うよ

>>922は、ひとつのプロジェクトで中央リポジトリがいくつもある、って状態
これはどうしようもない状態

962 ：デフォルトの名無しさん：2010/04/03(土) 01:14:48

>>960
>>961
あ、1プロジェクトに1リポジトリで合ってたのね。良かった
1リポジトリに全プロジェクトに入れるのかと読み間違えた。レスありがとう

ついでに質問だけど、svnってtddな開発スタイルと相性悪いのかな？(頻繁にコミット) tddにもっとも適したバージョン管理ってどれだとおもう？

963 ：デフォルトの名無しさん：2010/04/03(土) 01:31:56

TDD ＝頻繁なコミットってのもどうかと思うが、そう使いたいなら
ローカルコミット（＋あとでその部分を無視）できるシステムが必須だろうね。
分散型ならどれもそう変わらんのでは？

964 ：デフォルトの名無しさん：2010/04/03(土) 11:09:15

>>962
1リポジトリに全プロジェクトを入れるのもアリ。

この場合、各プロジェクトはリポジトリの単なるサブディレクトリ。
/reporoot/project1/trunk, branches, tags
/reporoot/project2/trunk, branches, tags
のようになる。

管理は楽なんだろうけど、リビジョン番号がプロジェクトごとに独立せず、
同一リポジトリ内での通し番号になるのが好かん。

965 ：デフォルトの名無しさん：2010/04/03(土) 13:02:57

>>964
> >>962
> 1リポジトリに全プロジェクトを入れるのもアリ。
>
> この場合、各プロジェクトはリポジトリの単なるサブディレクトリ。
> /reporoot/project1/trunk, branches, tags
> /reporoot/project2/trunk, branches, tags
> のようになる。

ああ、そうか、１リポジトリでまとめる場合各project(サブディレクトリ)毎にtrunk, branches, tagsを持たせればいいのか。

/reporoot/trunk/project1
/reporoot/trunk/project2

ってtrunk(branches, tags)の下にproject**を置いてた

>
> 管理は楽なんだろうけど、リビジョン番号がプロジェクトごとに独立せず、
> 同一リポジトリ内での通し番号になるのが好かん。
>

そうね、TortoiseSVNでリビジョングラフが変になるのが嫌いだ

966 ：デフォルトの名無しさん：2010/04/04(日) 09:45:43

>>961
> >>922は、ひとつのプロジェクトで中央リポジトリがいくつもある、って状態
> これはどうしようもない状態

これをどうにかできるようにしたものが分散型って理解でいいのかな
中央リポジトリでの一元管理って、なんだかんだ言ってかなり有用だよな

967 ：デフォルトの名無しさん：2010/04/04(日) 18:14:19

>>966
違うよ。全然違うよ。

968 ：デフォルトの名無しさん：2010/04/06(火) 14:28:30

今年度は申請書(EXCELシート)書いて上司の判子もらわないと
svn commit すらできない職場で仕事することになりました。
ttp://d.hatena.ne.jp/SiroKuro/20100405/1270460603

969 ：デフォルトの名無しさん：2010/04/06(火) 15:25:51

富士通のとある大規模システムやってたときがそんな感じだった。
しかもメディアはMOで、数台～十数台のPCに一個しかないので、MOに落とすの待ちやったあとに
ライブラリアンの前で行列みたいな感じだった。テスト中は地獄。

970 ：デフォルトの名無しさん：2010/04/06(火) 15:29:44

それって何のメリットがあるの?

971 ：デフォルトの名無しさん：2010/04/06(火) 18:14:57

いつのまにか動かないリポジトリにならない

972 ：デフォルトの名無しさん：2010/04/06(火) 20:12:10

レポジトリを破壊する奴を全員放り出した方が生産性が上がる気がする

973 ：デフォルトの名無しさん：2010/04/07(水) 06:47:04

そのあたり、subversionは使用経験が浅くてよくわからんのだけど、
CVS なら、

1.各人が勝手にコミット
2.ある時点でテスト担当がチェックアウトしてテスト実施
2-1.テストが失敗したら、当該ユニットの担当者に連絡
2-2.当該ユニットの担当者が修正してコミット
2-3. 2に戻る
3.テスト成功した時点で所定のタグを打つ
4. 1に戻って全体が完成するまで繰り返し。

みたいなことやってれば、「動かないリポジトリ」にはならないじゃん。
最悪、直前のバージョンタグ（ベースライン）まで戻ればいい。
そういう管理って subversion ではできないの？

974 ：デフォルトの名無しさん：2010/04/07(水) 08:05:56

subversionは、branchesに分岐、修正、テスト、trunkにマージで問題なく安全なtrunkをリポジトリに作れるし。

975 ：デフォルトの名無しさん：2010/04/07(水) 08:16:11

いつの間にか壊すような奴は何も考えずにtrunkにコミットコミットコミット！

976 ：デフォルトの名無しさん：2010/04/07(水) 08:59:47

>>971 は運用が適当なだけなので本気にしてはいけない。
本当のメリットは、上司用の仕事を作れること。

977 ：デフォルトの名無しさん：2010/04/07(水) 09:09:30

>>975
そのあたりはアクセス管理でなんとかならないの？

>>974
そのやり方だと、trunk の内容がテスト済みに保たれるだけだよね？
「ある時点のテスト済みプロジェクト全体」を取り出すにはどうすればいいの？
例えば、リリースファイルをビルド番号で管理していた場合に、
何世代か前のビルドに対応するプロジェクトのファイルのセットを取り出すみたいな。

978 ：デフォルトの名無しさん：2010/04/07(水) 09:15:51

>>977
> そのやり方だと、trunk の内容がテスト済みに保たれるだけだよね？
trunkにテスト済みが保たれてればいつでもテスト済みプロジェクト全体が取り出せるやん。

979 ：デフォルトの名無しさん：2010/04/07(水) 10:03:13

>>978
いや、だから、それは「最新の」テスト済みプロジェクト全体だけじゃないの？
以前のビルドに使ったプロジェクトのセットはどうやって識別するの？

980 ：デフォルトの名無しさん：2010/04/07(水) 10:19:47

tags使えやタコ

981 ：デフォルトの名無しさん：2010/04/07(水) 10:46:35

>>979
> リリースファイルをビルド番号で管理していた場合
だろ？
そこまで細かいことやってるんなら、その直近のtrunk出しておｋ、じゃないのか？
もしかして頭固い？

982 ：デフォルトの名無しさん：2010/04/07(水) 10:49:49

そのあたりが subversuon はよくわからないんだな。

CVS　なら、「そういときはタグを打て」と言われたとき、
コマンドのリファレンスを調べれば、
大体該当する機能があってどうすればいいかはわかるんだけど、
subversion の場合、マニュアルを見てもそういう機能は見当たらないのに、
みんなあたりまえのように　trunk とか branches　とか、tags とかを
使う話をしてる。
例えば、tags を使えと言われて　svn コマンドのリファレンスを調べるんだけど、
それに対応するコマンドなりオプションなりは、まったく見当たらない。

983 ：デフォルトの名無しさん：2010/04/07(水) 10:54:03

>>979
もしかして>>979はバージョン管理システムの基本がわかってないんじゃなかろうか
過去の履歴は「全て」残ってるのが大前提のシステムだぜ？
「最新の」ものしか出てこないバージョン管理システムってあると思う？
# ひょっとしてCVSがそうなのか？

「ビルドの識別」には、それこそtags利用なりリビジョン番号のメモを取るなりすればいい
それは運用だけど、それが「できない」ものはVCSの名に値しないよ

984 ：デフォルトの名無しさん：2010/04/07(水) 10:59:00

大規模システムってプログラマが数百人いて、各人が勝手にコミットとかしたら大変なことになる。

985 ：デフォルトの名無しさん：2010/04/07(水) 11:01:01

>>981
「直近」という言葉の意味がよくわからない。
なぜ、「そのビルドをビルドした時点」ではダメなの？

例えば、CVS の場合、ビルド100 を作るときに、
「B100」とタグを打って、「B100」でチェックアウトしてビルドしてテストしてリリースすれば、
そのあと、ビルドが200になろうが、300 になろうが、「B100」でチェックアウトすれば、
ビルド100をビルドした時点のファイルのセットが得られるよね？
これと同じことは subversion ではできないの？
「直近」というのは、どういうファイルを取り出すことを言っているの？

986 ：デフォルトの名無しさん：2010/04/07(水) 11:10:44

>>985
直近は曖昧だったか。ダメじゃないよ。
その「ファイル」をコミットした時点でのビルド、っていう基点がわかってるなら、
それこそそのファイルをコミットしたリビジョン番号が、すなわちあんたのいうB100だ。
(ex. rev.9893、とかな)
リビジョン番号はファイルについているのではなく、リポジトリ（≒プロジェクト）全体での通し番号。

んで、それではわかりにくいので、慣習的にtagsっていうディレクトリをtrunkと同階層に掘って、
そこに「コピー」を作る。
このコピーは結局trunkのディレクトリのコピーなので、好きな名前を付けられる。B100でも何でも。
また、いくつでも好きなときに作れる。これがSubversionで言うところの tags

987 ：デフォルトの名無しさん：2010/04/07(水) 11:22:52

>>986
なるほど、trunk とか tags ってのは慣習的に「そうやってる」って話なんだ。
リファレンス調べてもわからないはずだ。
それでわかりました、ありがとう。

988 ：デフォルトの名無しさん：2010/04/07(水) 11:35:39

そのあたり、わかりやすく書いた半公式サイトがあったような気がしたが、今探したら見つからないな。
やっぱり流行ると、なんつったっけ、ゴミサイト率が上がるな

989 ：デフォルトの名無しさん：2010/04/07(水) 12:24:38

>>988
TortoiseSVNのヘルプじゃね

990 ：デフォルトの名無しさん：2010/04/07(水) 12:59:50

>>987
まあ逆に考えるんだ
SVNなら、リビジョン番号さえわかれば、タグがついてなくてもいつでも
全ファイルセットを取り出せると考えるんだ

タグがコピーって言ったって、別に全てのファイルをコピーしてるわけじゃないし
コミットさえ無ければ（恐ろしいことにこれは可能だが）、純粋にリビジョン番号を
保持しているだけみたいなもんだし。

991 ：デフォルトの名無しさん：2010/04/07(水) 15:20:12

>>987
そうそう。
trunk、branches、tagsっていう名前を作るといいかもね
っていう感じ

992 ：デフォルトの名無しさん：2010/04/07(水) 15:31:19

え？trunk、branches、tagsってSubversionのマニュアルに載ってないの？
「慣習として使っている」みたいな記述もなし？

993 ：デフォルトの名無しさん：2010/04/07(水) 15:43:22

>>988
上平哲が訳して公開してたやつだと思うけど見つからない。
今は別の人が公開してるみたい。
www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork

994 ：デフォルトの名無しさん：2010/04/07(水) 17:18:06

まあ未訳が多いからTortoiseSVNのほう見たほうがいいかもね

995 ：デフォルトの名無しさん：2010/04/07(水) 18:26:13

「お約束」位のノリ

996 ：デフォルトの名無しさん：2010/04/07(水) 19:43:37

>>992
あったよ。
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html#ftn.id494504

997 ：デフォルトの名無しさん：2010/04/07(水) 19:54:10

projectname/trunkのタグをprojectname/tagsに入れるのは違和感ないんだが、
projectname/branchesのタグをprojectname/tagsに入れるのは違和感が有る。
かといって、projectname/branches/tagsを作るのもなぁという感じ。
どうやってる？

998 ：デフォルトの名無しさん：2010/04/07(水) 20:00:29

↓次スレ

999 ：デフォルトの名無しさん：2010/04/07(水) 20:09:59

つーか埋め立てるぞｺﾞﾙｧ
VSSで決まりだろｱﾌｫﾝﾀﾞﾗｰ

1000 ：デフォルトの名無しさん：2010/04/07(水) 20:50:10

1000ならVSS滅亡

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。