トップページ⇒tech
1001コメント322KB

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

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2010/04/07(水) 20:40:36
●関連スレ
CVS 1.3 [UNIX板]
http://pc12.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ～ Rev.3 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1154701996/
Subversion r12 [プログラム板]
http://pc12.2ch.net/test/read.cgi/tech/1254838551/
git スレッド [Linux板]
http://pc11.2ch.net/test/read.cgi/linux/1197798039/
【分散型バージョン管理】 Mercurial 【hg】
http://pc12.2ch.net/test/read.cgi/tech/1251208950/
【bzr】Bazaarでバージョン管理 Rev 2
http://pc12.2ch.net/test/read.cgi/tech/1265951333/

●過去スレ
バージョン管理システムについて語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1193332500/
バージョン管理システムについて語るスレ2
http://pc11.2ch.net/test/read.cgi/tech/1215520728/
バージョン管理システムについて語るスレ3
http://pc12.2ch.net/test/read.cgi/tech/1228366972/
バージョン管理システムについて語るスレ4
http://pc12.2ch.net/test/read.cgi/tech/1242918130/
バージョン管理システムについて語るスレ5
http://pc12.2ch.net/test/read.cgi/tech/1255241922/
0002デフォルトの名無しさん2010/04/07(水) 20:46:44
●関連サイト
CVS
ttp://ximbiot.com/cvs/wiki/
Subversion
ttp://subversion.tigris.org/
Git
ttp://git-scm.com/
Bazaar
ttp://bazaar.canonical.com/en/
Mercurial
ttp://mercurial.selenic.com/wiki/
Darcs
ttp://www.darcs.net/
GNU arch
ttp://www.gnu.org/software/gnu-arch/index.html
monotone
ttp://www.monotone.ca/
Visual SourceSafe
ttp://www.microsoft.com/japan/msdn/vstudio/products/ssafe/default.aspx

●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://subversion.bluegate.org/ (アクセスできない場合は↓)
ttp://www.caldron.jp/~nabetaro/hiki.cgi?SubversionWork
Git入門
ttp://www8.atwiki.jp/git_jp/
Bazaar Documentation Overview
ttp://wiki.bazaar.canonical.com/Documentation
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial
0003デフォルトの名無しさん2010/04/07(水) 22:37:23
ごめん、前スレで告知するの忘れてた。
0004デフォルトの名無しさん2010/04/07(水) 22:43:28
前スレからの続きだけど、タグやブランチの扱いに関しては Subversion はかなり異端だと思う。
「機能がないから運用で回避」みたいな。
0005デフォルトの名無しさん2010/04/07(水) 22:46:32
>>4
内部実装はあれでもいいんだけど、ユーザに見せるなやって思うわ

0006デフォルトの名無しさん2010/04/07(水) 23:14:40
スレ立て乙
0007デフォルトの名無しさん2010/04/08(木) 01:41:55
>>4
ディレクトリがあればタグやブランチはいらないと言うのがsubversionの考え方
0008デフォルトの名無しさん2010/04/08(木) 06:32:58
面白いな。
リーナスに罵倒されるぐらい CVS を踏襲しようとしてるのに、
妙なところで独自性を出してるという。
0009デフォルトの名無しさん2010/04/08(木) 07:03:03
ClearCaseの使い勝手ってどんな感じ？
0010デフォルトの名無しさん2010/04/08(木) 07:29:09
>>9
クソってのが定説だな
0011デフォルトの名無しさん2010/04/08(木) 07:51:29
>>5
ユーザが自由に運用しておくれ、という意味だと思ってた。
その割には、ベストプラクティス系のドキュメントを見たことがないが。
0012デフォルトの名無しさん2010/04/08(木) 09:03:14
>>7
バージョン管理システムがなければ
フォルダを作ってこそにコピーすることになると思うけど
それと全く同じイメージで使えることを目指したんだろうね
0013デフォルトの名無しさん2010/04/08(木) 10:09:44
>>8
それが svn コミュニティのあほなところ。
svn はすっ飛ばして正解だった。
0014デフォルトの名無しさん2010/04/08(木) 10:26:58
>>13
一度は触っとけよ
Tortoiseの使い勝手だけは間違いなく一級品だぞ
プログラマ以外にバージョン管理を使ってもらうには未だSVNが最高でデファクト
0015デフォルトの名無しさん2010/04/08(木) 11:02:01
最高でデファクトかどうかは兎も角、Tortoiseとかウェブクライアントはよくできているみたいね。
CVSからsvnに引き継いだプロジェクトは事実上死滅したし、
svnでスタートしたプロジェクトは全てbzrに引き継いだから私のところでは最早使ってないけど。
0016デフォルトの名無しさん2010/04/08(木) 11:13:16
>>15
？？
RubyはCVS→SVNだけど？
0017デフォルトの名無しさん2010/04/08(木) 11:25:48
15は突然自分語りを始めただけじゃねぇの
0018デフォルトの名無しさん2010/04/08(木) 11:26:12
>>16
その2行目は、3行目の「私のところ」の話だろう。
0019デフォルトの名無しさん2010/04/10(土) 21:25:42
いつになったらまともに日本語ファイル名を扱えるgitクライアントが出てくるんだよ。
cygwinとかいうのは無しで。
0020デフォルトの名無しさん2010/04/10(土) 21:56:01
>>19
gitユーザのありがたい仰せによると、
1. Windowsダっせぇ
2. んなもんどうせバイナリファイルだろ？svn使っとけやゴルァ
等々とても前向きなので、来世紀までには改善されるでしょ。
0021デフォルトの名無しさん2010/04/10(土) 22:45:12
これだからgitユーザーはクッセェんだ
0022デフォルトの名無しさん2010/04/10(土) 23:09:35
>>19
UTF-8なら問題ないよ。
Windowsとかいうのは無しで。
0023デフォルトの名無しさん2010/04/10(土) 23:10:58
一つの言語に対するエンコーディングが複数存在することを理解させる
複数のエンコーディングを排して統一するものとしてUNICODEでは不十分なことを理解させる
0024デフォルトの名無しさん2010/04/10(土) 23:20:58
UNICODEが不十分だから他のエンコーディングを相互変換するのが気持ち悪いんじゃないの？
0025デフォルトの名無しさん2010/04/10(土) 23:42:38
ファイル名にカッコ株とか携帯絵文字でもはいってんのか？
0026デフォルトの名無しさん2010/04/10(土) 23:46:25
別に完璧なんか求めてなくて、svnでできる程度できれば問題ないんじゃないの？
0027デフォルトの名無しさん2010/04/11(日) 00:32:26
カッコ株はunicodeにあるだろ
携帯絵文字もそのうち入るし
0028デフォルトの名無しさん2010/04/11(日) 14:02:08
gitはUnicodeとか何も考えてないよ。パス名はバイト列として扱ってるだけだから。
でもWindowsのANSI APIは、パス名をローカライズされた文字列(日本ならcp932)とみなしてUnicodeに変換しちゃうから、
gitのやり方だとAscii文字列以外がおかしくなる。

Unicode APIを使ってくれれば問題は起きなくなるはずなんだが、
そのためにはgit側がパス名をUTF-16に変換してからAPIに渡す必要がある。
結局、Windowsではパス名は文字列であるという認識をgitが持ってくれないといけない。

よく知らないけどCygwin1.7はちゃんとこういう変換をやってるのかな。
0029デフォルトの名無しさん2010/04/11(日) 15:07:31
Unicodeとか何も考えてないのに、Unicodeに変換しちゃうの？
0030デフォルトの名無しさん2010/04/11(日) 15:09:28
この読解力の無さはすごい
0031デフォルトの名無しさん2010/04/11(日) 15:09:37
変換しちゃう、のは win32 API が、じゃないの？
0032デフォルトの名無しさん2010/04/11(日) 15:33:38
よくわからん。
gitが取得したパス名ってCP932と見なせるバイト列じゃないの？
WindowsのANSI APIが渡されたバイト列をCP932として評価するなら化けないと思うんだけど。
0033デフォルトの名無しさん2010/04/11(日) 15:37:10
>>28
この考え方のせいでgit（とhg）はクズなんだけど、
DVCSでは一番（と二番）使われてるから今更変更きかないんだろうな。
まったく残念だ。
0034デフォルトの名無しさん2010/04/11(日) 15:39:18
俺Unicodeライブラリなんか使わないけど、一度もファイル名が化けたことなんてないよ
0035デフォルトの名無しさん2010/04/11(日) 15:40:30
>>32
それはそうだな
「Unicodeに変換しちゃう」のなら、gitのレポジトリにはUnicodeで送るようなイメージを受ける
>>28が詳しいなら、もうちょっと補足して欲しい
0036デフォルトの名無しさん2010/04/11(日) 15:40:49
UTF-8なら日本語だろうがどうということはないのだがな・・・
0037デフォルトの名無しさん2010/04/11(日) 15:42:31
>>36
だから、WindowsのクライアントがUTF-8なりなんなりでgitレポジトリに
アクセスすれば済むって話だろ？なんでそんなこともできないんだろう。
Windowsクライアントの開発者はやる気ないの？
0038デフォルトの名無しさん2010/04/11(日) 15:44:10
1時間くらいソース見て、ちゃちゃっとパッチ書けるならいいんだが、
だとしたらきっともう誰かがやってるはずだから、そうはいかないん
だろうなぁ。
0039デフォルトの名無しさん2010/04/11(日) 15:45:08
>>37
え？gitはUnicodeのことなんて考えてないのに、リポジトリにはUnicodeで保存するの？
0040デフォルトの名無しさん2010/04/11(日) 15:49:59
Windowsクライアントってgit.exeのこと？
0041デフォルトの名無しさん2010/04/11(日) 15:54:53
>>32
ごめん考察足りてないな。
確かに日本語Windowsだけで使うなら、CP932のまま扱っても問題ないはずだけど、
実際上手く扱えないのは例によって\が含まれる文字の場合じゃないかと。

>>35
gitのリポジトリに保存されてるファイル名はバイト列がそのまま保存されてる。
変換するのは、リポジトリからファイル名を取り出して、APIに渡した後の話。
0042デフォルトの名無しさん2010/04/11(日) 15:55:38
>>40
msysgitとやらいうやつのことじゃね？
0043デフォルトの名無しさん2010/04/11(日) 15:55:47
まぁ理由は何であれ、事実上のデファクトスタンダードであるmsysgitで正しくフィル名を
扱えるようにならないと駄目だな。
0044デフォルトの名無しさん2010/04/11(日) 15:57:16
>>41
> 実際上手く扱えないのは例によって\が含まれる文字の場合じゃないかと。

実際使ってみればわかるけど、どんな日本語ファイル名でも、ファイル名全体が化けるよ。
0045デフォルトの名無しさん2010/04/11(日) 15:57:55
>>33
別に今からでも、Windowsの場合だけは、
パス名の内部表現をUTF-8の文字列にして、APIに渡す前にUTF-16に変換する
って動作をするように変えてくれれば、困る人はいないんじゃないかなぁ。
0046デフォルトの名無しさん2010/04/11(日) 15:59:22
>>39
>>37は>>36へのレスで、UTF-8なら問題ないってのをまともに受けて書いたレス
その疑問は>>36へどうぞ
0047デフォルトの名無しさん2010/04/11(日) 15:59:39
ということは、msysgitがファイル名をUnicode(UTF-8?)でリポジトリに登録して、
持ってくるときはそれをcp932と見なして変換しちゃうということか。
どうやったらそんなタコなことできるんだよｗ
0048デフォルトの名無しさん2010/04/11(日) 16:11:13
>>47
おれぁファイル名のエンコードなんぞ知ったこっちゃねぇんだよ、
とかいってansi版のWinAPIにそのままバイト列突っ込んじまえば、そうなる。
0049282010/04/11(日) 16:11:54
>>47
いやリポジトリにはあくまでバイト列としてしか登録されないからそんなことはしてないよ
ちょっと>>28は忘れてくれ…。
APIのUnicode変換と文字化けを関連付けたのはおかしかった。
0050デフォルトの名無しさん2010/04/11(日) 16:14:48
>>48
Unicodeライブラリを使わない場合、コマンドライン引数もファイル名取得もCP932なわけだが。
0051デフォルトの名無しさん2010/04/11(日) 16:17:15
ちょっと待て。
msysgitでファイルを登録して、msysgitでファイルを取得しても化けるということなのか？
それともUTF-8を使ってるUnix/Linuxで登録したものを取得したら化けるのか？
0052デフォルトの名無しさん2010/04/11(日) 16:17:17
>>50
リポジトリはUTF-8って前提だから化けるわけだよね。
0053デフォルトの名無しさん2010/04/11(日) 16:19:17
あとログも化けるｗ
0054デフォルトの名無しさん2010/04/11(日) 16:20:11
じゃ、Windowsに閉じたグループがmsysgit使うなら何の問題もないじゃん。
0055デフォルトの名無しさん2010/04/11(日) 16:24:22
>>54
>>51の後者だとは思うが、その上で、TortoiseGitでは0x5C混じりのファイル名で
コミット出来ないって問題があって、それはmsysgitをそのまま使ってるから云々って
問題があったような希ガス

今は直ってるのかも知れないけど、結局は同根の問題だと思う
0056デフォルトの名無しさん2010/04/11(日) 16:26:09
A系決めうちで使ってるコード全体をW系も使うようにするのは非常に手間だから誰もやってないと思う。
0057デフォルトの名無しさん2010/04/11(日) 16:27:49
やっとすっきりした。みんなサンクス。
0058282010/04/11(日) 16:33:13
なんか適当な考察のせいで無駄にログ伸ばしたようで申し訳ない。
結局APIうんぬん以前にmsys側の問題が大きそうだね。
0059デフォルトの名無しさん2010/04/11(日) 16:42:14
誰か結論がどうなってんのかまとめてくれ
0060デフォルトの名無しさん2010/04/11(日) 16:44:51
>>59
・Windowsダサい
・gitで日本語ファイル名使う男の人って…
・結局cygwinってよくできてるよね

の三本立てでお送りしました
0061デフォルトの名無しさん2010/04/11(日) 17:01:58
結論：
・ファイル名がUTF-8で保存されているファイルはmsysgitを使うと化ける（いわゆる”日本語ファイル名”のみ）
・msysgitを使ってcp932のファイル名を保存する場合は\問題がある
・UTF-8でログを保存している場合は、mysgitでは化ける
・UTF-8版Cygwinでgitを使えば問題ない
0062デフォルトの名無しさん2010/04/11(日) 17:04:06
なんで日本語WindowsでUTF-8をデフォルトのコードページとして使えないの？
なんかそれだけで済む気がするんだけど、結局そういうOSじゃないってこと？
スレ違いかとは思うけど…
0063デフォルトの名無しさん2010/04/11(日) 17:04:40
>>60
そういうのは結論とはいわない。

>>61
ありがとう。よくわかった。
0064デフォルトの名無しさん2010/04/11(日) 17:08:18
>>62
カーネル内はUnicode化されてるんだけど、FAT32がcp932でファイル名を保存する関係で
ごちゃごちゃしてるんだと推察
0065デフォルトの名無しさん2010/04/11(日) 17:31:43
つか、日本語で名前付けるようなファイルって、結局は仕事で使うようなオフィス系のファイルだったり
デザイナーが使うリソースファイルだったりでしょ？
それらはどうせマージ出来ないんだから、gitとか使う意味ないし、そっちだけsvnなりでやってればいい。
0066デフォルトの名無しさん2010/04/11(日) 17:44:32
>>65
「>>20まで戻る」

なんだこの不毛なスレ進行ｗ
0067デフォルトの名無しさん2010/04/11(日) 18:07:21
さくらインターネットでgit入れてTortoiseGitでcloneとか
しようとしてるんだけどTortoisePlink passwordってダイアログが出て
パスワードを毎回入れるハメになるけど回避方法無いですか？
0068デフォルトの名無しさん2010/04/11(日) 18:41:32
まぁgitは一生マルチプラットホーム足り得ない田舎アプリってことでしょ
どうでもいい
0069デフォルトの名無しさん2010/04/11(日) 19:04:48
経緯の上でも、Linuxカーネル開発に使えれば十分なわけで。
0070デフォルトの名無しさん2010/04/11(日) 19:47:06
>>67
sshの公開鍵を作ればいい。
TortoiseSVNのほうが情報充実してるから、
TortoiseSVN ssh 公開鍵 あたりのキーワードでぐぐる。
0071デフォルトの名無しさん2010/04/11(日) 19:56:55
>>68
Windowsがサポートされればマルチプラットホームなのか？
どうしてだかドザって除け者にされると激しい反応を示すよな。。。。
0072デフォルトの名無しさん2010/04/11(日) 20:00:58
>>70
サンクス。sshの公開鍵ね
ぐぐって試してみるわ～
0073デフォルトの名無しさん2010/04/11(日) 20:26:14
>>71
なんだこの馬鹿は
なぜ突然「Windowsがサポートされればマルチプラットホーム」とか言い出すんだ？
マルチプラットフォームの意味知らんのか？
そんなの成り立つわけが無いだろ
0074デフォルトの名無しさん2010/04/11(日) 21:00:34
いや、まあ、あれだ

Windows入れてもすでにほぼマルチプラットフォームなんだ、gitは
ただ、マルチバイト文字圏ってのはなんだかんだ自助努力が必要なんだ結局
そこのところ、開発者かユーザかどっちがひっかぶるかってだけの話なんだと思うんだ
今世紀も半ばくらいには、多分解消してるよ。主にWindowsの変化によって（笑）
0075デフォルトの名無しさん2010/04/11(日) 21:01:35
>>73
は？　Windowsでgitのファイル名が化けるだとかって、昨日からずーっとグダグダやってんじゃん。
Windowsでうまく動かないから田舎アプリだとか、痛いレスしちゃって。
0076デフォルトの名無しさん2010/04/11(日) 21:09:19
一部を除いては、も少し建設的な情報交換もできたと思うので、そのまとめはどうかと
0077デフォルトの名無しさん2010/04/11(日) 21:15:58
Windows？そんなの知るかよ！って奴等が集まってるようには、見えるなｗ
http://repo.or.cz/w/git.git
0078デフォルトの名無しさん2010/04/11(日) 21:26:25
no-windows wwwww
0079デフォルトの名無しさん2010/04/11(日) 21:49:16
>>77
当たり前だけどJunio C Hamano氏の活動量すげぇ
0080デフォルトの名無しさん2010/04/11(日) 22:03:52
世界の70%を占めてるOSにまともに対応せずにマルチプラットホームとか(笑)
ごく簡単に対応できる問題にも対応できずに高スキル集団気取ってんなよgit共がｗｗ
0081デフォルトの名無しさん2010/04/11(日) 22:13:00
>>70
できた。puttygenで生成したテキストをauthorized_keysというファイル名で
保存しサーバーの$HOME/.sshのフォルダにアップロードするという事が
分からず時間掛かったけど。
あとはpageantを常駐してadd keyさせたらパス入力聞いてこなくなった。
0082デフォルトの名無しさん2010/04/11(日) 22:17:49
確かに変なのが居着いてるな
Windowsで普通にgit使いたい奴にとって非常に迷惑な奴が
0083デフォルトの名無しさん2010/04/11(日) 22:51:26
>>80
WindowsならSVNを使えばいいんじゃないですかね？
無理してgit使ってWindowsの欠点に文句言うのも不毛だよね
0084デフォルトの名無しさん2010/04/11(日) 22:58:20
Windowsの文字コードをUTF8にしたいんだけどどうやるの？
0085デフォルトの名無しさん2010/04/11(日) 23:00:55
文字列をバイト列と考えるgit側の致命的欠陥だろ
どこの誰がパスをバイト列で指定するんだよ
根本から間違ってる
0086デフォルトの名無しさん2010/04/11(日) 23:02:14
リナ糞圏のマルチバイトの弱さは特筆に価する。
0087デフォルトの名無しさん2010/04/11(日) 23:06:27
>>80
世界の70%を占めてるOSの世界の70%を占めてるユーザーで問題が無いことが問題なんだな。
(細かい数字は適当だから気にするな)
0088デフォルトの名無しさん2010/04/11(日) 23:09:33
>>85
だったらwinユーザーはgit使わずsvn使えば問題ない
0089デフォルトの名無しさん2010/04/11(日) 23:10:46
べつにWindowsユーザーに使ってもらうために作ってるわけでもないだろうし。
0090デフォルトの名無しさん2010/04/11(日) 23:10:48
>>88
なら田舎アプリと言われたからってウダウダ口出しすんな
0091デフォルトの名無しさん2010/04/11(日) 23:12:03
LinuxのlocaleをEUC-JPにするとかShift-JISにするとかすれば同じ問題が起きる
Windowsのlocaleを英語にすれば(ほぼ)問題が解決する
それが問題なのか問題では無いのかの違い
0092デフォルトの名無しさん2010/04/11(日) 23:12:32
というかWindowsだと問題が多発するgitをわざわざ使う必要なし
Windowsならsvn使うのが超安定
0093デフォルトの名無しさん2010/04/11(日) 23:19:34
>>90
そんなにくやしいなら自分でWindows用のgit作れ
オープンソースなんだからさ
0094デフォルトの名無しさん2010/04/11(日) 23:21:07
そろそろ、日本語使うなら Bazaar 使おうぜ！ って言ってもいい？
0095デフォルトの名無しさん2010/04/12(月) 00:55:49
gitとかそろそろ滅びろよ
0096デフォルトの名無しさん2010/04/12(月) 01:07:10
svn使ってれば？
0097デフォルトの名無しさん2010/04/12(月) 02:02:12
>>94
【bzr】Bazaarでバージョン管理 Rev 2
http://pc12.2ch.net/test/read.cgi/tech/1265951333/

Bazaarって知らなかったけど面白そうだな
0098デフォルトの名無しさん2010/04/12(月) 10:24:45
cygwin の git で LANG=ja_JP.utf-8 で使うというのが
現状では一番なのではないのか?
どうしてもmsysgitを使いたいっていうのならパッチ当てるしか...
0099デフォルトの名無しさん2010/04/12(月) 15:52:23
まっ良く知らない奴がWindowsでgit使うと痛い目見るって事だな

ここ見た奴は周りがWinでgit使いたいって言ったら全力で引き止めろよ
0100デフォルトの名無しさん2010/04/12(月) 17:47:41
いつもこの過剰な流れを見るたびに日本語ファイル名を使わなきゃ良いだけだろと思うんだけど...
ログはlogoutputencodingとcommitencodingを設定すれば問題ないし。
0101デフォルトの名無しさん2010/04/12(月) 18:02:23
まあ、その辺りは、置かれてる立場によって変わってくるだろ。
一人だけでやってるならなんとでもなるが。
0102デフォルトの名無しさん2010/04/12(月) 19:32:05
gitのコミッタはいい加減ガキ臭すぎると思うわ
簡単に解決できる問題をwindows憎しと言う感情のみで放置
チョン国人と同レベル過ぎる
0103デフォルトの名無しさん2010/04/12(月) 19:34:40
他人の感情がわかるとか凄いエスパーだな
0104デフォルトの名無しさん2010/04/12(月) 19:42:04
>>77 見ればただの野次馬な俺でも分かるってばよ・・・
0105デフォルトの名無しさん2010/04/12(月) 19:42:36
>>102
君みたいな人はSubversion使うのが合ってると思うよ
Windowsの文字コードの欠点はどうしようも無いからね
0106デフォルトの名無しさん2010/04/12(月) 20:04:28
あれ、svnでは解決してるんだろ？
どうしようも無いことなの？
0107デフォルトの名無しさん2010/04/12(月) 20:10:40
>>106
Linuxカーネル開発する上で困ることがないのでスルー。
0108デフォルトの名無しさん2010/04/12(月) 20:20:24
他の殆どのマルチプラットホームを謳うアプリで文字コードの問題を解決しているのに
git界隈ではどうしようもないと言われている
つまりはそういう事だ
0109デフォルトの名無しさん2010/04/12(月) 20:24:36
まぁ、現実問題対応していないと言う事は、gitはコミュニティレベルで劣っていると言う事の証左だよね。
0110デフォルトの名無しさん2010/04/12(月) 20:59:37
盛り上がっているのでmsysgitのソースコード見てみた。fopenとか使っている
んだな。gdi++.dllみたいにフックしてUTF-8変換すれば良いんじゃない?
0111デフォルトの名無しさん2010/04/12(月) 22:20:21
まあMercurialで問題ないわけだしね
0112デフォルトの名無しさん2010/04/12(月) 22:53:00
あるわ
0113デフォルトの名無しさん2010/04/12(月) 22:54:53
Hg、なんか中途半端なんだよな
いろんな意味で
0114デフォルトの名無しさん2010/04/12(月) 23:11:50
そうなのか?
0115デフォルトの名無しさん2010/04/12(月) 23:31:22
金属光沢だから、固体かと思ったら液体だった、みたいな？
0116デフォルトの名無しさん2010/04/12(月) 23:40:29
文字化けと言う失笑物の欠陥を直せないでいるgitよりはマシだけどね。
0117デフォルトの名無しさん2010/04/12(月) 23:47:45
自分が失笑されてることにも気づけないのか
0118デフォルトの名無しさん2010/04/13(火) 00:52:09
>>117
gitは検索タグがno-windowsってくらいだから、気づけないっていうか見ざる聞かざるだね
0119デフォルトの名無しさん2010/04/13(火) 01:31:06
プラットフォーム間で文字化けすると言う、普通に考えて恥ずかしいレベルの初歩的欠陥も

相手方がWindowsとなると途端に俺らに関係ねーししらねーよとなる

なんと言う低い民度のコミュニティであろうか

あらゆる原動力がwindows憎し、svn憎しから始まってるから、これで妥当なんだろうけどな
0120デフォルトの名無しさん2010/04/13(火) 02:52:26
根暗が負の感情を原動力にした時に発揮する力は半端無いからな
0121デフォルトの名無しさん2010/04/13(火) 03:34:21
別に憎いとかじゃなくて、彼らからみれば普通に馴染みのないOSだから。
そうやってギャーギャー言われると、こっち見んなってのはあるだろうけど。
0122デフォルトの名無しさん2010/04/13(火) 04:15:55
馴染みが無いと来たかｗ
それで居て田舎と言われると怒り出すｗｗ
0123デフォルトの名無しさん2010/04/13(火) 04:30:27
相手してもらえないからってファビョりすぎ。自称「都会」のWindowsで遊んでなさいよ。
0124デフォルトの名無しさん2010/04/13(火) 04:56:39
と、こんな時間に律儀に相手をしてる奴が何か言ってます。
0125デフォルトの名無しさん2010/04/13(火) 07:48:41
>>111
Mercurialも同じ問題抱えてた気が……
0126デフォルトの名無しさん2010/04/13(火) 08:25:22
Mercurialはmsys依存してるわけじゃないから、まだ何とかする余地がありそうなんだけど。
0127デフォルトの名無しさん2010/04/13(火) 10:35:15
Windows だけじゃなくて Mac に持ってっても問題出るよなぁ
0128デフォルトの名無しさん2010/04/13(火) 13:00:29
LANG=ja_JP.EUC-JPとかでもダメ。
要するに、汎用性は目標じゃないので、
多言語化はしたくない、ってことだろ。

現実を見据えた完全性を目標にしてる
感じのsvnやbzrとはもはや比較できない。
0129デフォルトの名無しさん2010/04/13(火) 13:19:27
もともとはLinus Torvaldsのオレ専用バージョン管理システムなんだから、
「Windowsで使えねー」とか言っても「Windowsを使うな」ってなるのは
ある意味当然

しかもLinusは特段優れたソフトウェアアーキテクトでもないしｗ
0130デフォルトの名無しさん2010/04/13(火) 13:46:58
誤解が無いように言っておくとWindowsで問題があるわけじゃない
変にローカライズされた一部のWindowsで問題がある
その中に日本語版Windowsが含まれるということ
0131デフォルトの名無しさん2010/04/13(火) 14:41:03
その「一部」の分母が数千万以上ってだけなんですけどね。
0132デフォルトの名無しさん2010/04/13(火) 16:07:08
それ以上に英語圏の分母が大きければ取るに足らんと思われても仕方ない
0133デフォルトの名無しさん2010/04/13(火) 18:32:41
その「一部」って世界のLinuxの稼動数超えてるよねｗ
0134デフォルトの名無しさん2010/04/13(火) 19:06:53
微妙な言い方だな。
Windows と Linux の「稼動数」の差って「ユーザ数」の差より小さいんじゃね？
0135デフォルトの名無しさん2010/04/13(火) 19:21:01
問題はOS自体の稼働数じゃなくてその上でのgitの稼働数だとおも。
0136デフォルトの名無しさん2010/04/13(火) 19:37:00
え？gitをまともに使えない現状でのgit稼動数を問題にするの？ｗ
そりゃ一生解決しませんわｗ
0137デフォルトの名無しさん2010/04/13(火) 19:39:30
svnみたいに高品質ならwindowsでも使われまくるよ
0138デフォルトの名無しさん2010/04/13(火) 19:42:11
次にお前は　だったらwinユーザーはgit使わずsvn使えば問題ない　と言う
0139デフォルトの名無しさん2010/04/13(火) 20:27:30
なんかgitのこと叩いてるWindowsユーザって、ふだん高飛車でちやほやされてるご令嬢が
転校生の主人公に無視されて「わたくしを誰だと思っているの！？」って怒ってるみたいでちょっと萌えるｗ
0140デフォルトの名無しさん2010/04/13(火) 20:44:05
>>139
いや、別にGitを使わなくてすむならそれでいいんだけど、
開発者のあいだでGitが人気なのはもはや止めようがなく、
好き嫌いに関わらず、使わなきゃいけない場面というのは
どうしても出てくるわけよ。
そして、Windowsで使おうとすると問題がでて困る、という話。
自分にすべて決定権があるならGit使わないという決定が
できるけど、そうじゃない人もいるよね。残念ながら。
0141デフォルトの名無しさん2010/04/13(火) 20:54:14
うそーん。
git使ってる人達は問題のない使い方してるはずだから、
Windowsで使うと問題が起こるなんてことはないんだよー。
0142デフォルトの名無しさん2010/04/13(火) 21:00:55
>>141
× 問題のない使い方
○ 問題に近寄らない使い方
0143デフォルトの名無しさん2010/04/13(火) 22:47:08
>>125
Mercurialはダメ文字は大丈夫。でもファイル名がバイナリ列なのはgitと同じ。
0144デフォルトの名無しさん2010/04/13(火) 23:59:13
あー、ダメ文字って0x5c入りの奴もそう呼ぶんだ。
マッピングできない奴だけを言うのかと思ってた。
0145デフォルトの名無しさん2010/04/14(水) 04:17:45
Git使いの>>139は物語の主人公らしいｗ
流石ですｗ
0146デフォルトの名無しさん2010/04/14(水) 10:45:47
>>144
個人的には、5Chが入ってる文字＝ダメ文字、で使ってきたから
マッピングできない文字をダメ文字と呼ぶ方が新鮮だったり。
0147デフォルトの名無しさん2010/04/14(水) 12:31:34
>>143
fixutf8
0148デフォルトの名無しさん2010/04/14(水) 13:18:49
バージョン管理システムも用途によって分化していくのかな。
0149デフォルトの名無しさん2010/04/14(水) 15:47:58
>>147
Hgスレだとfixutf8でもだめっぽいけど
0150デフォルトの名無しさん2010/04/14(水) 20:50:16
まぁgitもMercurialもLinux kernelの管理用に作られたわけだしな
0151デフォルトの名無しさん2010/04/14(水) 21:00:01
というかそういうWindowsでしか発生しない問題なんかは
TortoiseXXXとかのGUIがなんとかすればいいだけじゃないか？
どうせWindowsでコマンドラインから使ってる奴なんて
ほとんどいないでしょ
もしコマンドラインからやりたいならCygwin使えばいいだけだし
0152デフォルトの名無しさん2010/04/14(水) 22:10:53
>>151
MergurialやGitの問題です
0153デフォルトの名無しさん2010/04/14(水) 23:27:14
>>149
fixutf8でファイル名の問題は解決する
0154デフォルトの名無しさん2010/04/15(木) 00:08:27
>>151
無知と偏見の塊なのを自覚して黙ってた方が良いよ
0155デフォルトの名無しさん2010/04/15(木) 01:23:15
最近、仕事先でgitを使ってる。
一つ不満なのが、git status やらで出てくるメッセージが英語なんだが、
これって日本語メッセージにできないの？linuxのCUIでの話。
警告とか普通に読み飛ばしてしまってなんだかなー

export LANG=ja_JP.utf-8 とかはやってみた。だめだった。
なんかパッチとか必要なのかな
0156デフォルトの名無しさん2010/04/15(木) 01:32:15
>>155
ソースコードをgettext化する必要があるだろうね。
gitの配布物の中にある git gui はこれを使ってそこそこ国際化済み。
01571552010/04/15(木) 01:39:31
>>156
CUIはまだ国際化されてないのね
thx
0158デフォルトの名無しさん2010/04/19(月) 14:19:22
WindowsはさっさとUTF8化しる！
いつまでSJISなんだよ古くさー
0159デフォルトの名無しさん2010/04/19(月) 15:42:28
えっ
0160デフォルトの名無しさん2010/04/19(月) 20:38:21
マジで言ってるの？
0161デフォルトの名無しさん2010/04/20(火) 16:54:26
3.1の話かとｗ
0162デフォルトの名無しさん2010/04/20(火) 19:50:36
158じゃないけど、エクスプローラとか
コマンドラインとかのフロントエンドは
もうUTF-8にしないのかなーとは思う。
0163デフォルトの名無しさん2010/04/20(火) 21:21:46
コマンドプロンプト自体は一応UTF-8対応してるぞ
0164デフォルトの名無しさん2010/04/20(火) 22:13:55
Windowsの標準アプリはほぼUnicode対応になってるはず。
CP932に依存するのってコマンドプロンプトくらいじゃないか？

標準じゃないやつだと未だにAnsi API使ってるのがいっぱいあるけどな。
0165デフォルトの名無しさん2010/04/20(火) 22:58:11
cmd.exe のコードページを utf-8 にするには
chcp 65001
としたらよいのだが、今度は日本語フォントが。
0166デフォルトの名無しさん2010/04/20(火) 23:26:07
>>164
甘いよ。大甘。

Windowsではメニューやダイアログボックスなどのリソースは実行形式に埋め込まれるが、
そのリソースはUTF8どころか、UNICODEですら記述されていない。

なのでOSのロケールをUTF8にしてもまともに表示できるアプリはほとんどない。
0167デフォルトの名無しさん2010/04/20(火) 23:32:54
>>166
？？？
0168デフォルトの名無しさん2010/04/20(火) 23:36:57
ここまで意味不明な文章もなかなかないな
0169デフォルトの名無しさん2010/04/20(火) 23:49:49
なんだ、ム板だからわかるかと思ったが、このスレの住人にはわからんのか。

いや、悪かったな。意味不明な文章書いて。忘れてくれ。
0170デフォルトの名無しさん2010/04/21(水) 00:32:52
これはひどい。
0171デフォルトの名無しさん2010/04/21(水) 00:36:44
explorer.exeなりをバイナリエディタで開いてみれば、リソースがUnicodeで入ってることくらいすぐわかるんだが…。
（ただしVista以降ではリソースDLLに分離されてる）
0172デフォルトの名無しさん2010/04/21(水) 00:50:30
notepad.exe の保存ダイアログでは文字コードの指定ができ、utf-8 もある。
メモ帳で utf-8 を表示できるだろうということは標準コントロールで表示できることを示唆している。
0173デフォルトの名無しさん2010/04/21(水) 01:07:23
>>172
それはファイルの読み書きするときに変換かけてるだけだ。
EditコントロールはUTF-16でしか動かないぞ。
0174デフォルトの名無しさん2010/04/21(水) 08:56:15
そもそも>>162のexplorerがUTF-8に対応するってどういう意味かわからん
NTFSがUTF-8化するってこと？
0175デフォルトの名無しさん2010/04/21(水) 15:31:19
文字コード気にするやつはWindowsでgitを使うな
超安定のSubversionを使ってればいいんだよ
Windowsはもう諦めろ。無理してgit導入しても周りの迷惑にしかならん
0176デフォルトの名無しさん2010/04/21(水) 15:52:08
VisualStudioのリソースエディタでUnicodeが扱えないだけ
0177デフォルトの名無しさん2010/04/21(水) 16:48:06
はぁ？
0178デフォルトの名無しさん2010/04/21(水) 20:36:16
ファイル名に日本語使うバカは常識的に居ないからgit使っても問題なし
0179デフォルトの名無しさん2010/04/21(水) 20:42:37
はぁ？
0180デフォルトの名無しさん2010/04/21(水) 20:56:18
ホームフォルダが日本語名になっちゃってる人はよく見かける
0181デフォルトの名無しさん2010/04/21(水) 21:12:03
フォルダ()笑て何ですか?
0182デフォルトの名無しさん2010/04/21(水) 21:16:33
>>181
Windowsで使うな！と言いたいんだな?
0183デフォルトの名無しさん2010/04/21(水) 22:11:34
これだからWindowsユーザーは…
Subversionしか勧められないわけだ
0184デフォルトの名無しさん2010/04/21(水) 22:16:07
Windowsは今のunicodeの実装自体にはそれほど問題無い。Macよりは。
ただ過去の無理矢理localizeの後遺症がデカい。
0185デフォルトの名無しさん2010/04/21(水) 22:24:32
今時どのOSだってフォルダと言う
0186デフォルトの名無しさん2010/04/21(水) 22:37:48
フォルダとディレクトリは必ずしも一致しないな
0187デフォルトの名無しさん2010/04/22(木) 07:54:57
Windowsとかどうでもいいので開発陣には他のことに力を注いでもらいたい
0188デフォルトの名無しさん2010/04/22(木) 08:21:29
果たしてwinだけの問題であろうか。
ファイル名を単なるバイト列としか扱ってないことを続けて良いのか。
0189デフォルトの名無しさん2010/04/22(木) 09:09:48
Linux含めてUnixのfilesystemはバイト列で扱ってるからな。
WindowsはfilesystemはUnicodeとして扱う。
0190デフォルトの名無しさん2010/04/22(木) 15:58:08
MicrosoftがCanonical(Ubuntuの開発元)の運営するLaunchpadを使い始めた件。
https://launchpad.net/coapp
https://launchpad.net/~garretts
おまけ
https://bugs.launchpad.net/bugs/1
0191デフォルトの名無しさん2010/04/22(木) 20:38:02
＞Unixのfilesystemはバイト列で扱ってる
じゃあどうしようもないな
0192デフォルトの名無しさん2010/04/23(金) 23:13:57
>>190
MSの歩み寄りに今だに感情的に反発してる馬鹿共は何なの
どこまでガキなの
0193デフォルトの名無しさん2010/04/24(土) 02:20:51
>>189
そういう現状に即さない田舎OSは勘弁して欲しいな。
ファイル名がバイト列で良いならテキストファイルもバイト列として扱えるはずって事になる。
これがどれだけ無知で間抜けで短絡的かは言うまでもない。
0194デフォルトの名無しさん2010/04/24(土) 02:42:49
Windowsとかパソコンに弱い初心者向けだからgitとかは対応しなくていいよ
それにWinならSubversionがあるしな
0195デフォルトの名無しさん2010/04/24(土) 02:43:38
× 言うまでもない
○ 俺はバカだから説明できないが絶対正しいに決まってる
0196デフォルトの名無しさん2010/04/24(土) 03:38:05
>>195
それは流石に苦しいぞｗ
0197デフォルトの名無しさん2010/04/24(土) 04:02:01
gitのマルチバイト問題はUTF-8 cygwinでイケル！かと思いきや、
git-guiやgitkが文字化けしたり、文字化けしたのはファイル指定でエラーおこしたり散々ｗ
コマンドラインで使う分には問題ないんだがなあ。


githubもマルチバイトファイル名のファイルつっこむとファイルリストからクリックして見られなかったり、
たまにサーバーエラー起こすしｗ
githubにはエラーでたページからレポートしてるんだけどなかなか直してくれない。
github自身のissue トラッカーってないの？
0198デフォルトの名無しさん2010/04/24(土) 04:52:54
winユーザーがgit使えなくて嫉妬するスレになってるな
問題沢山あるからgit使うのはやめとけ
0199デフォルトの名無しさん2010/04/24(土) 05:12:27
文字コードにまともに対応できない無能集団が>>194見たいな事言っちゃってる姿がウザいんだよ
0200デフォルトの名無しさん2010/04/24(土) 07:18:42
まあ全世界から見たら「日本語の」「windows」なんて
田舎環境を使っている方が悪いんだよ
0201デフォルトの名無しさん2010/04/24(土) 08:07:41
果たしてwinだけの問題であろうか。
ファイル名を単なるバイト列としか扱ってないことを続けて良いのか。
0202デフォルトの名無しさん2010/04/24(土) 08:11:44
>>201
それは、そもそも、このスレで取り上げる主旨じゃない→スレ違い。
0203デフォルトの名無しさん2010/04/24(土) 08:18:00
>>200
「日本語の」だと？
馬鹿も大概にしろ
0204デフォルトの名無しさん2010/04/24(土) 13:36:49
>>200
馬鹿現るｗ
0205デフォルトの名無しさん2010/04/24(土) 14:14:57
英語以外はみんな問題あるだろ。
でも変換なしにがしがし書ける英語っていいよな。
0206デフォルトの名無しさん2010/04/24(土) 15:20:28
問題はおまいらだ
0207デフォルトの名無しさん2010/04/24(土) 18:15:20
winでgit使いたいなら使えばいいんだよ
ただ日本語のファイル名付けるバカで低脳な奴はSubversionにしとけ
日本語名付けるやつほど迷惑な奴もいないよな
0208デフォルトの名無しさん2010/04/24(土) 18:23:50
日本語ファイル名が馬鹿で低脳かは、TPOによるだろ。
米国人主体でプログラム開発してるなら、日本語ファイル名なんて論外だろうけど、
日本人主体のプロジェクトで、プログラマ以外のスタッフの方が多い
ゲームとか書籍製作で使うなら、日本語ファイル名禁止なんていうほうが論外だし。
そういうこと考えずに自分の狭い視野だけで低脳と決め付けるほうが低脳。
0209デフォルトの名無しさん2010/04/24(土) 19:05:31
別に日本語のファイル名つけても問題ないけど…
ただWindowsでおかしいだけでしょ？
0210デフォルトの名無しさん2010/04/24(土) 19:34:49
いい加減うざいんだが
0211デフォルトの名無しさん2010/04/24(土) 21:05:17
正直ドキュメントは、怪しい英語より日本語ファイル名を的確につけて欲しい
そんなものをgitに放り込むなってのは正しいんだろうが、gitとsvnの両用ってのも無駄に感じる
要はそんなとこだろ
なんでそんなにマルチバイト対応が後回しになるんだろってのは気になるな
0212デフォルトの名無しさん2010/04/24(土) 21:54:01
そりゃ単にファイル名を人間が読み取る文字列だと思ってないからでは。
0213デフォルトの名無しさん2010/04/25(日) 01:26:28
ここ見てると、一般にユーザーにバージョン管理の機能を落とし込んだDropboxがまさに対照的でおもしろいな。
馬鹿でも使えてTortoiseSVNよりももっと簡単（機能は少ないけど）
サーバー自前で立てる必要もない(むしろLAN用に立てさせろてほしいが)
Python利用のクライアントだがWindowsでも日本語ファイル名もOK。

IDとパスのみでネットのストレージにおくからと情報漏えいが不安な人にも暗号化ドライブ作成のTrueCryptとの併用で安心。
Dropboxはバイナリは差分とって送信するので数百MBの暗号化イメージ作って、
その中の1ファイルを更新しても軽やかに同期とられる。
コンフリクトは知らんがｗ

見た目はファイル共有の側面が強いが、開発者インタビューではバージョン管理をもっと手軽に
（多分このスレでは相手にしてないデザイナさんや事務職の人相手にも）ってのを売りだといってたよ。
0214デフォルトの名無しさん2010/04/25(日) 01:35:53
DropboxとSubversionを比較するのが間違い
0215デフォルトの名無しさん2010/04/25(日) 03:45:30
>>208
「日本語ファイル名禁止なんていうほうが論外」なんて言うのも低脳だな
日本語ファイル名を付ける可能性があるならgitなんて使わせないのが正解

問題が起こる可能性があるのを説明も出来ないのかお前は
説明したのに使う事になってるならそんな馬鹿な奴らほっとけ
0216デフォルトの名無しさん2010/04/25(日) 03:51:35
>>215
馬鹿はお前
gitが直せば良いだけの話に何を言ってるんだ？
0217デフォルトの名無しさん2010/04/25(日) 05:31:08
・〇〇という奴はバカで低脳
・〇〇なんて論外

そろそろ、釣られる奴は低脳くらいいってもいいころあい
0218デフォルトの名無しさん2010/04/25(日) 08:53:23
結論出ない議論を繰り返すよりgitでfilepathをUnicodeに変換して保存するコードを書いた方が建設的だわな
本家で受け入れられなくてもforkすればいいだけだし
0219デフォルトの名無しさん2010/04/25(日) 08:54:23
>>215
>日本語ファイル名を付ける可能性があるならgitなんて使わせないのが正解
いや、
>日本語ファイル名禁止なんていうほうが論外
は、ほぼそういう意味で書いたんだが。
なんか勘違いしてね？

0220デフォルトの名無しさん2010/04/25(日) 10:20:30
バカに正常な読解力を期待するからこうなるのだ。
0221デフォルトの名無しさん2010/04/25(日) 10:52:09
>>213
RCSならリポジトリも作らずにその場で今の状態を取っとけるじゃん
自分は今でもたまに使ってる
0222デフォルトの名無しさん2010/04/25(日) 10:56:09
Windowsとかよく知らないし
0223デフォルトの名無しさん2010/04/25(日) 13:30:20
Linuxとかよく知らないし
0224デフォルトの名無しさん2010/04/25(日) 13:40:51
わかった。

Q. git で日本語ファイル名が使えません。

に対して、

A1. 日本語ファイル名を使いたいなら Subversion とかの他の VCS を使え派

と

A2. git が日本語ファイル名に対応しろ派

と

A3. 日本語ファイル名を使うな派

がいるのな。

0225デフォルトの名無しさん2010/04/25(日) 13:43:10
Unicodeとかよく知らないし
0226デフォルトの名無しさん2010/04/25(日) 13:46:48
日本語とかよく知らないし
0227デフォルトの名無しさん2010/04/25(日) 13:52:52
>>224
× Q. git で日本語ファイル名が使えません。
○ Q. Windowsでgitを使うと日本語ファイル名が使えません。
0228デフォルトの名無しさん2010/04/25(日) 15:43:39
× Q. git で日本語ファイル名が使えません。
× Q. Windowsでgitを使うと日本語ファイル名が使えません。
○ Q. Windows-Linux間でgitを使うと日本語ファイル名が化けます。
0229デフォルトの名無しさん2010/04/25(日) 17:01:24
問題なのはwinでgitを使いたいと思ってる奴がこのスレに来てる事
win用じゃないんだから諦めてsvn使いなよ
gitに執着してるようだけど馬鹿みたいだよ？
0230デフォルトの名無しさん2010/04/25(日) 17:24:01
>>229
>問題なのはwinでgitを使いたいと思ってる奴がこのスレに来てる事
え？何で問題なの？理由は？
0231デフォルトの名無しさん2010/04/25(日) 17:25:00
自分も含めたグループに使わせたい場合とか考えないんだろうな。
自分のことしか考えてないか、一人でしか仕事してないか。
0232デフォルトの名無しさん2010/04/25(日) 17:26:32
そもそも仕事したことが無いんだと思うよ
0233デフォルトの名無しさん2010/04/25(日) 18:03:02
gitスレはLinux板にあるってのもなｗ
0234デフォルトの名無しさん2010/04/25(日) 18:12:52
OSSに関わってたり、Windowsを開発機にしてUnix鯖のwebアプリ作ってたりするとそうもいかない。
今時「win用じゃないんだから」はナンセンスじゃないか？
まー、Unix鯖で動くアプリ作るときは結局仮想マシンつかうし、その上でgit動かす分には問題ないかｗ
0235デフォルトの名無しさん2010/04/25(日) 18:38:57
なんのためにgitが生まれたか知らずに語っている奴が混じってないか?
0236デフォルトの名無しさん2010/04/25(日) 18:45:22
つまりMercurialも同様ということだな
0237デフォルトの名無しさん2010/04/25(日) 20:58:17
>>231
他人の事を考えるならgitなんか使うな
それこそSubversion使うだろ普通
0238デフォルトの名無しさん2010/04/25(日) 21:28:38
どんな普通だよｗ
0239デフォルトの名無しさん2010/04/25(日) 21:29:56
でもさー、日本語ファイル名使うようなファイルってWordとかExcelみたいな、
そのへんのバージョン管理システムのdiffサブコマンドじゃーどうにもならない
ファイルばっかりだし、それこそファイル名に日付でも付けた状態でそのまま
ファイルサーバに置いて管理して欲しいと思う……

どーせMS Officeってファイル内部で変更履歴管理できるのばっかりだろうし。

あ、プログラムのファイル名に日本語使う人は死んでいいから。
0240デフォルトの名無しさん2010/04/25(日) 21:31:44
マルチプラットフォームで日本語ファイル名も使うプロジェクト、
という前提での「普通」だろ？
0241デフォルトの名無しさん2010/04/25(日) 21:48:26
そういうプロジェクトでgitを使ってはいけない理由って別にないよね。

結局、gitは日本語ファイル名がうまく扱えないという現実を
「不具合だから直すべき」ととらえる人と、
「そういう風になっているソフトでわざわざ想定外の使い方をしなきゃいいのに」
と思ってるひととでは永久に相容れないと思う。
0242デフォルトの名無しさん2010/04/25(日) 23:12:55
>>239
>あ、プログラムのファイル名に日本語使う人は死んでいいから。
業務プログラムのテストケースとかだと普通にあるけどな。
"要件XXX-価格決定-特定得意先別値引率適用Test" みたいな。
0243デフォルトの名無しさん2010/04/25(日) 23:47:17
＞結局、gitは日本語ファイル名がうまく扱えないという現実を
日本語Windowsでの話だろそれ。自分の環境を前提に何でも話通そうとするなよ。
0244デフォルトの名無しさん2010/04/25(日) 23:56:00
>>224
× git が日本語ファイル名に対応しろ派
○ git を日本語ファイル名に対応させろ派
0245デフォルトの名無しさん2010/04/26(月) 01:09:39
つまり、要約すると、早い話が、gitは国際化対応できないって事で、FA?
0246デフォルトの名無しさん2010/04/26(月) 01:13:08
日本語をgitに対応させろ派も旗揚げ
0247デフォルトの名無しさん2010/04/26(月) 01:24:25
だからgitは世界のシェアの2%のLinuxの、そのまた更にシングルバイト圏でしか使う事ができない田舎アプリなんだよ
もう何も期待すんなよ
0248デフォルトの名無しさん2010/04/26(月) 01:30:12
gitのWindowsでの日本語ファイル名問題だけでここまで引っ張るのはすごい

>>247
シェア高いのって何？やっぱりSVNやCVSなのかな
0249デフォルトの名無しさん2010/04/26(月) 02:36:54
gitすげーさいこーっていう流れの反動と、svnみたいに簡単に
使えないことへのがっかり感とが怨念っぽくなってるんだろ
0250デフォルトの名無しさん2010/04/26(月) 03:56:16
>>249
まあ、バージョン管理システムて基本大勢で使う為の物になってしまったから、
バージョン管理システム自体の「癖」を気にしながら使わなきゃなのわ。
ちょと、辛いよね。
0251デフォルトの名無しさん2010/04/26(月) 04:13:17
問題はgitユーザーがとにかくSVN等を馬鹿にしていて
SVNがWindowsや文字コードに完全対応している事すら何故か見下し馬鹿にすると言う意味不明な行動を取っている事じゃなかろうか。

gitユーザーが最初に怨念染みたネガ波動を全方位に振りまいてんだから、それがそっくりそのまま帰ってきてもあたり前だろうに。
0252デフォルトの名無しさん2010/04/26(月) 05:57:16
gitスゲー他のvcsは全部糞git最強とか繰り返してるのを見てwktkしながらgitを試してみたら

導入第一歩であっけなく文字化け

それはもう遣る瀬無い気持ちになったとさ
0253デフォルトの名無しさん2010/04/26(月) 07:36:07
>>224
gitもSubversionもどうでもよくて、煽り合いたいだけの奴らが少なからず混じってるだろう
0254デフォルトの名無しさん2010/04/26(月) 08:02:24
暇で必死なバカが一人いるな、という感じに見える
0255デフォルトの名無しさん2010/04/26(月) 09:23:08
>>245
つまりはそういうことだね。
0256デフォルトの名無しさん2010/04/26(月) 09:55:09
仮にファイル名だけ文字コード変換したとしても、
Makefileみたいにファイル名を直に書いているファイルがあるとうまくいかなくなるよな

ファイル名だけじゃなくてファイルの内容まで含めた包括的な文字コード変換の仕組みが必要なんだけど
どのエンコーディングからどのエンコーディングに変換すればいいかがいまいち自明じゃない
変換失敗のときにどう動作すればいいのかとか、
文字コード変換しなくていいファイルはどう指定すればいいのかとか、
問題は山積している

だからそういう問題を忘れて、POSIX APIを仮定して（ファイル名＝バイナリ文字列）プログラムを書くというのは
それなりにわかりやすい態度だと思うのよね
0257デフォルトの名無しさん2010/04/26(月) 09:56:08
GNU周りってモノはそんな悪くないんだけど、コミュニティが最悪にガキ臭いよね。
Gitが文字コード問題に取り組まないのも、大嫌いなWindowsに関わる事なんざ知ったこっちゃ無いと言う小学生レベルの理由以外は何も無いし。
0258デフォルトの名無しさん2010/04/26(月) 09:59:09
>>256
ファイルの中身のエンコーディングについてはバージョン管理システムは関係ないだろう。
勝手にごっちゃにして実際に発生している問題を正当化する材料にするのはおかしくないか？
0259デフォルトの名無しさん2010/04/26(月) 10:01:12
>>256
OS含め全てがマトモに文字として扱っている限りはそんな下らん問題は発生しない
問題が発生するのは、どっかのタコプログラムが文字列(ファイル名等)をただのバイト列として扱うから
0260デフォルトの名無しさん2010/04/26(月) 10:14:51
>>259
> マトモに文字として扱っている

マトモな文字の扱いかたをしてるものって、EmacsとRubyぐらいしかないんじゃね？
OSなんか全滅だろ。
0261デフォルトの名無しさん2010/04/26(月) 10:25:51
うん、Unix派生OSは全滅だね
0262デフォルトの名無しさん2010/04/26(月) 10:29:22
つまりgitは無責任にOSに文字列の扱いを丸投げしているだけで
実際に文字化けを起こしているのはLinuxとかのタコOSなんだよ
0263デフォルトの名無しさん2010/04/26(月) 10:52:33
>>257 gitはGNUが作ってるわけじゃないけど。
0264デフォルトの名無しさん2010/04/26(月) 11:39:20
>>251
確かにLinusはSubversionをバカにしたけど、Windowsで日本語ファイル名がダメ
とかっていうのは、単純にWindows使わないから知らんがなーなだけ
だと思う。Windowsダッセーとかっていうのは昔から言ってるしね。別の話だよ。
0265デフォルトの名無しさん2010/04/26(月) 18:34:22
gitに興味持ってこのスレ覗いたwinユーザーは安易にgitを使わないで下さい。

winでは文字化けします。

勝手に導入すれば周りに迷惑を掛けるのがオチです。

導入したいならWindowsを捨ててください。
0266デフォルトの名無しさん2010/04/26(月) 20:12:28
日本語を捨てるのが先

または、全部ローマ字でkakebaZenbuKaiketsuDesu.
0267デフォルトの名無しさん2010/04/26(月) 20:58:06
同じマルチバイトの中国語や韓国語は問題ないの？
0268デフォルトの名無しさん2010/04/26(月) 21:26:16
田舎アプリユーザーはASCII以外興味ないんです
無理言わないであげてください
0269デフォルトの名無しさん2010/04/26(月) 22:23:45
>>267
ASCII Onlyでないやつはすべて問題あります
それでも日本がダメだと言い張るのがこのスレのクオリティー
0270デフォルトの名無しさん2010/04/26(月) 22:31:34
gitはlinuxどうしでもlocaleが違うとだめだよね
0271デフォルトの名無しさん2010/04/26(月) 22:32:19
Linuxが糞なだけでgitは悪くないっしょ
0272デフォルトの名無しさん2010/04/26(月) 22:48:09
Linuxの世界ではファイル名は文字列じゃなくてバイト列なんだよ
（'\0' と '/' 以外の任意のバイトが使える）

これはバグとかそういう問題じゃなくてただの文化の衝突だからどうにもならん
0273デフォルトの名無しさん2010/04/26(月) 23:10:42
そんなん何十年も昔の妥協点を未だに引きずってるだけの話でしょ
文化の衝突じゃなく、単にコミュニティがascii以外に興味が無いだけとしか思えない
0274デフォルトの名無しさん2010/04/26(月) 23:23:55
http://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-007ACA9B
Windowsの方も、アプリケーションにSJISでファイル名を渡してくるような状況を変えられないとねぇ…
0275デフォルトの名無しさん2010/04/26(月) 23:25:40
あと、そもそもLinuxはOSがロケールにアクセスしないから
システムコールレベルで文字コード変換を云々するのはそもそも不可能だな
0276デフォルトの名無しさん2010/04/26(月) 23:32:16
>>274
知らんなら黙れ
SJIS自動変換は当たり前にOFFにできる
0277デフォルトの名無しさん2010/04/26(月) 23:43:22
>>276
offってどうやるの？
別関数使うならわかるけど
0278デフォルトの名無しさん2010/04/26(月) 23:46:46
馬鹿には見えないマクロ郡を使って
0279デフォルトの名無しさん2010/04/26(月) 23:59:30
.netのSystem.Diagnostics.Processで引数としてファイル名をUTF-8で渡す方法は？
0280デフォルトの名無しさん2010/04/27(火) 00:04:04
突然関係ない都合の良い話を始めるのはgit病の症状なの？
0281デフォルトの名無しさん2010/04/27(火) 00:07:10
Git脳の恐怖
0282デフォルトの名無しさん2010/04/27(火) 00:14:44
>>280
ファイル名関連はBzr病だと思う
0283デフォルトの名無しさん2010/04/27(火) 00:49:18
OSがファイル名をUnicodeとして管理している場合と
OSがファイル名をただのバイト列としか思ってない場合とじゃリスクは比べるべくも無い
0284デフォルトの名無しさん2010/04/27(火) 01:51:17
ここで修正パッチも出さずに、gitがWindowsでうんこといっても
暗にhgもクソ、Bzrマンセーしているようにしか見えないし
0285デフォルトの名無しさん2010/04/27(火) 01:55:35
せっかく賑わってきたので現実的な解決方法を話しあいたい。

ぶっちゃけアドホックでもいいので
「Windowsで(UTF-8なcygwin環境以外でも)日本語ファイル名が
他のプラットフォームと相互運用してもSubversion並に問題ない」というような
（↑要点あってるよね間違ってたら言って)
現実的な解決方法って何かないもんなんでしょうか？
Windowsユーザー的にはツールはTortoiseGitとmsysgit辺りでなんとかなればいいんだと思う。
0286デフォルトの名無しさん2010/04/27(火) 03:25:13
身も蓋もないことを言うようだが、TortoiseとかでGitやっても、Subversionと同じ使い方しか
しないような気がする。そんなことない？　失礼しました。
0287デフォルトの名無しさん2010/04/27(火) 08:12:44
>>286
同じじゃだめなの？
コミットがローカルにされて、pushとpullを覚えるくらいのイメージなんだが。
ブランチだなんだと面倒なことは慣れてから理解。

いきがってstashとか使ってたら大昔のやつをpopしてしまって
コンフリクトの嵐。戻し方がわからず泣きそうになった。resetとか怖い
0288デフォルトの名無しさん2010/04/27(火) 08:35:27
gitはrebase -iで履歴を組み換えるのが楽しいぞ。
0289デフォルトの名無しさん2010/04/27(火) 12:17:17
>>285
>>110

Mac問題はシラネ
0290デフォルトの名無しさん2010/04/27(火) 13:19:59
>>287
いや、ダメっていうか、svnと同じ使い方しかしないのなら、移行にかかる学習コストや
既出の障壁なんかを考えると、無理に導入する必要あるのかな、と。
0291デフォルトの名無しさん2010/04/27(火) 15:40:38
なんども言われてる事だと思うけど>>285みたいなのはSubversion使うべき
無理にgit導入すれば周りから迷惑な奴と思われてしまうよ
さらにgitの文字コード問題を知ってる奴から見たら馬鹿な奴と思われるだけ
0292デフォルトの名無しさん2010/04/27(火) 15:56:53
なぜ無意味に上に立ちたがるのか
0293デフォルトの名無しさん2010/04/27(火) 16:32:19
subversionなら日本語ファイル名の相互運用が問題ないっていう妄想はどこからくるわけ?
0294デフォルトの名無しさん2010/04/27(火) 23:29:45
>>293
ja_JP.UTF-8 のDebianで「十表.txt」を作成、svnでコミット。
これをWindowsのTortoiseSVNでチェックアウト。問題なし。もちろん逆も。

これくらいのことなら、もちろんGitでもできるんだよね。
これくらいのことが普通にできればそれでいいんだよ。
0295デフォルトの名無しさん2010/04/27(火) 23:42:52
>>290
・ 全ディレクトリに.svnが作られ、ディレクトリのコピーが気楽にできない。
ネストしたディレクトリのコピーとか、結構面倒。そのままコミットするとsvnが錯乱する
・ 全ての編集が毎度中央レポジトリにされるので、一時保存的なコミットができない。
　 なんか恥ずかしいし、あとから見たらゴミでしかない。
・ やっぱり、ネットが切れててもコミットしたい状況はある。

別にgitじゃなきゃいけないわけじゃないけど、この辺はなんとかしたい。
0296デフォルトの名無しさん2010/04/27(火) 23:46:05
終了してしまったけど、svkはローカルリポジトリの履歴を
上流にpushするときに改変できたりしないの?
0297デフォルトの名無しさん2010/04/28(水) 01:04:28
>>296
svkはできるよ。svnリポジトリ間のマージにも重宝する。
ただ、けっこうかなり重たいんだよな。。。
でも
* .svnは無い
* ローカルコミット可能
* リモートにpushする時にまとめたり出来る
ってのは>>295の要望には合ってそうだね。
0298デフォルトの名無しさん2010/04/28(水) 01:07:07
svnの延長として分散型使いたいならBzrは悪くない
0299デフォルトの名無しさん2010/04/28(水) 01:27:36
逆に、Bazaarは何がイケてないんだろ
使い方が難しいのかな
0300デフォルトの名無しさん2010/04/28(水) 02:17:43
まあ、後発だからな > bzr
0301デフォルトの名無しさん2010/04/28(水) 06:08:21
社内のバージョン管理をgitで統一しようと思う
日本語ファイル名禁止のメールを全員に送らにゃならんが
0302デフォルトの名無しさん2010/04/28(水) 09:10:53

　　　　　　　　　　 　 ｜
～～～～～～～～｜～～～～～～～～～～
　　　＞( c´_ゝ`)　　｜
　　　　　　　　　　　 ｜
＞( c´_ゝ`)　　　　　J
　　　　　＞( c´_ゝ`)



　　　　　　　 　　　　 ｜
～～～～～～～～｜～～～～～～～～～～
　　　　　　　　 　　　 ｜　　　　　＞( c´,_ゝ`)
　　　　　　　　 　　　 ｜
　　　　　　　　　 　　 J　　　＞( c´,_ゝ`)
　　　　　　　　　　　　　　　　　　　　＞( c´,_ゝ`)
0303デフォルトの名無しさん2010/04/28(水) 10:20:22
>>299
何でもできるような余地(集中型・分散型どっちもおkとか)を残しすぎてて、
内部の動作を理解しないと使いにくそうに見えるところ。
リポジトリとブランチは別物とか言われても、「なにそれこわい」にしかならんと思う。
0304デフォルトの名無しさん2010/04/28(水) 23:00:33
>>299
むしろ逆。普段からgithubとか使ってるとなんでgitじゃねーんだよ！って感じになる

まあ、仕事でWindowsだとBazaar、趣味やOSS開発だとgitとつかいわけてもいいんだが
0305デフォルトの名無しさん2010/04/29(木) 00:15:35
>>303
> 内部の動作を理解しないと使いにくそうに見える
これはまさにgitにも言えることではないかと思うんだが、gitはあれでシンプルなのか？
rebaseとか言われた時点で、あ、これ無理とか引いてしまう
0306デフォルトの名無しさん2010/04/29(木) 00:34:08
構造的に最もシンプルなのはgitだろう
だからといって使う人が理解しやすいかということは別問題
0307デフォルトの名無しさん2010/04/29(木) 00:38:24
gitはresetでコミットが消えるとか言われた
コミットが消えるバージョン管理とか、なにそれこわい
どこかには残ってるんだよねそう言ってよママン
0308デフォルトの名無しさん2010/04/29(木) 01:42:38
正直gitには、
ttp://d.hatena.ne.jp/idesaku/20091106/1257507849
こういう情報がもっと一般的に、大量に、言い換えれば懇切丁寧に、公式に、これくらい柔らかく必要だ
0309デフォルトの名無しさん2010/04/29(木) 02:34:12
>>285
msysgitはどうにもならないと思う。
TortoiseGitのバックエンドをcygwin版gitにする方が見込みがありそう。
0310デフォルトの名無しさん2010/04/30(金) 23:17:18
gitは趣味に留めて業務で使わないでくれよおまいら
0311デフォルトの名無しさん2010/05/01(土) 04:20:22
Gitはおもちゃだし
0312デフォルトの名無しさん2010/05/01(土) 10:48:38
そのおもちゃをソースコード管理に使っているLinuxはしょせんおもちゃプロジェクトであり
シェアなど1%前後で十分ってことだ
ttp://marketshare.hitslink.com/os-market-share.aspx?qprid=9
0313デフォルトの名無しさん2010/05/01(土) 20:46:02
↑Winユーザーの嫉妬はみっともないな
0314デフォルトの名無しさん2010/05/01(土) 21:23:18
↑おもちゃユーザーの嫉妬はみっともないな
0315デフォルトの名無しさん2010/05/02(日) 10:25:41
mercurial-1.5.2.tar.gz
0316デフォルトの名無しさん2010/05/02(日) 12:14:04
なぜ hg のスレに書かずに、ここに。
0317デフォルトの名無しさん2010/05/02(日) 15:00:34
バカなWinユーザーがいつまでもgitに嫉妬してるからです
早く別のを使えばいいと思います
0318デフォルトの名無しさん2010/05/02(日) 15:20:47
↑gitがこんな考えしてるから無駄に叩かれるんだよ
0319デフォルトの名無しさん2010/05/02(日) 15:55:37
前のほう読むと、Windowsに対応してないとか意味わかんない！　って突っかかってるように見えるが
0320デフォルトの名無しさん2010/05/02(日) 16:00:31
gitにshit
yeah
0321デフォルトの名無しさん2010/05/02(日) 17:09:04
>>319
0322デフォルトの名無しさん2010/05/02(日) 18:09:12
>>319
そんなのLinuxをおもちゃとか言ってるバカの粘着だけだよ
お子様にはsvnを使ってもらいたいねぇ
0323デフォルトの名無しさん2010/05/02(日) 20:18:32
ほら、無駄にsvnを見下してる
文字コード問題とか言う初歩的なバグを直せていないのにコレだよｗ
0324デフォルトの名無しさん2010/05/02(日) 20:23:10
良いと思うならメリットを論じれば良いのに
0325デフォルトの名無しさん2010/05/02(日) 20:55:02
>>323
バグじゃなく、実装されてないだけ
その違いがわからないならム板でレスしないでね
0326デフォルトの名無しさん2010/05/02(日) 21:41:47
仕様って素敵やん
0327デフォルトの名無しさん2010/05/02(日) 23:55:12
>>325は確実にMSの「仕様です」回答を散々馬鹿にした奴らの一人
0328デフォルトの名無しさん2010/05/03(月) 00:49:44
仕様よ仕様。でもちょっとだけ仕様じゃないの。
0329デフォルトの名無しさん2010/05/03(月) 01:47:39
仕様バグって奴か。
一番深刻だな。
0330デフォルトの名無しさん2010/05/03(月) 01:57:40
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
仕様って事にしたいんですね、わかりますん。
0331デフォルトの名無しさん2010/05/03(月) 02:16:06
つーか想定外の用途なので欲しい人頑張って。

0332デフォルトの名無しさん2010/05/03(月) 02:20:39
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
想定外の用途って事にしたいんですね、わかりますん。
0333デフォルトの名無しさん2010/05/03(月) 02:38:09
問: gitは何のために作られましたか?
0334デフォルトの名無しさん2010/05/03(月) 02:43:15
Linuxで使えればOKと思われている以上……ね。
ttp://www.garbagecollect.jp/~usa/d/200904b.html#id20090417_P1
# 1年前のエントリだが。
0335デフォルトの名無しさん2010/05/03(月) 02:59:22
>>332
特定のOSの開発用に作ったバージョン管理システムが、とあるプラットフォームで
動かないからクソだって罵るのは別に自由だし、他のを使えば済むことだし、
あなたの意見はよく分かったから勝手にして欲しいんだけど、いつもまでも同じ主張を
延々とやられるとウザったいからもういいよ。
0336デフォルトの名無しさん2010/05/03(月) 03:00:45
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
特定のOSの開発用に作ったって事にしたいんですね、わかりますん。
0337デフォルトの名無しさん2010/05/03(月) 03:07:29
こいつもうただの荒らしだな。
Gitが何を目的にして作られたのか知らないのか？
0338デフォルトの名無しさん2010/05/03(月) 03:25:26
要するに不用意にWindows版作ったgit開発者が悪い
0339デフォルトの名無しさん2010/05/03(月) 03:35:33
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
Gitが何を目的にして作られたのか知らないのか？って事にしたいんですね、わかりますん。
0340デフォルトの名無しさん2010/05/03(月) 03:55:40
結論は>>338
0341デフォルトの名無しさん2010/05/03(月) 04:16:02
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
ベースではなくWindows版だけが悪かったって事にしたいんですね、わかりますん。
0342デフォルトの名無しさん2010/05/03(月) 04:38:33
>>331
こういうこと言ってる奴ほどMSのこういう態度を批判するんだよなｗｗｗ
0343デフォルトの名無しさん2010/05/03(月) 06:16:26
>>342
MSの場合ソースコード非公開だから、頑張りようがないと思うが
0344デフォルトの名無しさん2010/05/03(月) 06:25:26
ん？頑張って他に移ってねって話では？
散々svn使えって言ってきてるじゃん
0345デフォルトの名無しさん2010/05/03(月) 06:32:11
つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
svnはクソだからgitを造ったのに結局使うなって事にしたいんですね、わかりますん。
0346デフォルトの名無しさん2010/05/03(月) 14:56:31
言い出しっぺの法則というものがありましてね
0347デフォルトの名無しさん2010/05/03(月) 15:42:31
そうだね、Windows版作ろうとか言い出した奴は最後まで責任持たないとね
0348デフォルトの名無しさん2010/05/03(月) 15:59:17
>>345
gitに嫉妬してここで文句言えば誰かがgitをWin用に対応してくれるとでも
思ってるだろお前？
幼稚なコピペばかり繰り返して頭悪いんじゃない？
造ってる人間達に能力がない為と言うなら自分で対応しろよ
0349デフォルトの名無しさん2010/05/03(月) 16:41:53
嫉妬とかそういうくだらん発想で会話するから、馬鹿にされるんだよ
0350デフォルトの名無しさん2010/05/03(月) 17:26:45
ここで暴れているのってgitばっかりのような気がする。
0351デフォルトの名無しさん2010/05/03(月) 17:54:53
信者が必死なんだろ
0352デフォルトの名無しさん2010/05/03(月) 18:29:17
誰がどう見てもアンチが必死
0353デフォルトの名無しさん2010/05/03(月) 18:46:21
日本語表示できないのは事実なんだから適当に流せばいいのに
いちいち言い返さないと気がすまないもん同士でエスカレートしてるだけ
0354デフォルトの名無しさん2010/05/03(月) 19:05:15
誰か他の話題たのむ。

CVSの話でもするか。
0355デフォルトの名無しさん2010/05/03(月) 19:37:18
ミンナダイスキ
IBM Clear Case
0356デフォルトの名無しさん2010/05/03(月) 19:51:51
で、ちょっと分散型のを使ってみようかとなったら、
・WinでもLinuxでも
・日本語ファイル名なんざ金輪際使わねぇなんてポリシーは無い
って場合には、gitは駄目で将来的にも直りそうに無いということは
分かりました。

とすると、マーキュリアルとかいうのとバザールでござ～るの
どっちが良いんでしょうか。
0357デフォルトの名無しさん2010/05/03(月) 22:57:01
>>356
その二択なら、迷わずbzrを取った方がいいような気がする。
両方コミュニティの雰囲気とかよく知らないけど。
hgのgitに対する優位って何かあるの？
0358デフォルトの名無しさん2010/05/03(月) 23:17:08
hgも日本語対応のパッチはrejectされたんじゃなかったっけ？
まともに期待できるのはbzrしかなさそう
0359デフォルトの名無しさん2010/05/04(火) 00:05:21
>>357
hgはgitと比べたら、基本的にpythonだけで動くところと、コマンドラインで
使いやすいのがメリットかな
0360デフォルトの名無しさん2010/05/04(火) 00:24:36
そのマニアックな利点を利点と感じられる人間は、ぶっちゃけ何でも使えるだろ
gitと同じ日本語問題を抱えてるなら、乗り換え先として魅力はかなり少ないような

ちょっと本腰いれてbzr使ってみるかな
bzrは、以前触ったときにはTortoiseよりもむしろBazaar Explorerがいい感じだと思った
あとはCUI出力(log とか status)に色が付けられたら、たぶん文句なく使えそう
0361デフォルトの名無しさん2010/05/04(火) 02:06:41
「日本語対応」とか言ってるから、git儲がいつまでも付け上がるんだぜ。
「国際化対応」と言えば、もちろん「できない・やらない方が悪い」。
つまり、git儲は視野が狭い独善的な国際的悪者なのだ！
0362デフォルトの名無しさん2010/05/04(火) 03:45:38
またバカが来たよ
0363デフォルトの名無しさん2010/05/04(火) 04:13:32
よっぽど恨みに思うようなことがあったんだろうな
0364デフォルトの名無しさん2010/05/04(火) 05:06:01
国際的患者に見えたわ
0365デフォルトの名無しさん2010/05/05(水) 08:32:21
Git と Mercurial が Subversion より優れている点 - tcha.org
http://tcha.org/blog/2010/02/01/dvcs-over-svn/
0366デフォルトの名無しさん2010/05/05(水) 09:07:04
Subversionが（現状）GitやMercurialより優れている点

・ 変更の確認…アイコン見るだけ。diff・mergeは右クリックでWinMergeU
・ その他のほぼ全ての操作…右クリックでごにょごにょ

何を言っても、全てはこれに尽きるだろ。

あと、Gitは自動マージに頼りすぎで、衝突の解決をさせる強制力が弱い気がする。
なんでもかんでも add . でコミットできてるんじゃねーよ。これは使う人間次第だろうけど。
0367デフォルトの名無しさん2010/05/05(水) 10:15:29
>>366
それはTortoiseSVNの機能。Subversion自身にそんな機能は無い。
0368デフォルトの名無しさん2010/05/05(水) 10:27:56
早くGitにもすてきGUIを作ってくれよ
0369デフォルトの名無しさん2010/05/05(水) 10:43:31
>>368
あっても無駄だろ。
ファイル名を文字として認識して無いという国際化対応での駄目っぷりが直らない限り。
0370デフォルトの名無しさん2010/05/05(水) 11:08:41
gitみたいな複雑な利用をするものほど、GUIの恩恵は大きいと思うんだ

git reset は HEADの位置を動かす？ おｋ、今どこにいるの？
git stash で修正をスタックに棚上げ出来る？ おｋ、今どれだけ積んでいて、どれが何時の分？
branch が基本で今時のSCMには必須？ おｋ、どこからどうやって分かれて今どうなってるの？

みたいなのが、結局記憶ベースかコマンドからのテキスト読解もしはハッシュコピペベースって、
お世辞にも使いやすいとは言えない
0371デフォルトの名無しさん2010/05/05(水) 11:23:40
>>368
つTortoiseGit
0372デフォルトの名無しさん2010/05/05(水) 11:51:24
>>366
> 366 名前：デフォルトの名無しさん [sage]： 2010/05/05(水) 09:07:04
> Subversionが（現状）GitやMercurialより優れている点
>
> ・ 変更の確認…アイコン見るだけ。diff・mergeは右クリックでWinMergeU
> ・ その他のほぼ全ての操作…右クリックでごにょごにょ
>
> 何を言っても、全てはこれに尽きるだろ。
>
> あと、Gitは自動マージに頼りすぎで、衝突の解決をさせる強制力が弱い気がする。
> なんでもかんでも add . でコミットできてるんじゃねーよ。これは使う人間次第だろうけど。

TortoiseHg ならほとんど全部　GUI　で出来る。
コミッタに日本人２人いるから、がんがん要望を日本語であげることもできる。
メニューなどの日本語化も終わっているし。
0373デフォルトの名無しさん2010/05/05(水) 13:01:05
の割にはスレにぎわってないよねえ。
不満がないのかあきらめてんのか。

俺は……まあ両方かな。bzr と併用しつつ様子見。
0374デフォルトの名無しさん2010/05/05(水) 14:51:13
自分はシェルでのCUI操作とgitk(gitリポジトリ履歴ビューア)の併用で慣れてしまったし別に。
他のバージョン管理システムも、そう悪くないんじゃないかとは思うけどね。

日本語ファイル名使えないとヤダヤダ、全部GUIじゃないとヤダヤダって人達とは
今のところは一緒に作業する事は無いし、往々にして困ったちゃんが多い印象があるからなぁ…

使い易いGUIやインストーラなどを整備するのは別に拒まないけど、
個人的には、クレクレ&FUD猿状態の連中にまで仏心を振りまく気概は無いし。
付き合ってストレスばかり感じる相手に、無償で奉仕する義理は無い。

あと、svn/git/hg/bzrに限らずバージョン管理システムのクライアントは
Tortoiseのようなエクスプローラ統合型だけでは無く、
Eclipse/NetBeansなどの統合型開発環境への組み込み型プラグインという形態もあるのだから、
用途によってはGUI等の実現はそちらの方が便利、というケースもあるんじゃ？
0375デフォルトの名無しさん2010/05/05(水) 16:48:32
そんなに内容の無い長文書いてなにがしたいの？
0376デフォルトの名無しさん2010/05/05(水) 16:52:18
批判されないように妥当な事ばかり書いたら何も内容が無かったと言う
0377デフォルトの名無しさん2010/05/05(水) 18:22:07
>>370
俺は逆にマウスでポインタ合わせしまくらないといけないGUIのほうが疲れるな。
コード書きもGUI使わないし、マウスでコミットとか何か間違えそうで怖い。
ただマージが複雑になってくるとgitkみたいなのが無いと理解するのは難しいね。
>>370みたいな人が居るってことは、そのうち使いやすいGUIも誰か作るんじゃない？
0378デフォルトの名無しさん2010/05/05(水) 20:55:45
ちょっと前、Java の Mercurial 環境の試しで、
NetBeans は NetBeans が Mercurial で開発されているので、何もしないで使えた。
Eclipse も結構いい線いってた気がした。
結局、Mercurial はコマンドラインで、Java は maven が一番快適だったが。
0379デフォルトの名無しさん2010/05/05(水) 21:11:58
自分は普段はコマンドラインで使ってるけど、
人のコードを調べたり、人のコードをレビューする時の道具として使うときは
GUIとWebUIの方が楽ちんだな。

0380デフォルトの名無しさん2010/05/05(水) 21:32:11
>>372
Junioって日本人として全く役に立ってないんだねぇ
0381デフォルトの名無しさん2010/05/05(水) 21:55:35
>>372
TortoiseHg前に使っててすごい便利だったけど(部分的にはTortoiseSVNより便利だったところ合った気が)、
Mercurialがマルチバイトファイル名の問題が解決されないので今は様子見中だわ・・・

コマンドラインで使うならUTF-8のcygwin hg使えば解決できるけど、
それならgit使うｗ

>>374 >>378
たまたまSubversionのプロジェクトでNetBeans使ってたら、
SVNに対応されててプロジェクトのファイルビューアーがTotoiseSVNみたいにアイコン変わったり、
エディタで変更箇所示してくれたり便利だったな。

IDEの組み込みは便利なんだが、IDEを変えられないという欠点が…。
言語ごとに適してるIDEがあるから、下手すると言語ごとにバージョン管理システム変えるハメに（はならないかｗ
0382デフォルトの名無しさん2010/05/05(水) 21:57:27
>>380
日本語メールはスパムとして弾いてるほどの人だし
0383デフォルトの名無しさん2010/05/05(水) 22:05:02
>>380
JunioってGITのPLだろ？
0384デフォルトの名無しさん2010/05/05(水) 23:14:39
マルチバイト圏の人間のクセにシングルバイトしか考えないこの有様
一体どれだけ無能なのやら
0385デフォルトの名無しさん2010/05/05(水) 23:33:49
>>382
mjd?
0386デフォルトの名無しさん2010/05/06(木) 01:18:27
>>382 >>384
そういう人じゃなきゃ、gitやhgは馴染まないってことだろ
無理して日本語Windows環境を捨てて開発しなきゃいけないとかおかしい

ぶっちゃけCygwinなんて興味ない人に使わせるの無理ありすぎだ
精々、Macオンリーまでが許容範囲じゃなかろうか
0387デフォルトの名無しさん2010/05/06(木) 09:59:28
いいえ
0388デフォルトの名無しさん2010/05/06(木) 13:35:04
自助努力という言葉が辞書にないのがドザ、ってことだけはよくわかった。
0389デフォルトの名無しさん2010/05/06(木) 13:50:44
Windowsは関係ない
前世紀から使っているようなeucJPのNetBSD機が混在しただけでも破綻する
0390デフォルトの名無しさん2010/05/06(木) 15:58:59
Mac OS Xのように、UTF-8 と UTF-8-MAC という微妙な差異も意外と苦しそう。
（主に濁点・半濁点を用いた平/片仮名文字）
0391デフォルトの名無しさん2010/05/06(木) 17:44:31
>>390
gitやhgをクイックハックでなおすとすると、WindowsよりMac対応のほうが面
倒くさそうだよね
0392デフォルトの名無しさん2010/05/06(木) 18:53:13
MacOSX はそれが本当に面倒でなぁ。
0393デフォルトの名無しさん2010/05/06(木) 23:09:48
エンドユーザに自助努力を要求するようになったら開発者としちゃ下の下。
余計な苦労は無いに越した事はない。
0394デフォルトの名無しさん2010/05/06(木) 23:20:04
例えば誰？
0395デフォルトの名無しさん2010/05/06(木) 23:33:33
NFCとNFDの違いはUnicodeの仕様だから我慢するとして、
他にもMacは文字マッピングが違うところがあるらしいけど、
具体的にドレ?
0396デフォルトの名無しさん2010/05/06(木) 23:44:55
その辺、普通にスレ違いにも程がある話題ではあるんだ

日本人だからまだそれなりにみんな関心あるだろうけど、
git開発者連中にしたら、どうでもよすぎるんだろうなあ
結局はそういうことだろ

何が何でもbzrを盛り上げて、svnかbzrの二択にできないもんかね
0397デフォルトの名無しさん2010/05/06(木) 23:48:39
>>389
ああっ！ってか確かにそうだよな。
Linuxなんかはいつの間にか(というと失礼と無知さらしだが)UTF-8当たり前になってたから最近はいいんだが、
以前のEUC_JPからの環境はWindowsと同じで切り捨てってことか。

>>390
最近、たまにwebでまれによく見る濁点と半濁点がかなと別に表示されている、みっともない文字のことかな？
ブラウザでテキストで選択すると一緒に選択されるもしかしてあれか？
0398デフォルトの名無しさん2010/05/06(木) 23:52:49
>>397
Linuxの場合は、locale切り替えでなんとか対応出来るんじゃね？既存ファイルは別として
Windowsでもそれができれば別に問題ないとも言えそう。まあできないんだがな。
0399デフォルトの名無しさん2010/05/06(木) 23:56:14
>>390
濁点とかアクセント付き文字はUnicode自身が合成済みのと分離状態
の両方の文字を持っていて、利用システムで好きな方式を採用してい
いんだけど、両方区別なく扱えるようにしてよね、ということになっ
ている。

0400デフォルトの名無しさん2010/05/06(木) 23:59:46
>>396
日本語対応の観点から、現実的にはすでに svn と bzr の二択
しかないと思うが、git と mercurial はググったら日本語の
解説ページがいろいろ引っかかるのに対し、bazaar でググると
もともと日本語のページは少ないうえに、物を売るバザーの
ページもたくさん引っかかって情報収集がしにくいので、
まず情報収集しやすい git か mercurial に手を出してしまう、
という罠があると思う。
0401デフォルトの名無しさん2010/05/06(木) 23:59:58
>>399
つまり、RDBMSなんかでは両方ヒットするのが正しい実装、ってことでしょ？
エディタの検索・置換なんかでもしかり。
で、gitやhgでは？…って、聞くだけ野暮なんだろうね
subversionやbazaarができてるかどうかは別にして、"ポリシー"的に
0402デフォルトの名無しさん2010/05/07(金) 00:26:33
まあそろそろ、声を少しだけ大きくして言ってもいいと思う
ファイル名やましてやコミットログは、バイト列じゃないんだぜって
まずLattin-1を普通に使ってる奴をつるし上げればいいと思う
0403デフォルトの名無しさん2010/05/07(金) 00:30:24
Latin-1な
それってドザだろ
0404デフォルトの名無しさん2010/05/07(金) 00:36:14
忠告じゃないけど、”ドザ”って書くと「頭悪いMac信者」というアピールしているように見えるからやめた方がいいよ。
突然に中国とか韓国ネタ書くやつと大差がない。
不要に荒れる要素出す必要ないだろ
0405デフォルトの名無しさん2010/05/07(金) 00:37:19
おおっと、別に >>403 が「頭悪いMac信者」だと言っているわけじゃないからな、
誤解を生みやすい表現失礼
0406デフォルトの名無しさん2010/05/07(金) 00:37:49
文字=バイト列な田舎モンがドザドザ言ってるのはなんか滑稽
0407デフォルトの名無しさん2010/05/07(金) 00:40:41
シェア1%でこれだけ声がデカイ奴らなんだから、相当アレな奴等じゃないと勤まらんよね
0408デフォルトの名無しさん2010/05/07(金) 00:54:38
いいから黙ってアメリカ語使えおまいら
0409デフォルトの名無しさん2010/05/07(金) 00:57:58
fuck you
0410デフォルトの名無しさん2010/05/07(金) 01:18:20
fack you位言えよ
0411デフォルトの名無しさん2010/05/07(金) 01:30:39
b*******k
0412デフォルトの名無しさん2010/05/07(金) 01:33:47
gitやmercurialがUTF-8で問題ないってのも、単純に「ただそこにあったUTF-8」なら
あんまり問題ないみたいね、ってだけで、Unicodeがどうたらってことには全く無頓着
ってことでいいのかな

もちろんバージョン管理システムの開発って観点では、んなもん関心の対象じゃない
ってのはわからんでもないけど、使い勝手や発展性という点では正直、疑問だと思う
0413デフォルトの名無しさん2010/05/07(金) 01:59:07
満足に「文字」として検索できない時点で、相当のタコだと思うよ
UTF-8が非常に優れた物だったから辛うじて保ってるだけ

大喧嘩の末別れた上に、今でも事ある毎に叩いてる所の技術におんぶに抱っこで恥ずかしくないのかな、彼らは
0414デフォルトの名無しさん2010/05/07(金) 02:05:47
>>413
いや、そのためにUTF-8は生まれたんじゃないか。

今の時代、UTF-8専用でもかまわないと思うが、WindowsでANSI APIを使うのは
避けてほしいところだな。
0415デフォルトの名無しさん2010/05/07(金) 02:12:09
いいから黙ってアメリカ語使ってろおまいら
0416デフォルトの名無しさん2010/05/07(金) 02:15:14
hey boss, bull shit!
0417デフォルトの名無しさん2010/05/07(金) 02:24:07
Get out of here!!
0418デフォルトの名無しさん2010/05/07(金) 02:30:28
ゲラウトヒア！！
0419デフォルトの名無しさん2010/05/07(金) 02:34:30
Yes, you must'nt say "ｹﾞﾗｳﾄﾋｱ!!", OK?
0420デフォルトの名無しさん2010/05/07(金) 04:59:14
>>413
一体どのUTF? win linux ms どのUTFも互換性ない上に、リビジョンがあるんだけど。
0421デフォルトの名無しさん2010/05/07(金) 07:42:00
>>420
バカ現る
0422デフォルトの名無しさん2010/05/07(金) 09:10:37
2008年の頃から、同じような話してんだな。

http://www.unkar.org/read/pc12.2ch.net/tech/1218083381
18 ：デフォルトの名無しさん[sage]：2008/08/08(金) 23:36:58
bzrのいいところは、ファイル名がバイト列ではなくて文字列として扱われて、ちゃんとエンコーディング変換されること。
Windows上で ソ連.txt とか なんとか表.txt とかをaddして、LC_CTYPE=ja_JP.UTF-8なLinuxでチェックアウトすると、
きちんと文字化けせずにチェックアウトできてる。

Mercurialは「ファイル名はファイル内容と同じでバイナリ列」という扱いだけど、ファイル名なんてファイル
システムに書くときにエンコーディングされるし、CUIに表示されるときも、CUIで打ち込むときも
エンコーディングされた文字列を扱っているだけだから、このポリシーはダメダメ。

既にMLで議論されたが、ascii圏の人にはこの問題が理解できなかったらしい。
Python3.0に対応するときに理解できるかな。
0423デフォルトの名無しさん2010/05/07(金) 11:13:28
>>413
＞大喧嘩の末別れた上に、今でも事ある毎に叩いてる所の技術におんぶに抱っこで恥ずかしくないのかな、彼らは
これはドコとどこの話？
0424デフォルトの名無しさん2010/05/07(金) 11:30:28
とりあえずASCIIを可変長のマルチバイトにして符号化方式も3種類くらい乱立させればいいんじゃね？
世界中が幸せになるよ
0425デフォルトの名無しさん2010/05/07(金) 11:34:21
いやASCIIはASCIIだし
0426デフォルトの名無しさん2010/05/08(土) 03:11:22
ASCII範囲を置き換えるくらい分かれよアスペル君
0427デフォルトの名無しさん2010/05/08(土) 03:32:55
msysgitでもUTF-8対応の動きあったんですね。
リリースバージョンには反映されてないみたいですが
TotoiseSVNのcygwin gitの対応はやる気ないみたいだし、msysgitで対応できればTotoiseSVNもなんとかなりそうなんもんですが

Public Git Hosting - git/mingw/4msysgit.git/commit
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commit;h=45867beb1b85a258482431cff2d8268fea4bc7ca
0428デフォルトの名無しさん2010/05/08(土) 09:24:46
TortoiseSVNって? TotoiseGitの間違いだよね?

というツッコミはさておき、msysgitマターでしょう常考
ていうかmsysgitインスコ不要にしてほしいと思う俺だ。
0429デフォルトの名無しさん2010/05/08(土) 10:15:06
他のバージョン管理ソフトみたいにlibgitみたいなのがあって、
それさえ読んでればgitの機能使えるとかだとできるんだろうねえ
0430デフォルトの名無しさん2010/05/08(土) 10:35:26
TotoiseGit はとにかく不安定。
ソース見たら、Windows オンリーぽかった。
TotoiseHg, TotoiseBzr みたいに、PyGtk, PyQt だったら何とかなりそうな気もするんだが。
0431デフォルトの名無しさん2010/05/08(土) 10:48:35
GUIが必要なのってWindowsユーザーくらいだろうから（自嘲）
ネイティブでいいと思う
0432デフォルトの名無しさん2010/05/08(土) 10:49:25
gitならTortoiseGITよりgit extentionsかな
0433デフォルトの名無しさん2010/05/08(土) 13:12:02
JGit - Java GIT ってのがあるみたいですね。
http://www.jgit.org/
0434デフォルトの名無しさん2010/05/08(土) 13:18:37
いらねぇ
0435デフォルトの名無しさん2010/05/08(土) 13:42:26
Javaって聞くだけで拒否反応が起きる俺はV2C使い
0436デフォルトの名無しさん2010/05/09(日) 07:33:38
gitで間違えたユーザー名でコミットした場合はどうやってなおせばいいんでしょうか？

git config user.name "new user"
git config user.email [email protected]
git commit --amend -m "saido commit"

のようにしてgit log -1してみても、authorが書き変わってくれません(´･ω･`)
04374362010/05/09(日) 07:53:33
git commit --amend -m "saido commit" --author="new user <[email protected]>"
で行けました。

以下のコマンドで見ていたところ、
git log -2 --pretty=full
>>436の時点では authorは変わらずcommitは変わっていました。
コミット時に--author指定でauthorも変わりました。

ありがとうございました！
04384362010/05/09(日) 08:13:03
ちょっと気になったのですが、>>436 のAuthorが国家的な機密情報(のようなもの)だった場合、
例えば仕事のリポジトリに間違って、個人の名前を入れてしまった場合です。
--amendで修正した前のコミットしたデータは、リポジトリに残っているようなことはないもんでしょうか？
git pushしなければリポジトリにはデータは残らないと考えてよいのでしょうか？

この辺のドキュメントはどこを見ればよいのでしょう？
0439デフォルトの名無しさん2010/05/09(日) 08:22:46
国家機密レベルなら、むしろ間違えたコミットの前まで戻って
もう一度やり直す（ブランチを切り直して無かったことにする）のがいいのでは？

まあpushしなければ全てはローカルでの出来事なのは確か
push前に確信が持ちたかったら、ドキュメントはむしろソース嫁レベルじゃないかと
0440デフォルトの名無しさん2010/05/09(日) 08:27:22
>>438
git gc するまではリポジトリに残ってるよ。pushした先も同様。
ドキュメントはgit help gc とか？
04414362010/05/09(日) 09:26:49
ありがとうございます。
git reflog
や
git log --author="old_name" -p

のように試してみたのですが、git gcしても残りますね・・・。
amendだと残ってしまうん？
04424362010/05/09(日) 09:37:40
x git log --author="old_name" -p
o git log --author="old_name" -g

ああ、reflogは共有されないんですね。まあ、いいのか。
0443デフォルトの名無しさん2010/05/11(火) 01:26:11
ログメッセージに書くべき内容って、バージョン管理ツールのマニュアルに書いてないみたい
なんだけど、どっかに文書でまとめられてたりしない？
0444デフォルトの名無しさん2010/05/11(火) 03:17:56
>>443
あなたは自分が何をすべきかご存じないのですか?
0445デフォルトの名無しさん2010/05/11(火) 03:21:07
あるわけねーだろ
0446デフォルトの名無しさん2010/05/11(火) 03:45:12
つ ChangeLog
0447デフォルトの名無しさん2010/05/11(火) 07:57:27
>>443
コード中に書くコメントとほぼ同じに考えればいいよ。
書くべきは「何故」そういう変更をしたのか。
後は、「どういう」変更をしたのかも簡単に添えておけば、
いちいちdiffする手間がちょっと省ける。
(ここがちょっとコード中コメントとは違うかな)
0448デフォルトの名無しさん2010/05/11(火) 08:46:45
関数名を変更とか、変数を追加とか、は比較的書く意味が薄いな。
0449デフォルトの名無しさん2010/05/11(火) 11:05:30
>>448
なんでそうしたか書けばいいじゃん。
実態と合わない命名を修正したとか、ソース整理したとか。
0450デフォルトの名無しさん2010/05/11(火) 11:12:41
そういう機能や仕様が変わらない変更は
ほとんど「リファクタリング」の一言ですましちゃうな
0451デフォルトの名無しさん2010/05/11(火) 12:53:43
trivial change
trivial change
trivial change
・・・
04524482010/05/11(火) 13:19:17
>>449 うん、理由を書くならいいんだよ。それを否定してはいない。
0453デフォルトの名無しさん2010/05/11(火) 13:22:14
最悪なのは「いろいろ修正」とかだな。ログメッセージ空のほうがまだいい。
0454デフォルトの名無しさん2010/05/11(火) 13:26:35
>>453
(´；ω；｀)ｳｯ…
偉い人も
「明日の自分のためにもちゃんとログを残しておけ」
って言ってるけどなかなか実践できてないや…
0455デフォルトの名無しさん2010/05/11(火) 13:46:30
ここまで総合するに，ログに書くべき内容は，
変更箇所 + 変更内容 + 理由
といったところでしょうか。
些細な変更には，変更内容と理由を合わせて "refactoring" などの一言でOKと。

ちなみに，ログの形式はどうされてますか？
0456デフォルトの名無しさん2010/05/11(火) 13:47:49
変更したモジュール名だけを書くやつもおる。
0457デフォルトの名無しさん2010/05/11(火) 14:26:21
>>455
自分の考えを述べてみよ。何のためにログメッセージを残す？
0458デフォルトの名無しさん2010/05/11(火) 14:31:29
変更箇所と変更内容は差分を見れば自明なので、最悪の場合差分を見ればいいけど、
理由を書いてないと変更した本人以外わけがわからなくなることが多い。
0459デフォルトの名無しさん2010/05/11(火) 17:07:05
お前ら何言ってんだ
ログに残すのは「何々がしたかった」に決まってんだろ
他の情報は全て蛇足でありノイズ
0460デフォルトの名無しさん2010/05/11(火) 18:18:19
> 「何々がしたかった」
で、それは実現できたの？できなかったの？
0461デフォルトの名無しさん2010/05/11(火) 19:04:07
>>460
バカなの？
そんなもの後になって運が良ければ分かるだけの話
「したかった事を実装した」直後には「したかった事が実現できた」など断言できん
0462デフォルトの名無しさん2010/05/11(火) 19:46:39
オプションの追加や、メソッドの追加は歴然と事実としてあるんじゃないの？
それを、オプションを追加したかった、メソッドを追加したかったと記述するのには違和感がある。

多分、実装途中のログの表現について言ってるんだと思うけど、
「～中」や、現在進行形で良いのでは？
0463デフォルトの名無しさん2010/05/11(火) 20:02:59
自分の場合、
一連のコミットで共通になる事柄をTracとかRedmineとかのチケットに書いておいて、
コミットログは「○○のために××した、#xx」(#xxはチケット番号)にしてる。
0464デフォルトの名無しさん2010/05/11(火) 20:06:29
遊ぶ金が欲しかった（過去形）
04654622010/05/11(火) 20:09:11
レスを勘違いしてたかもしれん。

「～したかった」とそのままログに書くのではなく、
「何々がしたかった」を指針にその内容をログに書けってことかな。
理解しきれてないけど。
0466デフォルトの名無しさん2010/05/11(火) 20:34:14
後からバグが発覚したときに後悔しないようなコミットログにしようぜ。orz
0467デフォルトの名無しさん2010/05/11(火) 20:40:04
この変更をコミットしたのは誰だぁ
svn/git/bzr/hg blame
0468デフォルトの名無しさん2010/05/11(火) 20:41:44
>>459　した事を書け！！
とレスして欲しかったんですね。わかります。
0469デフォルトの名無しさん2010/05/11(火) 20:48:53
>>462
バカすぎる
お前の手書きした「メソッドを追加した」と言う情報に一体何の価値があるの？
そんなもん最もログに書く意味の無い、ノイズの極みだよ

後に問題とされるは「そのコード変更でコミッタが一体何をしたかったか」だ
前任者がコミットログに「オプション～を追加したメソッド～を追加した」とかだけを羅列してたら、ぶん殴りに行きたくならんか？

これで理解できないなら、もうお前はパッチをコミットログにコピペしとけ
抜け漏れが無いことが保証されてるから幾分マシ
0470デフォルトの名無しさん2010/05/11(火) 20:51:44
>>468
何も分かってねぇ
「した事」なんざDiff見りゃ分かる
「その意図」を残すのが最も重要
0471デフォルトの名無しさん2010/05/11(火) 21:49:44
お手本plz
04724622010/05/11(火) 21:55:07
>>469
これは失礼しました。

要するに、上でも既に述べられてるけど、理由を書けってことね。
あなたの言葉を焼き直すと、動機を書けになるのかな。
0473デフォルトの名無しさん2010/05/11(火) 21:59:20
いや、目的を書けだろ
0474デフォルトの名無しさん2010/05/11(火) 22:29:15
>>472
何でそんなズレてんだか
動機なんてオマケだろ

「手動で～するのが面倒だった(動機)」ので「自動で～する機能を実装した(したかった事＝目的)」

コードを追う上で面倒だったと言う感想なんざ要らん
コードを変更した理由として動機を書くのはタコ
コードを変更した理由として目的を書くのが正しい
0475デフォルトの名無しさん2010/05/11(火) 22:39:01
ユーザーから仕様変更の依頼があったので
っていう動機は？
0476デフォルトの名無しさん2010/05/11(火) 23:13:26
オマケとして付いてる分にはかまわん
目的抜かして動機だけ書けば良いと思ってるなら>>472と手を取り合って死ね
0477デフォルトの名無しさん2010/05/12(水) 00:41:20
目的を書く事が重要なのは同意だが、なるべく修正箇所の要約もログに残ってると便利だがなぁ。
改造目的を読んでコードの修正内容が連想できる場合は良いけど、そうでない場合に逐一Diffを
追いかけて目的のリビジョン探すなんて時間の無駄じゃね？
0478デフォルトの名無しさん2010/05/12(水) 01:03:16
目的とか動機という単語は、かなりメタな言葉だ。
新規実装の時とバグ修正の時と仕様変更の時で、それぞれコミットログに求められるものが違うだろう。
0479デフォルトの名無しさん2010/05/12(水) 01:07:20
>>474
その状況で「手動で～するのが面倒だった」をログに書かないなんて、ありえない。
0480デフォルトの名無しさん2010/05/12(水) 01:13:49
自動化による効率化の為、とでも書けば満足なんじゃね？
動機と目的はそんなに遠い言葉じゃないと思うので、要はwhyを書けってことかな
howやwhat、where、whoは勝手にわかるのでいらねってことかと
0481デフォルトの名無しさん2010/05/12(水) 01:17:06
>>480
when が抜けてるぞ。いらないけどな

WHY > WHAT >>> （必要なら） HOW でFA？
0482デフォルトの名無しさん2010/05/12(水) 01:33:43
>>481
なぜその位置にwhatがあるんだ
たとえば「変更する」を補うと
なぜ変更したか→コミットログしとけ
何を変更したか→diffがあるよ
どうやって変更したか→どうでもいい
0483デフォルトの名無しさん2010/05/12(水) 01:46:33
ちょっと大きな修正の場合、「何をどうして」こうなったって記述が
必要になるケースはあるだろう
0484デフォルトの名無しさん2010/05/12(水) 01:49:07
機能追加のコミットなんかは、まさにwhatがメインだな
原則さえ抑えておけば、ケースバイケースでいいじゃないか
0485デフォルトの名無しさん2010/05/12(水) 01:52:14
普通、コミットログは、1行目だけは特別扱いされてる。
だから、1行目は見出しとして書くべき。2行目以降は妥協しても良し。
0486デフォルトの名無しさん2010/05/12(水) 01:58:53
「それをなぜしたのか」 → why
「それは何をしたのか」 → what
「その修正はどういうロジックなのか」 → how

こんな所だろ？それぞれ必要なケースも容易に想像できそうだけど…
最初以外は、ソースのコメントに書くべきかもしれないとか、そういうことなのかな
0487デフォルトの名無しさん2010/05/12(水) 07:24:44
「What」はDiff見ろって効率悪過ぎだろ
リビジョンいくつあると思ってるんだよ。
0488デフォルトの名無しさん2010/05/12(水) 07:42:04
全部のWhat見て何がしたいの？
Diff見るのすら手間になるような数のコミットで、漏らさず変更箇所を書く労力は考えないの？
後で漏れてた事に気付いたらどうやって修正するの？
0489デフォルトの名無しさん2010/05/12(水) 07:50:49
もちろん後の祭です(ｷﾘｯ
0490デフォルトの名無しさん2010/05/12(水) 08:01:28
というか、変更箇所の要約無いとダメとか言ってるお猿さん達はpatchをgrepする脳みそを備えてないの？
0491デフォルトの名無しさん2010/05/12(水) 08:02:34
例えば、こんな感じ？
Why ZZ社 特許XXXXXX 請求項nnの回避
What xxxx算出式を変更
How yyy係数を0.125の倍数に変更
0492デフォルトの名無しさん2010/05/12(水) 08:05:23
>>474
結局何も新しいこと言ってないんだよな～

> 「手動で～するのが面倒だった(動機)」ので「自動で～する機能を実装した(したかった事＝目的)」

結局、散々否定したwhatを書いてるじゃん。
printf を実装した目的を書けってか？
利便性のためという自明な目的なら、いちいちそれを書くのは不毛。
whatを書くだけで十分な場合もある。

> コードを変更した理由として動機を書くのはタコ
> コードを変更した理由として目的を書くのが正しい

動機 = 理由だから、理由に動機を書いてタコな理由が分からん。
目的にこだわる理由を教えてくれ。
理由も動機も目的もニュアンスは同じ。
>>447が指摘済み。
0493デフォルトの名無しさん2010/05/12(水) 08:15:27
>>467
単にざっと眺めるだけならannotate, 「この行追加したの誰だ。氏ね」という
気分の時にはblameを使います
0494デフォルトの名無しさん2010/05/12(水) 09:29:15
仕様の変更点を探す時はwhy、実装の変更点を探す時はwhatがあった方がいいやね
0495デフォルトの名無しさん2010/05/12(水) 10:10:57
>>493
bzrだとannもblameも同じなんだが、他は違うの?
つーか、「この行消した間抜けは誰だ」ってときには使えないし。
0496デフォルトの名無しさん2010/05/12(水) 10:15:14
>>492が本物のバカなのはもう疑う余地が無い
問題：「手動で～するのが面倒だった(動機)」
解法：「自動で～する機能を実装した(したかった事＝目的)」
計算式：Diff
で、解法が書かれていれば計算式の正しさを検証できる
問題と計算式しかない場合、想定していたであろう解法を計算式から予測するしかなく、誰にも検証できない

>printf を実装した目的を書けってか？
当たり前だ
コードからじゃお前以外誰にもprintfを再実装した目的など分からん

>利便性のため
そりゃ動機だ

>whatを書くだけで十分な場合もある。
で？だから何なの？十分な場合もあるから、一辺倒にwhatだけ書いてりゃいいの？

>理由も動機も目的もニュアンスは同じ。
そりゃ大層な無学だな
健康上の理由で辞職する
健康上の動機で辞職する
健康上の目的で辞職する
これじゃ日常会話にすら支障が出るわ
現に出てるし
0497デフォルトの名無しさん2010/05/12(水) 10:50:12
文脈もあるよな。ログメッセージ読むってことは多少なり開発に足突っ込んでるだろうから、
簡潔な文章でも他の開発者が「意味わかんねーんだけどナニこれ？」ってならないなら
それでもいいし、けっこう突飛なこととか誤解されそうな内容だったら冗長に書く、
それでいいんじゃないかね。
0498デフォルトの名無しさん2010/05/12(水) 11:09:08
>>496
問題と計算式だけあれば、問題が解決されているかどうかで変更の妥当性を検証できるんじゃないの？
0499デフォルトの名無しさん2010/05/12(水) 12:09:27
>>498
できない
コードは書かれた通りにしか読めない
そのコードで本当にやりたかった事など誰にも分からない
0500デフォルトの名無しさん2010/05/12(水) 12:28:03
>>499
やりたかったことは、その問題を解決したかったということに決まっているじゃないか。
具体的な方法は Diff にある。これで何が不満なの？
0501デフォルトの名無しさん2010/05/12(水) 12:43:21
>>469
前任者の履歴コメントなんて見ないよ
何かを知る必要があればdiff見る
0502デフォルトの名無しさん2010/05/12(水) 12:45:59
annotation知らん奴が多そうだな
0503デフォルトの名無しさん2010/05/12(水) 12:49:30
>>500
いい加減日本語も不自由で人のバグを追ったことも無いタコスケは黙れば？

「手動で～するのが面倒だった(動機、問題)」ので「～の条件化では自動で～する機能を実装した(目的、解法)」
で、お前の作り出した糞の塊であるコミットログには問題しか書かれて無いわけだが
その条件式の必要性と正当性はDiffから読み取れるのか？
こんなシンプルなケースすら想定できないって、どんだけの未熟者が口出ししてんだよ
0504デフォルトの名無しさん2010/05/12(水) 12:55:42
>>503
何か後出し来たな・・・。まぁいいか。

その条件式の必要性と正当性は Diff や変更後のファイル自体から読み取れるべきだろ。
自明かもしれないし、自明で無いならコメントが添えられているべき。

ログに「～の条件下では自動で～する」と書かれていてもその条件の必要性と正当性は
結局ソースにコメントでも無いとわかんないよね？
0505デフォルトの名無しさん2010/05/12(水) 13:07:07
>>504
で？だから何？
結局ソース見なきゃわかんないからログには「手動で～するのが面倒だった(動機、問題)」だけが書かれていれば十分と主張するの？
もういいよ、お前は生まれ付いての糞転がしで、糞の塊を作り続けるのは本能なんだよな
俺には糞転がしのライフスタイルを改めさせるだけの力は無かったと言う事で終了
0506デフォルトの名無しさん2010/05/12(水) 13:37:36
>>505
こちらの主張は、挙げられた例で「手動で～するのが面倒だった(動機)」にあたるような内容こそ
ログに書くべきなのであって、それを否定するような主張（「～はタコ」とか）は間違いだと言うこと。

別に「目的、解法」にあたる内容をログに書くことを否定しているわけじゃない。しかしそういった
内容は対象のファイル自体から（ログを追わなくても）読み取れるべきだとも考えているので、
そこがログの要点であるという主張には疑問が残る。
0507デフォルトの名無しさん2010/05/12(水) 13:43:11
>>505 無意味なレッテル貼りや煽りをやめればそういう力が付くかもね。がんばれ。
0508デフォルトの名無しさん2010/05/12(水) 14:06:49
目的はソースからはなかなか読み取れないと思うなぁ。
ベテランならともかく、若い子の書いたソースなんて
なんでこんなことしてるの？ってのがよくある。
そんなソースに限って、「変数を初期化する」みたいな
無意味なコメントばっかりだったりする。
0509デフォルトの名無しさん2010/05/12(水) 14:08:42
>>508
それはソースのコメントで済ませるべき問題であって、ログに書くべきこととは違うんじゃない？
0510デフォルトの名無しさん2010/05/12(水) 14:24:44
>>509
人と仕事したこと無い奴が人と仕事するためのルールに口出しするのはおかしいと思わない？
0511デフォルトの名無しさん2010/05/12(水) 14:53:45
バグ修正は、
Fixes #xx (BTSの番号) 簡単な記述。
で十分。
0512デフォルトの名無しさん2010/05/12(水) 15:09:03
>>495
subversionに文句を言ってくだしあ> <
0513デフォルトの名無しさん2010/05/12(水) 15:19:27
コミットの粒度の問題もあって、
新規機能開発で、git, hg の場合、
ローカルな複数のコミットを１つのコミットにまとめて push ってのもある。
CVS, Subversion の場合、ブランチなんだろうけど。
0514デフォルトの名無しさん2010/05/12(水) 17:19:27
git-svnの質問いいでしょうか？

ローカルブランチで一通り作業し終わって、リモートtrunkに関連付けたmasterにmergeしgit svn dcommitしました。
こちらの期待としてはブランチでの作業もsvnに上げたかったのですが、
上の方法ではmasterにmergeした分しかsvnにコミットできませんでした。
ようするに「マージした(Merge branch なんとか)」というログと全部マージした1つ分のコミットしかない状態です。
(当たり前といえば当たり前の挙動ですが)

ローカルのブランチでの作業もsvnにコミットしたい場合、どういう開発の流れになるのでしょうか？
git svn branchでリモートブランチを作成し、それにコミットしていくべきなのでしょうか？

また今後はそうするとして、
今あるローカルブランチのログを残したいのですが今からでもsvnでブランチ作成してそこにコミットすることってできないんでしょうか？
0515デフォルトの名無しさん2010/05/12(水) 17:39:00
>>514
git svn dcommitするならmergeじゃなくrebaseするべし。
0516デフォルトの名無しさん2010/05/12(水) 19:19:08
>>514
master でそのまま作業して dcommit すれば？
0517デフォルトの名無しさん2010/05/12(水) 20:08:08
コミットログもソースのコメントも、ここの図のように、
http://doc.bazaar.canonical.com/bzr.dev/ja/user-guide/bazaar_workflows.html#id7
あまりにもおかしいやつは、ゲートキーパーが突っぱねればいいんじゃないの？
0518デフォルトの名無しさん2010/05/12(水) 20:09:23
>>495
svn annotate = svn blame = svn praise
気分によってお好みで。
0519デフォルトの名無しさん2010/05/12(水) 22:02:47
あ、そういうことか。
05205142010/05/13(木) 13:35:20
git-svnの運用がイマイチわからない・・・

今までsvnだと
機能やissue、チケットごとにブランチ切る＆切り替え→実装してコミット繰り返す→trunkに切り替えてマージ
とやってました。

gitでも、チケットごとにブランチ切る＆切り替え(git co -b unko_feature)→実装してコミット繰り返す(git add .; git ci)→
masterに切り替えてマージ(git co master; git merge unko_feature)
というようにやってました。

git-svnの場合、
remotes/trunkをlocal_trunkに割り当てて(git co -b local_trunk remotes/trunk 相当？)→
チケットごとにremoteブランチを切って(git local_new_feature co -b remotes/new_feature )→
実装してコミット繰り返す(git add; git ci)→リモートブランチにコミット→(git svn dcommit)→
完了したらtrunkにマージ(git co local_trunk; git merge --no-ff new_feature)→trunkをコミット(git svn dcommit)

でいいんでしょうか。

>>513でも書いたのですが、リモートブランチでなくローカルブランチを作ってマージしてsvnにコミットしても
マージした結果しか残らず、お手軽にローカルでブランチ切って開発というようにはいかないのですが、
こんなもんですか？

リモートブランチはsvn側に記録が残るが、
ローカルブランチはマージだけした場合svn側に残らない(マージしたのがまるごと記録)ということでしょうか？
リモートブランチはsvnに繋がる環境でないといけませんよね？気軽にブランチ切れない気がします。

>>515
git svn rebaseってことですか？git svn rebaseは更新(pull相当)だと思っていたのですが、違うものでしょうか？

>>516
気軽にブランチをバンバン切りたいのです…
0521デフォルトの名無しさん2010/05/13(木) 14:28:11
マスタがSubversionなら、気軽にブランチ切っちゃいけないでしょ。
0522デフォルトの名無しさん2010/05/13(木) 15:37:55
>> 520
そもそもSubversionは1.5まではマージの記録が残らなかったんだから。

0523デフォルトの名無しさん2010/05/13(木) 20:55:42
>>520
>>521の言う通り、Subversionを使う限りはそっちに従わないといけないので、
svnに対しては真っ直ぐな履歴（マージコミットは無し）にしてdcommitしないといけない。
gitとsvnではマージの扱いが違うので、今のところgit-svnはマージの面倒をみてくれない。
Subversion1.5のマージって確かpropsに情報埋め込む感じだったと思うんだけど
gitはコミット同士の親子関係を明確に管理してる。
だからgitでブランチ切ったりしていろいろやるのは自由だけど、最終的に
svnに持っていく時には、svnみたいな履歴（真っ直ぐな履歴）にする必要がある。

git svn dcommitで出来ることは単純。svnに存在しなくてgitにだけ存在するコミットを
（git-svn-idを元に判断して）svnに持って行く。さらにそこにresetする。
git svn rebaseは、同じようにsvnにのみ存在するコミットがあれば持ってきて
rebaseする。
ようは設定したsvnパス（trunkとか）とgitの現在のブランチの同期を図るような感じ。
05245142010/05/14(金) 10:03:17
>>521-523
ありがとうございます。

リモートがsvnだとブランチ気軽に切れないんでしょうか？（ん？？何で？？？）

まっすぐな履歴ということはつまり、リモートブランチをなるべくきらないなら、
trunkにそのままフラットにコミットしていくということでしょうか？

ブランチ切れないと開発しにくくないですか？(git使う意味って？？)

> だからgitでブランチ切ったりしていろいろやるのは自由だけど、最終的に
> svnに持っていく時には、svnみたいな履歴（真っ直ぐな履歴）にする必要がある。

これをうまくやるやり方がぜひ知りたいです。
上にも書きましたけど、ローカルブランチをマージしたならマージしたのしかコミットできないので・・・。
（マージした際のそっけないログメッセージは、-mでログを指定するか
mergeした後で --amend で再コミットすればいいと気づいたので解決できそうです）


svn dcommit, svn rebaseはなんとなくわかりました。

>>522
そもそもまだSubversion 1.4使ってる・・・(´･ω･`)
0525デフォルトの名無しさん2010/05/14(金) 10:25:39
>>524
Subversionのブランチって（タグでさえも）普通のディレクトリだからね。
Gitとは扱いが違うから、git-svnではGitとSubversionの普通のコミットを
相互にやりとりするぐらいしか出来ない。

＞ブランチ切れないと開発しにくくないですか？(git使う意味って？？)
SubversionをやめてメインをGitにするなら問題ない。
ていうかSubversionでマージしたりGitでマージしたり、
ごちゃ混ぜにして使ったらおかしなことになりそうだとは思わない？
Git使う意味はあなたに聞きたいね。どうして使いたいの？

＞これをうまくやるやり方がぜひ知りたいです。
だからrebaseで真っ直ぐにするんだよ。
まずPro Git とかチュートリアル読んだようが良いと思う
http://progit.org/book/ja/
http://www8.atwiki.jp/git_jp/pages/27.html
0526デフォルトの名無しさん2010/05/14(金) 10:54:45
"git svn rebase" じゃなくて "git rebase" とまで書かないと理解していないっぽい。
0527デフォルトの名無しさん2010/05/14(金) 11:52:21
アホ過ぎて呆れるわ
0528デフォルトの名無しさん2010/05/14(金) 12:44:05
gitにはgitは使えないこの皮肉
これはgit自体がgitである事の証左にもなっている
0529デフォルトの名無しさん2010/05/14(金) 13:47:50
うまいこと言ってるつもりなのか。痛いなー
0530デフォルトの名無しさん2010/05/14(金) 23:29:53
>>520
> 今までsvnだと
> 機能やissue、チケットごとにブランチ切る＆切り替え→実装してコミット繰り返す→trunkに切り替えてマージ
> とやってました。

このルールだと、結合テスト・総合テストの度にマージを繰り返していたってことなのか？
マージが終わったら、"svn rm ブランチ"なのか、放置なのか？
svnでブランチだらけって考えただけで・・・
05315142010/05/15(土) 18:18:46
アホな俺にアドバイスくださり、ありがとうございます！！

>>526-525
Pro Git読んだら、rebase勧められた意味がわかってきました。
あとgit svn rebaseとも混同してましたｗ

Pro Git - Pro Git 3.6 Git のブランチ機能 リベース
http://progit.org/book/ja/ch3-6.html


Pro Git一通り以前にさらりと読んでいたつもりだったんですが、全然頭に入ってなかったことがわかりました。
実際に使うときにならないとわからないもんです。
頭悪いわ俺・・・

>>530
普通はsvnはブランチがつくりにくい(作るコストやマージしにくい)から
長期のブランチのみで運用するってことですよね？
0532デフォルトの名無しさん2010/05/16(日) 08:32:58
>>531
> 普通はsvnはブランチがつくりにくい(作るコストやマージしにくい)から
> 長期のブランチのみで運用するってことですよね？

svnのブランチは、"svn cp DIR1 DIR2"で作るもの。
branchesみたいなディレクトリに作らないと、ブランチなのか何なのか分からない。
branches/ticket/xxx みたいなブランチなら、それはそれでありでは？
でも、とんでもない数にならないか？

長期のブランチってのも、プロダクト、プロジェクトによって違う。
メジャーバージョンで分けたり、安定版・開発版で分けたりする。

Mercurialの場合、この長期のブランチというのは、リポジトリで分けるのがポリシー。
Mercurial本体や、Mozillaがそんな分けかたをしている。

gitはsvnから移行したのが多そうなので、svnを踏襲しているのが多そうに見える。
0533デフォルトの名無しさん2010/05/17(月) 21:32:29
>>15
しかしあれを使ってリポジトリを作成するときにFSFSを選択しないと
後で痛い目をみるという
0534デフォルトの名無しさん2010/05/18(火) 01:06:32
だいぶ前からデフォルトでFSFSだぞ
0535デフォルトの名無しさん2010/05/18(火) 14:44:35
Gitで、リモートリポジトリのブランチに対して git rebase を実行することはできますか。

## リモートブランチからチェックアウト
git checkout -b dev --track origin/dev
## なんかコミットしてpushする
git commit -m "..."
git commit -m "..."
git push
## masterブランチをマージしてrebaseする
git merge master
git rebase master
## 同じことをリモートブランチに対して行いたいんだけど、
## どうしたらいい？

0536デフォルトの名無しさん2010/05/18(火) 15:21:28
>>535
＞Gitで、リモートリポジトリのブランチに対して git rebase を実行することはできますか。
rebaseしたのをpushしたらいいよ。たぶんFastForwardじゃない、と拒否されるので
ブランチ名に+を付けてpush。
ただし外に公開してるブランチをrebaseしちゃうのはあまりよくない。
他の人が驚くので。そのへんクリアならやってもよいと思うけど。

＞git merge master
＞git rebase master
mergeしちゃったらrebase意味ないんじゃないか？
0537デフォルトの名無しさん2010/05/27(木) 13:18:29
github で、あるリポジトリをフォークしたあとに、オリジナルのリポジトリを反映させるにはどうしたらいいでしょうか。

たとえば
http://github.com/rails/rails.git （オリジナルのリポジトリ）
をフォークして
[email protected]:myname/rails.git （フォークしたリポジトリ）
を作ったとします。
そんで、手元で git clone [email protected]:myname/rails.git を実行して
ローカルにリポジトリを作成しました。
で、そこで作業するのはいいんですが、オリジナルのリポジトリも当然更新されていきます。
その更新を、フォークしたリポジトリに反映させるのはどうしたらいいのでしょうか。
0538デフォルトの名無しさん2010/05/27(木) 13:27:22
>>537
remote追加してpush.
0539デフォルトの名無しさん2010/05/27(木) 14:05:28
hatしてgood
0540デフォルトの名無しさん2010/05/27(木) 15:03:24
>>537
オリジナルをgit remote add してそこからpull
そんでそれを自分とこにpush
0541デフォルトの名無しさん2010/05/29(土) 11:16:08
>>538,540
どうもありがとうございます。
具体的な手順としては
git remote add rails http://github.com/rails/rails.git
git pull rails master
git push origin master
であってますでしょうか。

あと、この方法で同期させた場合、ローカルリポジトリに独自のコミットがあった場合、
git pull rails master
はうまくいくのでしょうか。
ローカルリポジトリに独自のコミットがなければうまくいくだろうとは思うのですが、
あった場合に git pull rails master がうまくいくのか心配です。
0542デフォルトの名無しさん2010/05/29(土) 11:25:21
>>540
fetchしてmergeないしはrebase
0543デフォルトの名無しさん2010/05/29(土) 16:32:01
>>541
ローカルリポジトリに独自のコミットが無いなら単なるミラーになるし
独自のコミットがあればマージされる。コンフリクトしてマージ失敗することも
もちろんある。
てかGitはローカルで誰にも影響与えずにちょちょいと試せるんだから、
テストリポジトリ（テストリモートetc）たくさん作って試行錯誤してみたらいいよ。
あとsvnとかCVSの感覚でいきなり始められるものじゃないから、
一度は腰据えてドキュメント読まないとダメだよ。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html
0544デフォルトの名無しさん2010/05/29(土) 16:49:20
テストリモートってあるが、ローカルにbare作っていじり倒せば良い。
0545デフォルトの名無しさん2010/05/29(土) 19:02:55
テトリスモードに見えた
0546デフォルトの名無しさん2010/06/13(日) 17:58:35
一般的な商用RDB（oracle、Sqlserver）ぐらいの確率でいいんですが、
リポジトリの壊れないフリーのバージョン管理システムはありますか？
0547デフォルトの名無しさん2010/06/13(日) 18:10:17
あるよ
0548デフォルトの名無しさん2010/06/13(日) 20:01:30
>>546
> 546 名前：デフォルトの名無しさん []： 2010/06/13(日) 17:58:35
> 一般的な商用RDB（oracle、Sqlserver）ぐらいの確率でいいんですが、
> リポジトリの壊れないフリーのバージョン管理システムはありますか？
>
git, Mercurial は、分散型だから、clone自体がバックアップの一種。
0549デフォルトの名無しさん2010/06/13(日) 20:04:13
普通に良く使われてるのは壊れないんじゃないか？
0550デフォルトの名無しさん2010/06/13(日) 20:08:39
>>549
Subversionの最初のやつ、bdbだっけ、壊れまくったらしいが。
0551デフォルトの名無しさん2010/06/13(日) 20:39:44
bdbはリモートディスクで使うとぶっ壊れる。
いまはbdbを使わないFSFSがメインだね。
0552デフォルトの名無しさん2010/06/13(日) 21:58:34
CVSの ,v チェックサム入っているように見えなかったんで
コミットログをエディタでいじったりしたんだが、これってまずかったのか？
0553デフォルトの名無しさん2010/06/13(日) 22:17:54
この分野はむしろ商用の方が壊れやすいという印象。
0554デフォルトの名無しさん2010/06/14(月) 11:08:51
>>552
お勧めはできないけど、独りで使っているなら遠慮なくどうぞ。
後は、CVSスレへ。
0555デフォルトの名無しさん2010/06/16(水) 23:11:49
mac portのdarcsがいつまでたっても直る気配ない
乗り換えろってことなのか
0556デフォルトの名無しさん2010/06/17(木) 08:19:33
Macからか？
0557デフォルトの名無しさん2010/07/07(水) 12:40:33
初歩的な質問なんですが、gitでbranchを切って作業をして、
別件でmasterに戻って作業をする場合は、branch側でどんな状態でもcommitしてから、
masterに戻る…というので良いんでしょうか？
0558デフォルトの名無しさん2010/07/07(水) 15:00:52
>>557
そういう時はstashのほうが手軽かも
0559デフォルトの名無しさん2010/07/07(水) 19:53:36
開発担当にgitを使わせたいが、commitをどれぐらいの頻度で使わせるべきですか？
促さないとcommitしないし、コメントに何を書けば良いか分からないと文句が出るし、
本当にわけわかめ。
0560デフォルトの名無しさん2010/07/07(水) 20:35:09
>>559
とりあえず、そういうのはいまどきの開発者として駄目だから、切ったらいいよ。
0561デフォルトの名無しさん2010/07/07(水) 21:07:40
つーかちゃんと教えてやれよ
0562デフォルトの名無しさん2010/07/07(水) 21:36:53
帰る前か、忘れたときは次の朝か、１日１回以下しかコミットしないやつ
たくさん居るだろ。
0563デフォルトの名無しさん2010/07/08(木) 01:03:17
>>562
チケット切ってそれ単位にさせればいい。
別にチケット管理システム使えと強制はしないけど、残タスクの管理は
なんにしろやるだろ？そのタスク単位にコミットさせればいい。
05645572010/07/09(金) 08:44:19
>>558
おぉ、ありがとうございます。
git stashですね。便利すぎる。
0565デフォルトの名無しさん2010/07/09(金) 19:44:48
git stashしたのってオブジェクトとして保存されてる？
違うブランチでgit stash popしちゃった時が怖いから
コミット作ってるなあ
0566デフォルトの名無しさん2010/07/13(火) 12:33:14
>>565
>違うブランチでgit stash popしちゃった時が怖いから
あれ、違うブランチでstash popできるのが利点だと思ってたけど違うのかな。
0567デフォルトの名無しさん2010/07/13(火) 14:24:37
英語力が貧弱すぎる上に、どうでもいいことなんだけど
checkout よりも checkin の方がしっくりきてしまう…。
でも調べると out が正しいんだよね。
0568デフォルトの名無しさん2010/07/13(火) 14:57:29
なんで in のほうがしっくりくる？
0569デフォルトの名無しさん2010/07/13(火) 15:05:35
普段聞きなれてるからかと
0570デフォルトの名無しさん2010/07/13(火) 15:14:38
ホテルからチェックインする・・・

聞き慣れてないんだが
0571デフォルトの名無しさん2010/07/13(火) 15:56:39
出る/出すんだからoutだろ?
何の捻りもなくて理解しやすいと思うが
0572デフォルトの名無しさん2010/07/13(火) 16:11:39
ホテルはチェックイン、チェックアウト両方あるけど
飛行機に乗る時はチェックインだけだから
チェックインのほうが使う機会は多い
0573デフォルトの名無しさん2010/07/13(火) 16:13:19
>>570は飛行機にも乗らないし、ホテルにも泊らないんだろう
0574デフォルトの名無しさん2010/07/13(火) 18:49:10
○ホテルにチェックインする
○ホテルからチェックアウトする

×ホテルからチェックアウトする

って言いたいんじゃ
0575デフォルトの名無しさん2010/07/13(火) 20:32:17
　　　　　　／/
　　　　／　.人
　　　 / 　（＿_） ﾊﾟｶ
　　　/ ∩(＿___）　　　あ、ぽこたんインしたお！
　　 /　.|（ ・∀・）＿
　　/／ |　　　ヽ／
　　"￣￣￣"∪

>>567 は廃人
0576デフォルトの名無しさん2010/07/13(火) 23:06:20
>>574
てかそれ以外の意図に読み取る方が難しいよな・・・
0577デフォルトの名無しさん2010/07/13(火) 23:12:39
ふと思ったけどcheck outの記録を残すVCSってあるっけ？
副次的に残るケースは考え付くけど。
そういう意味じゃcheck～じゃないよな。
0578デフォルトの名無しさん2010/07/13(火) 23:37:54
git reflogはちがうのけ？
0579デフォルトの名無しさん2010/07/13(火) 23:41:56
>>577
CVSROOT/history
0580デフォルトの名無しさん2010/07/14(水) 01:30:12
>>577
なんでも残せばいいってもんでもないと
宿のチェックアウトは、入った奴が出て行った、っていう意味しかないだろ
残ってたら課金しなきゃいけないしｗ

主はあくまでもインの方で
0581デフォルトの名無しさん2010/07/14(水) 02:39:29
>>578
無いかと思ったらまさにそれか
0582デフォルトの名無しさん2010/07/14(水) 09:52:32
>>580
手続きを伴わなければチェックアウトという言い方はしないよ
#飛行機でチェックインは言ってもチェックアウトとは言わないのはその為

おそらく昔のVCS(RCSとかSCCSとか)でファイルを持ち出す時にロックの手続きを
行っていたからチェックアウトという呼び方になって、その名残なんじゃないかな
0583デフォルトの名無しさん2010/07/14(水) 10:26:31
git reflogなんでも記録残っててすごいな
やべ、間違った・・・ってときもとりあえずgit reflog
git gcとかpushする前なら戻せるのびっくりしたわ
0584デフォルトの名無しさん2010/07/16(金) 14:07:43
gitで何か新しいことをやろうとすると、
なぜかコミットを失ってわけわからん状態になるので
毎回reflogで救い出してます。reflog様々ですね
0585デフォルトの名無しさん2010/07/16(金) 16:59:41
>>584
なんで、そんな状態になるのか調べたほうが早くないか？
0586デフォルトの名無しさん2010/07/16(金) 22:56:18
>>584
gitで新しいことをやろうとするまえに、bzrあたりでコミットしておけばいいんじゃね？
0587デフォルトの名無しさん2010/07/17(土) 08:58:41
bzr-git使えばいいんじゃね？
0588デフォルトの名無しさん2010/07/17(土) 09:50:03
最初からBazaarを使えばいいんじゃね？
0589デフォルトの名無しさん2010/07/17(土) 09:59:54
賢い人は最初から分かってるよね。
0590デフォルトの名無しさん2010/07/17(土) 11:57:26
C++の話（本当にあった怖い話）
http://www.slideshare.net/Isoparametric/c-horror-kai


中身はバージョン管理してないとかそういう話
0591デフォルトの名無しさん2010/07/17(土) 12:58:04
>>590
SVNスレの方にはSVN使ってても先祖返りされたっていう実例もあるし、VSS以前の話じゃない？
0592デフォルトの名無しさん2010/07/17(土) 14:21:47
>>590 のプレゼンした人のブログにあった記事ワラタｗｗ

VSSが相変わらずフルボッコすぎる件について - 神様なんて信じない僕らのために
http://d.hatena.ne.jp/Isoparametric/20100428/1272405617


> 「ゲームコーディング・コンプリート」より引用。
>
> 常識的に考えて嫌われすぎだろ……。
>
> Microsoft製Visual SourceSafe
>
> 　Visual SourceSafeはMicrosoftのVisual Studioで使われているソースリポジトリである。
> 「安かろう悪かろう」の良い例だ。
>
> 多くの人がこの製品に惹かれるのは、GUIインターフェイスが使いやすく、
> セットアップがとても簡単だからだ。タイプするのが遅くなければ、 10分で起動できる。
>
> 　SourceSafeの一番の問題点は、ソースリポジトリをどうやって格納するかだ。
> リポジトリが格納された共有ファイルを探ってみると、 AAAAAAAB.AAAとかAAACCCAA.AABのような
> 奇妙な名前のついたファイルからなる大きなツリー構造のデータディレクトリがある。
> こうしたファイルの中身はプレーンテキスト（バイナリ化されていない）かそれに近い形だ。
> だからこの奇妙な名前のつけ方はセキュリティ上の理由からではない。
> 理由をご存じの方はメールで教えてほしい。気になって仕方がない。
>
> 　それぞれのファイルは、リポジトリ内のファイルの、前のリビジョンとの差分を保持する。
> ファイルを改訂すれば新しくSourceSafeのファイルを作り、例の変な名前をつける。
> 注意して見ていると、ソース変更が１文字程度の簡単なものであれば、作られるファイルの多くはかなり小さいとわかる。
> それなのに、SourceSafeがネットワークドライブに確保するスペースの量は、控えめにいっても容認できる限界を超えている。
>
(続く)
0593デフォルトの名無しさん2010/07/17(土) 14:24:27
> 　速度面でも深刻な問題がある。小さなプロジェクトでさえ数百のファイルの規模になり、
> 大きいプロジェクトにいたっては何十万ファイルにもなり得る。
> SourceSafeはデータファイルをリポジトリディレクトリ構造に格納するので、
> ファイルの開閉にかかるアクセス時間は極めて長く、プログラマは最新のファイルかどうかを
> チェックするだけでも果てしなく待たされることがある。
>
> 　SourceSafeはブランチをサポートしておらず（ブランチについてはあとで触れる）、
> 枝分かれさせたかったらツリー全体の完全なコピーを作らなければならない。お話にならない。
>
> 　SourceSafeにリモートでアクセスしようなどと思ってはならない。
> 何千ものファイルをのろのろしたインターネットを介して検索するなどもってのほか。
> T1回線でもダメだ。最終的にSourceSafeのファイルインデックスデータベースは動かなくなり、
> ちょっとした分析ユーティリティにも降参し、やり直しだといってくる。
> 私は以前、壊れたデータベースでプロジェクトを乗り切ったことがあるが、
> 壊れた部分の影響が、もはや必要のない古いバージョンのファイルだけにとどまっていた。不幸中の幸いだった。
>
> 　SourceSafeには自ら壊れる癖もある。リポジトリ全体を役立たずの不可解なファイルの山にする。
> これは特に、サウンド、テクスチャ、ビデオなどの大きなバイナリ資源を格納するときに起こる。
>
> 　まだSourceSafe以外のものを使おうという気になってなければ、こういいたい。
> よく調べてほしい。Microsoft自身が使わないという噂を耳にしたことがある。
> もちろん単なる噂にすぎないかもしれないが、他の選択肢も検討してみる余地はある。
>
> バージョン管理システムの紹介で、ダメだししか書いてないよー！

元ネタ
Amazon.co.jp： ゲームコーディング・コンプリート 一流になるためのゲームプログラミング: Mike Mcshaffry, 手島 孝人, 山下 恵美子, 依田 光江, 大貫 宏美, 廉 典子, 田中 幸, 宮本 寿代: 本
http://www.amazon.co.jp/dp/4797358432
0594デフォルトの名無しさん2010/07/17(土) 14:25:28
悪い引用中のスペースが崩れた・・・

専ブラ用ポップアップおいとく >>592-593
0595デフォルトの名無しさん2010/07/18(日) 00:36:31
Visual SourceSafeは、MS的にも既に終了したプロダクトだろ。
だから、MSDNのVS 2010からTeam Foundation Serverをただで使わせるようにしたんだし。
0596デフォルトの名無しさん2010/07/18(日) 00:40:07
>>595
それって結局VSSをマシに作り直した的なものだったりしないのかな？
0597デフォルトの名無しさん2010/07/19(月) 02:16:16
クラサバ方式になってる時点で全くの別物
0598デフォルトの名無しさん2010/07/19(月) 02:42:55
その悪評高いVSSはクラサバじゃないのか？
クラサバじゃないのにどうやってリポジトリ共有するの？
p2pなのかな？
0599デフォルトの名無しさん2010/07/19(月) 02:45:31
調べたらVSS6.0まではファイル共有で運用だったのかｗ
それが原因でファイル壊れるとかワロタ

とはいえ2000年頭のかなり昔の話だな。今はさすがにないだろ
0600デフォルトの名無しさん2010/07/19(月) 08:21:59
調べるも何も、>592-593に書いてあるのに……
おまけに>595にも終了したって書いてあるのに……
0601デフォルトの名無しさん2010/07/19(月) 09:14:48
MS codeplexはhg対応したみたいだけど、gitはどうするのかな？
0602デフォルトの名無しさん2010/07/19(月) 15:57:55
オープンソースは悪だってずっと言ってたけど、変わるもんだねぇ
0603デフォルトの名無しさん2010/07/19(月) 17:33:13
世界中の好きモンが、世界中のユーザーにあーだこーだ言われながら作っていくんだから
完成度はメーカー製の比じゃないと思うがね。

残念ながら Linux に関しては微妙なところだが。
0604デフォルトの名無しさん2010/07/20(火) 01:51:43
codeplexもそうだけどgoogle codeもDVCSでhgしか対応していないんだよね。
bzrをさわるきっかけが無い理由の１つ。
0605デフォルトの名無しさん2010/07/20(火) 01:54:12
bzr-hgはbzr-gitやbzr-svnに比べて遅れてたけど、今は使い物になるのかな？
bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。
0606デフォルトの名無しさん2010/07/20(火) 02:20:55
お前らよくそんなに多種多様なVCS使えるな
0607デフォルトの名無しさん2010/07/20(火) 02:32:25
>>605
Pythonがhgに移行する（した？）んだからbzr-hgが実用じゃないと困るんじゃないの？
0608デフォルトの名無しさん2010/07/21(水) 01:32:51
ところで分散バージョン管理のpush/pullは、なんであんなに
システムごとに概念が違うんだ。
0609デフォルトの名無しさん2010/07/21(水) 02:23:44
バージョン管理ごときに脳細胞1つも使いたくない
何、管理システム乱立させてんだよ。戦国時代ごっこか？
とっとと、これ使っておけばおｋって物だせよ
いつまで待たせんだよ
0610デフォルトの名無しさん2010/07/21(水) 02:31:35
>>609
明らさまにそう言う人はあまり居ないが、大半はそうなんだろうな。
これっぽっちもドキュメント読まないで2chで質問してる人が多いもの。
ある意味インフラだからなー。
0611デフォルトの名無しさん2010/07/21(水) 05:21:43
>>605
> bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
> 操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。

え、マジ？
それいいな

とりあえずgit採用しておいて、gitでのマルチバイトの不安なWindowsからはbzr-gitで操作とかも可能なのか
それはすごい

>>609
いや、実際そうですよ

中央集権ならSubversion一択、と思っていた時期が私にもありました・・・

分散バージョン管理使ってみたら、もうもどれないな。
もちろん細かい不都合は多々あるんだがね。
Windowsとの連携とかマルチバイトがらみの話とか、マルチバイトとか、マルチバイトとか
0612 [―{}@{}@{}-] デフォルトの名無しさん2010/07/21(水) 06:25:43
>>611
>>588
0613デフォルトの名無しさん2010/07/21(水) 07:18:01
>>612
あ、、、

確かに
0614デフォルトの名無しさん2010/07/21(水) 07:49:09
bzrとhg同じpythonだから仲良く出来ないのかな？これじゃあ・・・
http://wiki.bazaar.canonical.com/BzrVsHg
http://mercurial.selenic.com/wiki/BzrVsHg
0615デフォルトの名無しさん2010/07/21(水) 15:07:52
>>608
>ところで分散バージョン管理のpush/pullは、なんであんなに
>システムごとに概念が違うんだ。

後学のために詳しく説明してください。お願いします。
0616デフォルトの名無しさん2010/07/21(水) 15:20:25
何で自分で調べないの？
0617デフォルトの名無しさん2010/07/21(水) 18:29:38
脳細胞1つも使いたくないんでしょｗ
0618デフォルトの名無しさん2010/07/21(水) 19:48:56
>>614
hgさんは、日本語ファイル名の対応に対する開発者のメール見て脱力したから
俺は仲良く出来ないなぁ。マルチバイト圏に対する考慮というか理解が欠けすぎ。
>>615
むしろ同じものを作りたくないから違って普通じゃ無いかと。
どこをチューニングするかって目的意識の違いで設計が変わっているっぽいね。
0619デフォルトの名無しさん2010/07/21(水) 23:03:58
このスレ日本語ファイル名の対応に対する開発者のメール見て脱力した人よく見るよね

TOMOYO Linuxの人みたいにがんばって対応しないといけないんだろうな・・・
0620デフォルトの名無しさん2010/07/21(水) 23:34:58
>>609
http://www.ericsink.com/entries/veracity_early.html
0621デフォルトの名無しさん2010/07/22(木) 02:03:20
>>619
gitやhgしかなければそうなんだろうけど
...bzr

実際使ってみれば、Bazaar別に悪くないのに
マルチバイト圏の人間が盛り上げなくてどうするんだろ

ガラパゴス恐怖症なのかもね。わからなくもないけど
0622デフォルトの名無しさん2010/07/22(木) 11:07:25
>>605
bzr-gitとbzr-hgどっちもpushできないって書いてあったんだけど・・・
0623デフォルトの名無しさん2010/07/22(木) 11:17:40
>>622
bzr-gitはdpushはできる。bzr-hgはまだ使ってないから知らない。

pushとdpushの違いは、相手側のフォーマットとこちらのフォーマットの間で
ラウンドトリップができるかどうか。

pushの場合はラウンドトリップができる（bzrのリビジョンを向こうに置いても、pullすれば
bzrのリビジョンIDが復元できる）ので、bzrのリビジョンを全く修正せずに
pushする。bzr-svnでは、svnのversioned propertyにbzrのリビジョンIDや
ファイルIDを付与することでラウンドトリップを実現している。

dpush の場合はラウンドトリップができない（一度pushしてpullすると別のリビジョンIDに
なってしまう）ので、手元のリビジョンを向こうのフォーマットに合わせて作り直す。
例えば、bzr-gitの場合、bzrのリビジョンidを "git:<sha1>" という形に書き換えて、
bzr側に「gitのどのリビジョンに対応するか」という情報を保存する。

一応、gitのコメントの最後にbzrのリビジョンIDをつけることでpushを実現する方法も
開発されてたと思う。その場合、gitで普通にログを見るとbzrのリビジョンIDが見えちゃうけど。
0624デフォルトの名無しさん2010/07/22(木) 11:46:36
bzr-svnの一発目は軽いの？
git,hgともsvnクライアントとして使おうとすると最初のcloneが重くて。
0625デフォルトの名無しさん2010/07/22(木) 11:51:44
>>624
bzr-svnも重い。こればかりはsvnプロトコルの問題だからなぁ…

オープンソースのプロジェクトなら、Launchpadでimportしてしばらく待っておけば
ミラーが出来上がるので、そこから作業始めれば楽。
社内利用なら、リポジトリのコピーをローカルに持ってきて、ネットワークを通さないで
bzr-svnを使うと速い。
0626デフォルトの名無しさん2010/07/22(木) 11:54:23
Launchpadってユーザ作ってプロジェクト簡単に作れるの？
github, bitbucketみたいな勝手にforkとは文化が違うみたいなんだけど。
0627デフォルトの名無しさん2010/07/22(木) 11:57:01
>>626
プロジェクトは簡単に作れるよ。
forkを作るときは、 lp:~ユーザー名/プロジェクト名/ブランチ名 という感じでブランチを作る。
プロジェクトを用意するまでもないときには、プロジェクト名のところに +junk って書けば
プロジェクトに属さないブランチを登録できる。
0628デフォルトの名無しさん2010/07/22(木) 12:33:59
hgのここ重宝するんだけど、bzrもあったらうれしいな。
http://mercurial.selenic.com/wiki/GitConcepts
0629デフォルトの名無しさん2010/07/22(木) 15:40:16
bzr ってやたら重くない?
0630デフォルトの名無しさん2010/07/22(木) 16:03:17
>>629
別に？
0631デフォルトの名無しさん2010/07/22(木) 16:51:04
Bazaar Explorer は何かと重い。
0632デフォルトの名無しさん2010/07/22(木) 18:25:15
ちょっと大きなリポジトリを clone するとえらい待たされるような
0633デフォルトの名無しさん2010/07/22(木) 20:33:34
煙草でも吸ってればいいと思う
0634デフォルトの名無しさん2010/07/22(木) 21:26:02
なら自分は嫌煙厨なので煙草が必要なbzrは捨てだな
0635デフォルトの名無しさん2010/07/22(木) 21:51:44
bzr の clone(branch) は tree を再構築するから多少遅いね
gitやhgはレポジトリ丸ごとコピーな分速い
分散型の宿命で clone は SVN の checkout と比べたら、どれも十分遅いけど
最初の1回だけだから、それほど気にならないな
0636デフォルトの名無しさん2010/07/22(木) 22:04:19
hgのcloneは基本は丸ごとだけど、-r でリビジョン、1.5からは -b でブランチを指定してcloneが出来る。
firefoxやopenofficeみたいな弩級のリポジトリはタグを指定してcloneしてからpullをちまちまやった方が安全。
cloneは途中で失敗すると最初からやり直しだから。
0637デフォルトの名無しさん2010/07/22(木) 22:07:43
openofficeでかいからbundle配布しているみたいだね。
http://wiki.services.openoffice.org/wiki/Mercurial/Getting_Started
0638デフォルトの名無しさん2010/07/22(木) 22:57:58
>>636
その辺りはgitもbzrも同様だよ。
機能的にはどれも同じようなものが揃ってる。
0639デフォルトの名無しさん2010/07/22(木) 23:01:28
遅いっていっても1時間とかかかるわけじゃないし、そんなに問題じゃないでしょ。
0640デフォルトの名無しさん2010/07/23(金) 02:10:18
gitとhgは機能的に似たようなもんだけど、bzrはちょっと感覚が違うなぁ。
0641デフォルトの名無しさん2010/07/23(金) 03:29:49
Inkscape を clone するときなんか多少どころの遅さじゃなかったなー。 > bzr
0642デフォルトの名無しさん2010/07/23(金) 08:07:54
>>635
svnのcheckoutは.svnにコピーを作るから十分遅いでしょ。
hgのcloneは-Uオプションでファイルを展開しないというのもあるので、ある意味svnのcheckoutより速い。
0643デフォルトの名無しさん2010/07/23(金) 08:08:55
bzrって昔は遅かったから、リポジトリフォーマットを新しいやつにして、bzrも2.0以降を使わないと
遅くなると思う。
今LaunchpadのInkscapeブランチを見たら、「An upgrade of this branch is in progress.」って
書いてあったから、もうすぐ新しいフォーマットが使われるようになると思う。

問題は、新しいフォーマットが実験的にサポートされたのが1.16からなのに対して、
Debian lennyでも標準のパッケージは1.15なんだよな。自分で新しいやつを入れないと
いけない。
0644デフォルトの名無しさん2010/07/23(金) 08:11:32
>>642
履歴がかなり古いプロジェクトを除いたら、hg/git/bzrの方が速いよね。
gitは --depth っての使ったら履歴を途中から持ってこれるから、履歴の古い
プロジェクトでも強い。Bazaarにはまだ各種コマンドが履歴がちょん切れても
動くようにしている最中で、--depth機能は無い。
0645デフォルトの名無しさん2010/07/23(金) 08:38:06
>>644
hgも履歴の途中のcloneのプランはあるんだけどね。
http://mercurial.selenic.com/wiki/ShallowClone
Google Summer of Codeでやんのか。
0646デフォルトの名無しさん2010/07/23(金) 10:54:10
>>605
> bzr-hgはbzr-gitやbzr-svnに比べて遅れてたけど、今は使い物になるのかな？
> bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
> 操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。
これって、EUC-JPやlatin1でもいけるってこと？
0647デフォルトの名無しさん2010/07/23(金) 12:23:24
>>643
アップデートの多いアプリは、標準パッケージはほとんど使わないな。
古くて使ってられん。
0648デフォルトの名無しさん2010/07/23(金) 16:39:26
最近の bzr は bzr log も速くなってるのかな?
Emacs のソースツリーで bzr log --limit=4 FILE とかやると 1 分以上待たされるw
0649デフォルトの名無しさん2010/07/23(金) 16:59:12
>>643
lenny-backportsなら2.0.3だよ
http://packages.debian.org/search?keywords=bzr

>>647
Debianは特にリリース間隔長いからね…
0650デフォルトの名無しさん2010/07/23(金) 18:22:02
>>614
設計方針からして違うんだから仲良く出来るはずがない。
bzrはクソすぎて理解できん。
GuidoがbzrよりMercurialの方がSubversionに近いと言っているのをBazaarMLで頭がおかしいと言っているのを見て
bzrがクソな理由がよく理解できた。
0651デフォルトの名無しさん2010/07/23(金) 18:44:54
Bazaarの開発者もMercurialの開発者もPythonのコミュニティ内では仲良くしているよ。
>>650
先にMercurialを理解してしまったせいで、その先入観がBazaarの理解を妨げているんじゃない？
Bazaarはブランチをうまく管理できないユーザーにsvn coと同じチェックアウトを利用して
push/pull 無しに update/commit だけで作業することもできるし、
ブランチにURLが対応するのもSubversionと似てるよ。
0652デフォルトの名無しさん2010/07/23(金) 19:23:35
Mercurialの場合Subversionでのブランチはこんなのを意味するんだけど
http://hg.mozilla.org/releases/mozilla-1.9.1/
http://hg.mozilla.org/releases/mozilla-1.9.2/
0653デフォルトの名無しさん2010/07/23(金) 19:30:54
>>652
ブランチどころかリポジトリも別れちゃってるから、両方cloneしたら同じリビジョンを
2回ダウンロードする必要が発生しない？
0654デフォルトの名無しさん2010/07/23(金) 19:39:38
>>653
それで何が問題？
容量のことなら、Mercurialの場合あまり気にしていないけど。
Mozillaの場合、CVS文化のままっぽいから名前付きブランチが付いていて例として良くないけど。
0655デフォルトの名無しさん2010/07/23(金) 20:17:59
>>654
ディスク容量よりも、ダウンロード時間やネットワーク負荷の方が問題だな。
0656デフォルトの名無しさん2010/07/23(金) 20:35:34
Mercurialのブランチのポリシー、こっちの方がいい。
http://mercurial.selenic.com/wiki/DeveloperRepos
開発者はcrewを持ってくるし、
一般ユーザで上のDebianの例じゃないけど少しでも早く安定版が使いたい人はstableを持ってくる。
0657デフォルトの名無しさん2010/07/23(金) 20:51:50
>>653
マジで？　それってsvnと変わらなくないか。。。？
0658デフォルトの名無しさん2010/07/23(金) 21:01:16
>>657
Mozillaの場合、マルチヘッドにもなっているっぽいのであんまり良い例じゃなかったね。
hgはgitのリモートブランチという概念も中央リポジトリという概念も無いから
別にネットワーク越しに同期する必要も無いし。
0659デフォルトの名無しさん2010/07/23(金) 21:44:30
>>657
どうしても２回pullがいやっていうんなら、手持ちのリポジトリを合体させておけばいい。
0660デフォルトの名無しさん2010/07/23(金) 23:54:00
>>628
あー、こういうのいいね。
同様なツールの他のものとの構造の比較みたいのってはっきりいって理解の妨げになりやすい
すごく助かるわ

よく参考書でも複数買って照らし合わせたら異なる角度で書かれていてわかりやすいみたいな現象
0661デフォルトの名無しさん2010/07/24(土) 00:00:03
git の cloneメチャ早くてびっくりする。githubで大き目のプロジェクトcloneしても、やたら早い
Subversionをdisるだけはあるわｗ

圧縮して固めて一括転送してるのか？あれは
0662デフォルトの名無しさん2010/07/24(土) 13:01:51
Bazzarは一番シンプルな動作の組み合わせで分散バージョン管理を実現してると思うがなあ。
単機能コマンドを組み合わせて複雑な目標を達成するunix的というか。
0663デフォルトの名無しさん2010/07/24(土) 13:19:23
好きなの使えばいいじゃん。
git が流行ってる理由がよくわからんが。
0664デフォルトの名無しさん2010/07/24(土) 13:23:01
>>615
・bzrのpush/pull
ブランチの履歴を全く同じ状態にする。
送り元のみがマージされていないチェンジセットを持った状態でないと実行できない。

こんな感じ？

・mercrialのpush
・mercrialのpull
・gitのpush
・gitのpull

について、誰か頼む
0665デフォルトの名無しさん2010/07/24(土) 13:32:16
お前らコマンドラインで使ってますか？

833 名前：デフォルトの名無しさん[sage] 投稿日：2010/07/24(土) 13:19:42
LinuxでRubyのなんちゃらを開発してる人ってさ、Gitのクライアント何使ってんの？
まさかコマンドラインで頑張ってるの？

0666デフォルトの名無しさん2010/07/24(土) 13:33:45
>>662
> 単機能コマンドを組み合わせて複雑な目標を達成するunix的というか。

実装の話だけで言えばgitがそんな感じだぞｗ
0667デフォルトの名無しさん2010/07/24(土) 14:31:13
>>665
gitはコマンドラインでの使い勝手がいいから、linuxならコマンドラインで十分いけるな。
diffの時にいちいち | less つけなくていいところとか他も見習ってほしい。

Subversionの場合はTortoiseつかわないとやってられない。
リモート操作の時とかやたらパスが長くなるのとか、コマンドラインで動作が遅いとイライラするし。
もちろんTortoiseSVNの出来がよくて安定してるからってのもあるけど。
0668デフォルトの名無しさん2010/07/24(土) 14:41:16
>>667
でもログはgitkでみちゃう。
0669デフォルトの名無しさん2010/07/24(土) 14:56:45
>>666
bzrはdebian/ubuntu的というのが敷居の高さを感じさせる
0670デフォルトの名無しさん2010/07/24(土) 14:57:55
svnはTortoiseSVNが十分成熟してるからコマンドライン使わないな。
TortoiseBBR他のは日本語パスの扱いが微妙に怪しかったりするので
コマンドラインから使ってる。
0671デフォルトの名無しさん2010/07/24(土) 15:30:53
>>664
・hgのpull/push
incoming/outgoingで確認した結果を実行する。
pushは送り先でマルチヘッドになる場合怒られるが強制的に作ることも可能。
TortoiseHgに「Push new branch」という新たなオプションが付いたので変わったかもしれない。
0672デフォルトの名無しさん2010/07/24(土) 15:46:53
俺もgitでログみるときはgitkだな

--graphとかもっと見やすくならんの？
サブピクセルみたいにコンソールにもっと詰め込む技術の開発が必要
0673デフォルトの名無しさん2010/07/24(土) 16:20:50
>>667
Windowsでもコンソールだけでいける。
msysgitのエクスプローラの右クリックでコンソールが立ち上がるのが凄い便利。
0674デフォルトの名無しさん2010/07/24(土) 16:40:01
自社内もしくは個人レベルのプロジェクトなら好きなの使えるけど
常駐先とか、他社が入った場合は、難しいよなぁ。
話しあって決められる場合はまだいいけど、指定されている場合もあるし。
0675デフォルトの名無しさん2010/07/24(土) 16:51:16
>>674
>>605
0676デフォルトの名無しさん2010/07/24(土) 18:54:51
gitをコンソールだけで弄っている人に聞きたいんですけど、
履歴の把握はどうしてます？
ブランチとかたくさんあるとこんがらがったり、rebaseとかmergeするときに
コンソールだけだとわけわかんない・・・


そういや、msysgitってマルチバイト大丈夫になったんだっけ？
0677デフォルトの名無しさん2010/07/24(土) 19:17:31
>>676
つ>>672
0678デフォルトの名無しさん2010/07/24(土) 19:21:25
>>676
gitk --all
0679676=6722010/07/24(土) 19:53:52
わるい、今はgitk --all使っているんだ

ごめん、IDないとわからんな
おれ >>672 なんだ orz


ただ、gitkだとUnix系ならX入ってないと見れないよね？違うかな？
Cygwin版のgitkなんかのGUIツールは文字化けするから、
どうせと思って動かしている仮想環境のLinuxでgitk立ち上げたら文字化けは問題ないんだけど、
ほぼそれだけのためにX立ち上げてるのがねえ
ちょっと不満なんだ

それがなければ、sshでターミナルでつなぐだけですむのに、と思って
ちょっとLinux経験あさいから、もっといい方法知っている人はぜひつっこみいれてほしい
06806672010/07/24(土) 20:27:15
>>676
仕事でgit-svn中心で使ってたからあんまり複雑な履歴は扱ってないな
MacだとGitXってクライアントがなかなか見やすかった。
0681デフォルトの名無しさん2010/07/24(土) 20:37:04
>>676
git log --graph --oneline --decorate
0682デフォルトの名無しさん2010/07/24(土) 21:13:10
>>681
ありがとう、見やすくなった。
ざっと見るだけならこれでいいか。

こんなのも試してみた。
formatの%dがgit 1.6は対応してないが。1.7だと行けたが
git log --graph --date=short --pretty=format:'%Cgreen%h%d %cd %Cred%cn %Creset%s'
0683デフォルトの名無しさん2010/07/24(土) 22:08:18
Macでいいならgitxが便利。gitkとかクソ。
0684デフォルトの名無しさん2010/07/24(土) 22:38:08
>>683
履歴の探索に関してはgitkもgitxも同じに見えるんだが…
0685デフォルトの名無しさん2010/07/25(日) 19:18:42
>>684
ああごめん、大筋の機能は同じだけど、使いやすさと美しさではgitxの圧勝。しょうがないけど。

0686デフォルトの名無しさん2010/07/25(日) 20:17:50
cygwinのgitkクソすぎる。不安定すぐ固まるし。
0687デフォルトの名無しさん2010/07/25(日) 21:10:54
用途次第じゃね？

boostを展開したディレクトリをSVNでコミットしようとすると1日かかるんだが、小分けにすると5分で終わる。
並列処理でかえって遅くなってるよな。

こんな使い方するほうが悪いんだろうけどさｗ
0688デフォルトの名無しさん2010/07/25(日) 22:11:34
gitのレポジトリ構造にbzrのUIなら文句無いんだけどなぁ
0689デフォルトの名無しさん2010/07/25(日) 23:22:04
レポジトリの中身はユーザが意識しなくてもいいのが正道だと思うが
0690デフォルトの名無しさん2010/07/25(日) 23:25:04
SVNはリポジトリが手元に無くて理解しにくいと思うが
0691デフォルトの名無しさん2010/07/25(日) 23:32:30
中身はユーザが意識しなくてもいいってのは誤解を呼びそうだな。
レポジトリのフォーマットは、ユーザが意識しなくてもいいってのが言いたいこと。
0692デフォルトの名無しさん2010/07/25(日) 23:36:10
>>690
手元にないのが嫌ならローカルに作ればいいじゃない
0693デフォルトの名無しさん2010/07/26(月) 12:23:28
msysgit と TortoiseGit 使ってるけど、日本語コミットログ絡みでmsysgitコマンドが
うまく動かない場合を除いて、たいていコマンドラインでやっちゃうようになった。

ログ見るのはコマンドラインとGUIの併用だな。

つーかgitとSearchIndexerとカスペの相性災厄。
0694デフォルトの名無しさん2010/07/26(月) 20:31:27
searchindexerと相性っつーか関連があったのか
やたらgit使ってると重くなるときあるなあと思ってたけど
偶然じゃなかったってことか
0695デフォルトの名無しさん2010/07/26(月) 20:38:49
msysGit の UTF-8ファイル名対応版を作りました。
一応、TortoiseGit からきちんとUTF-8ファイル名を扱えることを確認済み。
http://tmurakam.org/git/
本家にもパッチ送っておいたけど、取り込まれるかな、、、？
0696デフォルトの名無しさん2010/07/26(月) 20:41:22
神じゃ
神が降臨なされた
0697デフォルトの名無しさん2010/07/26(月) 21:14:59
hgのfixutf8の強力なライバル出現。
fixutf8の場合リポジトリ毎に有効にするかしないか選択できるんだけど。
0698デフォルトの名無しさん2010/07/26(月) 22:51:48
素晴らしいね。早く分散バージョン管理御三家にもsvn並の
マルチバイト対応がされる日が来ることを祈るよ。
0699デフォルトの名無しさん2010/07/26(月) 23:08:06
>>695
神キターｵﾜﾀ＼(＾o＾)／

0700デフォルトの名無しさん2010/07/26(月) 23:08:28
わるい、ｵﾜﾀ の文字消し忘れた
0701デフォルトの名無しさん2010/07/26(月) 23:51:29
ちょｗ　神は死んだｗｗｗｗ
0702デフォルトの名無しさん2010/07/27(火) 00:44:27
終わっちゃったよ・・・
0703デフォルトの名無しさん2010/07/27(火) 01:14:07
>>695
使ってみました。

全体的にUTF-8のcygwin gitと問題になっている状況が改善しないところがあったので報告
こちら側で何か変なところがあるのかもしれない

・TortoiseGitでそちらのmsysGitのgitパスを設定しmsysGitのバージョンが出ることを確認
・TortoiseGitのコミットダイアログでは、マルチバイトのファイル名は化けず、diffアプリもちゃんと呼べる
・コミット時のProgressウインドウではファイル名表示が化ける（コミット自体は成功）
・TortoiseGitのログ表示でマルチバイトのファイル名が文字化けした。コミットログは文字化けしない。
　文字化けファイル名はdiffアプリに正しく渡すことが出来ない
・そちらのmsysGit UTF-8付属のgitkは、同様にファイル名とdiff表示の中身がUTF-8のファイルが文字化け。
　コミットログはOK
・同じく付属のGit GUIは、マルチバイトファイル名の表示やindexに追加、コミットまでが無事に行けました

捕捉
・msysGit UTF-8でコミットした日本語ログはcygwin gitでもちゃんと見られた
・cygwinのgitkではファイル名は化ける。diff表示ではファイルの中身がUTF-8のものは見られる。SJISは化ける


gitkはcygwinのUTF-8でもおかしいのでtkの問題なのかな。
ファイルの中身がUTF-8なものが化けてSJISは見られるのがよくわからないけど
GitGUIの設定ウインドウ見る限り、.gitconfigは見てくれてるみたいのようだし
07047032010/07/27(火) 01:47:32
>>695
ちょっと状況がよくわからないが少し追加

・msysGit UTF-8をファイラーのコンテキストメニューの"Git Commit Tool"もしくは、"Git GUI"からGit GUIを起動し、
　そこから、メニューのブランチの履歴を選んでgitkを起動した場合、
　ファイル名は文字化けするが、diff表示の中身がUTF-8のファイルは文字化けなし。SJISは文字化け
　オプションの設定を見るに、HOMEの.gitkをちゃんと読んでくれているよう
・逆にコンテキストメニューの"Git History"からgitkを立ち上げた場合は、
　HOMEの.gitkを読んでくれず >>703の通り、
　ファイル名は文字化けし、diff表示の中身がUTF-8のファイルは文字化けする。SJISは文字化けしない
　というdiffだけ逆の状態。
　gitkのオプションで設定を変えても、保存されない

　(一番目)Git GUIから立ち上げた場合はgitの子プロセスでgitkが起動していて、
　（二番目）gitkをそのまま立ち上げた場合はsh.exeから--login オプション起動している点も気になる


cygwin 1.7とgitが既に入っていて、インストール時にshell extentionにGit Cheetah選んだんだけどそれのせいなのかな
ただ、Process Explorerで見る限りはmsysGit側のexeが立ち上がっており、
cygwinのexeが間違って起動されていることはないみたい
07056952010/07/27(火) 03:04:41
どうもありがとうございます。

TortoiseGit 側は文字列が ANSI で出力されてくることを期待しているので、UTF-8 を ANSI に
変換して出力するような修正をいれているんですが、ログが文字化けするということはまだ直しきれて
ない箇所が残っているようです。もう少しソースを追ってみないといけないかな。
gitk で文字化けするのも同じ理由のような気がします。
07067032010/07/27(火) 12:59:00
>>705
こちらこそ助かります

ちょっと長文で書いちゃってわかりにくくなっててすいません

Cygwinの話もまざっているのでmsysGit UTF-8で整理すると

・Git Cheetahのファイラーからのコンテキストメニューから立ち上げた場合の話
・"Git Commit Tool"もしくは、"Git GUI"はコミットログやマルチバイトのファイル名の表示コミットも特に問題ない様子
・上記のGit GUIからgitkを起動した場合、
　・ファイル名は文字化け
　・diff表示がUTF-8のファイルは文字化けしない(SJISは文字化け)
　・$HOME/.gtkなどの設定が反映されている様子
・"Git History"からgitkを立ち上げた場合、
　・ファイル名は文字化け
　・diff表示がUTF-8のファイルは文字化けする(SJISは文字化けしない)
　・$HOME/.gtkなどは無視されている気がする？

Cygwinも入れてある環境なため、環境依存の不具合もありそうです。

ファイルの中身がSJISのものは文字化けするのは不便ですが、今回とは別件の話だと思います
(diff表示に異なるエンコーディングが混ざっている場合の問題でもあるし)

今後も長文になりそうだし、githubのissueに行った方がいいかも
0707デフォルトの名無しさん2010/07/27(火) 13:49:04
githubのissueトラッカーでやったら？
0708デフォルトの名無しさん2010/07/27(火) 13:50:18
>>707
最後まで読まずに書いちゃった。>>706　の最後に書いたあった。
0709デフォルトの名無しさん2010/07/27(火) 15:35:57
modern-gitってのもgithubにあるね。
やはりMinGWでの日本語の扱いをどうにかするのが目的みたいで
C++で実装しなおしてるみたい。
どこまで実装できてるかはよく分からないんだけど（個人的にWindows使わないので）
0710デフォルトの名無しさん2010/07/27(火) 15:59:07
>>709
mingw前提なので華麗にスルー
0711デフォルトの名無しさん2010/07/27(火) 16:01:50
bzr-git/hg-gitで使っているpythonのdulwich使えないのかな？
0712デフォルトの名無しさん2010/07/29(木) 22:20:12
バージョン管理システムってどこから入ればいいの？
何を学べばいいの？
0713デフォルトの名無しさん2010/07/29(木) 22:34:38
>>712
まずはソースコードの変更履歴を失わない感動から学べばいいと思う
次に、変更者が常に追跡出来ることによる疑心暗鬼の解消、心の平穏を味わえば入門は終わり
0714デフォルトの名無しさん2010/07/29(木) 22:41:25
>>712
http://mercurial.selenic.com/wiki/JapaneseTutorial
0715デフォルトの名無しさん2010/07/29(木) 23:04:00
>>712
他人と共同作業して足踏みまくるとこから。
0716デフォルトの名無しさん2010/07/29(木) 23:07:33
>>712
IBM Rational ClearCase か Microsoft Visual SourceSafe だな
0717デフォルトの名無しさん2010/07/29(木) 23:13:18
>>712
RCS
0718デフォルトの名無しさん2010/07/29(木) 23:27:07
>>716
あえて最初は地雷踏ませるのか。
0719デフォルトの名無しさん2010/07/31(土) 14:21:31
>>712
まずはzipとかでソースを公開しているのにバージョン管理のリポジトリをさらさないソフトの作者を罵倒したり、
HDDが吹き飛びましたので開発中止します、というソフトの開発者をこけ下ろすブログエントリーを書いたり
するところから始めたらいいと思う

何かやりとげたい目標があったとき
(この場合は例えば「バージョン管理を使いこなして他のプログラマーよりも優位性を保ちたい」といったような)
まずは自分がその目標をすでに到達しているかのように振舞ったり想像してい行動することが重要
0720デフォルトの名無しさん2010/07/31(土) 14:29:40
>>719
> >>712
> まずはzipとかでソースを公開しているのにバージョン管理のリポジトリをさらさないソフトの作者を罵倒したり、
> HDDが吹き飛びましたので開発中止します、というソフトの開発者をこけ下ろすブログエントリーを書いたり
> するところから始めたらいいと思う
>
具体例が分からんが、forkすればいいだけじゃないの？
0721デフォルトの名無しさん2010/07/31(土) 14:46:20
は？
0722デフォルトの名無しさん2010/07/31(土) 23:17:42
夏はネタにマジレスだよな(tameiki
0723デフォルトの名無しさん2010/07/31(土) 23:52:09
>>712
vadm
0724デフォルトの名無しさん2010/08/01(日) 12:47:44
>>720
cvs/svn import
git/hg commit --date
0725デフォルトの名無しさん2010/08/02(月) 11:27:47
>>719
×こけ下ろす
○こき下ろす(扱き下ろす)
意味は、「しごいて」落とすことだ。つまり、おまいらが日夜やっていることだな。
0726デフォルトの名無しさん2010/08/02(月) 18:29:38
落としてないよageてるよ！！！！！
0727デフォルトの名無しさん2010/08/03(火) 19:57:38
マジレスすれば、TortoiseSVNでローカルレポジトリを作って
自分がよく変更するファイルを管理するとこからはじめるといい。

学んでるときに、それとは関係ない文字コードだとかの問題にひっかかったり、
コマンドライン叩くのはなかなか難しいものがある。普段からコマンドラインに
慣れ親しんでる人なら話は別だが。
0728デフォルトの名無しさん2010/08/03(火) 20:06:19
TortoiseCVSすらあるのにTortoiseRCSは無いのかな？
0729デフォルトの名無しさん2010/08/03(火) 21:56:24
>>728
rcsは分散バージョン管理のカレントパスにレポジトリを作る仕様によって完全に
その役目を後続に明け渡したと思う。

そろそろ休ませてあげてもいいんじゃないかな。
0730デフォルトの名無しさん2010/08/03(火) 21:59:10
TortoiseGit
0731デフォルトの名無しさん2010/08/03(火) 22:21:12
>>729
でもまだメンテされているみたいだね。
http://git.savannah.gnu.org/cgit/rcs.git/
git?!
0732デフォルトの名無しさん2010/08/04(水) 17:48:21
>>727
なぜ分散型でなくTortoiseSVNでローカルレポジトリを作るのか理由を教えてください。
0733デフォルトの名無しさん2010/08/04(水) 17:55:48
GitもHgも現状日本語ファイル名の扱いに問題を抱えてるからな
0734デフォルトの名無しさん2010/08/04(水) 18:00:02
サーバのセッティングは後回しでいいじゃない
0735デフォルトの名無しさん2010/08/04(水) 18:29:06
>>733
SVNは問題無いのですね？
0736デフォルトの名無しさん2010/08/04(水) 18:40:33
>>733
ローカルで使う分には関係ないんじゃないの？
0737デフォルトの名無しさん2010/08/04(水) 18:43:09
SVNのリポジトリを作ってチェックアウトしてtrunk,branches,tagsを追加するのは初心者向けだとは思えません。
0738デフォルトの名無しさん2010/08/04(水) 20:05:15
>>733
但しWindowsに限る
なんじゃなかったっけ？
0739デフォルトの名無しさん2010/08/04(水) 20:12:29
>>738
違います。ロケールに限るです。
Unixではja_JP.EUC-JP,ja_JP.UTF-8であれば問題なく動きます。
0740デフォルトの名無しさん2010/08/04(水) 20:29:58
ロケールだと語弊があるので、
ファイルシステムのパスがバイト列かUnicodeかの違いと
そのAPI(fopen)の違いです。
0741デフォルトの名無しさん2010/08/04(水) 23:14:49
ja_JP.EUC-JPとja_JP.UTF-8だろうが、それらの相互運用は
ファイルパスが(ry

結論：Windowsに限らずまだ無理
0742デフォルトの名無しさん2010/08/04(水) 23:30:38
>>741
Windows上でコミットしたものもLinux上で展開できますが。
何がどう無理なのか具体的に教えていただけませんか？
0743デフォルトの名無しさん2010/08/04(水) 23:50:28
>>742
俺の勘違いならスマン

EUC-JP環境でコミットしたマルチバイトのファイル名などを
UTF-8環境と相互運用できなくない？
0744デフォルトの名無しさん2010/08/04(水) 23:53:25
できなくってよ
07457412010/08/05(木) 00:04:03
悪い、俺の勘違いだったみたいだ
Cygwinで試したが、LANGがja_JP.EUC-JPとja_JP.UTF-8だろうが相互運用できたわ

LANG=ja_JP.EUC-JPでも、UTF-8として扱われるんだな。
マルチバイトなファイル名入れてもUTF-8で記録されて問題なかった。
checkoutやUTF-8環境からのcloneも確認した
0746デフォルトの名無しさん2010/08/05(木) 00:06:06
>>743
相互運用というのが何を意味するのか知りませんが、
コンソールの設定を変えれば、または、nkfを通せばファイル名は化けずに見えますよね？
化けるまでもなくファイルの実態は存在していますが。
07477412010/08/05(木) 00:10:55
>>746
相互運用というのは、ja_JP.EUC-JP環境からコミットしてpushしたものが、
ja_JP.UTF-8環境へcloneしてコミットしpushやpullして問題ない
2つの環境で中央の同じリポジトリ、もしくはお互いのリポジトリを介して開発する、ということを意図してました。

でもgitやhgでそれができないというのが勘違いだったのでもういいです、、、
0748デフォルトの名無しさん2010/08/05(木) 01:46:55
>>746
svnやbzrなら、ファイル名がUnicodeで管理されてチェックアウト時にlocaleに合わせてエンコードされるから、
EUCな環境の人はEUCのファイル名になるし、UTF-8な環境の人はUTF-8のファイル名になる。

相互運用性うんぬんを話しているときは、何もしなくても文字化けしない、EUC-JPのファイル名とSJISの
ファイル名とUTF-8のファイル名がリポジトリ内に混在して存在してカオスなことにならない、ということを
言っているのであって、「バイト列としてはきちんと機能しているよ」という指摘は筋違い。
0749デフォルトの名無しさん2010/08/05(木) 02:00:57
>>748
それじゃあMakefileみたいなのにファイル名が書かれていて
それがファイル名変換で機能しなくなっても問題ないってことなんだね？
0750デフォルトの名無しさん2010/08/05(木) 02:19:59
>>749
それはmakeの問題だから、そもそもMakefileに書くようなファイルはASCIIファイル名にする。
0751デフォルトの名無しさん2010/08/05(木) 02:34:40
>>748
ユニコードってそんな万能じゃないだろ。
特に開発環境で勝手にファイル名いじられるのは怖いから要らない。
0752デフォルトの名無しさん2010/08/05(木) 02:51:15
>>748
仮にEUC-JPとUTF-8のファイル名がコミットで混在しても、分散型なんだから受け入れ拒否すれば良いし、
人間がやるのがいやだったらhookかませば良い。
0753デフォルトの名無しさん2010/08/05(木) 02:58:41
>>751
同感。
bzrもunicodeに変換しないという機能があれば選択肢に入るんだけど。
0754デフォルトの名無しさん2010/08/05(木) 03:02:37
bzrなリポジトリに～(波線)入りのファイル名のファイルをWindowsから突っ込んでこいや
0755デフォルトの名無しさん2010/08/05(木) 03:03:35
このスレ見て、WindowsでSubversion(TortoiseSVN)が猛勢ふるっているのもわかるような気がした
0756デフォルトの名無しさん2010/08/05(木) 03:32:24
ユニコードは万能じゃなかったとしても、マシな解として受け入れられてるだろ。
EUC-JPのバイト列なんてWindowsじゃチェックアウトできないんだ。バイナリ透過型より
ユニコード型の方がクロスプラットフォームで動く確率が高い。

>>754
全く問題ないよ。bzrはWindowsでは基本的にWindowsのW系APIを使うから、cp932とUnicode間の
変換はされない。ネイティブにUnicodeで動く。
0757デフォルトの名無しさん2010/08/05(木) 03:51:09
>>756
＞EUC-JPのバイト列なんてWindowsじゃチェックアウトできないんだ。
Cygwinとかでもダメなの？　リポジトリがUTF8なら大丈夫とか？
0758デフォルトの名無しさん2010/08/05(木) 06:21:59
>動く確率が高い

確率で片付く話なのか？
0759デフォルトの名無しさん2010/08/05(木) 07:27:01
>>756
Eclipseは？
あとDBとか。
0760デフォルトの名無しさん2010/08/05(木) 07:29:42
>>756
UTF-8のファイル名を、ja_JP.EUC-JPでチェックアウトできるの？
0761デフォルトの名無しさん2010/08/05(木) 07:59:22
>>756
> ユニコードは万能じゃなかったとしても、マシな解として受け入れられてるだろ。
誰が受け入れたのですか？
0762デフォルトの名無しさん2010/08/05(木) 09:12:09
あほですか？
0763デフォルトの名無しさん2010/08/05(木) 09:16:14
>>757
cygwinでもだめ。あれはリポジトリ内のバイト列がUTF-8でエンコードされているという
前提で、UTF-8でデコードしてW系APIを呼び出しているだけだから。

>>758
揚げ足取るなよ。クロスプラットフォームで使える文字が多い、で満足？

>>759
Eclipseは使ってないけど、たぶんxmloutputがコンソールで文字化けしないように
ロケールのエンコーディングでxmlを生成していたのが問題で、今問題があったとしたら
もうすぐ直るはず。
DB？なにそれ？

>>760
UTF-8の環境の人は、UTF-8でデコードしたユニコードのファイル名をコミットして、
EUC-JPの環境の人は、ユニコードファイル名をEUC-JPにエンコードしてチェックアウトする。

>>761
CVSでSJIS版とかいろいろ改造版が溢れてよくリポジトリ内で文字化けが発生していたのが、
Subversionに移行してファイル名やコミットログの文字化けなくなって喜んでる人がたくさんいると思うけど？
0764デフォルトの名無しさん2010/08/05(木) 09:30:30
>>763
> DB？なにそれ？
VCSと連携するツールでパス名をDBに保存するものがあります。
0765デフォルトの名無しさん2010/08/05(木) 09:32:07
>>763
> >>761
> CVSでSJIS版とかいろいろ改造版が溢れてよくリポジトリ内で文字化けが発生していたのが、
> Subversionに移行してファイル名やコミットログの文字化けなくなって喜んでる人がたくさんいると思うけど？
CVSからSVNを経由しないでgit/hgに移行したプロジェクトもあるけど？
0766デフォルトの名無しさん2010/08/05(木) 09:35:33
>>763
> >>760
> UTF-8の環境の人は、UTF-8でデコードしたユニコードのファイル名をコミットして、
> EUC-JPの環境の人は、ユニコードファイル名をEUC-JPにエンコードしてチェックアウトする。
>
EUC-JPにないユニコードの文字を含むファイルはチェックアウトできないという認識で良いのですね？
0767デフォルトの名無しさん2010/08/05(木) 09:52:10
>>766
その場合は、ユーザー側でLANG=ja_JP.UTF-8とかしてからsvn coしたら良いだろ。
それでも一つのリポジトリに複数のエンコーディングが混在するよりはマシ。
0768デフォルトの名無しさん2010/08/05(木) 10:30:51
>>767
ユーザにデーモンは入りますか？
0769デフォルトの名無しさん2010/08/05(木) 10:43:46
すごく不毛
0770デフォルトの名無しさん2010/08/05(木) 12:31:24
>>763
> >>758
> 揚げ足取るなよ。クロスプラットフォームで使える文字が多い、で満足？
>
クロスプラットフォームでトラブる文字が多い
0771デフォルトの名無しさん2010/08/05(木) 14:24:14
バイト列で良いって言ってるヤツは、昔WinCVSの改造版とかの設定でハマって、
Subversion登場時に「これでやっとマトモに日本語が使える」って喜んだ経験が無いんだろうな。

新しいものへの移行が遅い日本の中・大企業でも、Subversionへの移行は一気に進んだ。
その原因の一つには、文字化けに辟易していたからだと思うよ。

>>770
クロスプラットフォームでトラブる文字は、バイト透過型の方が非ASCII全体だから多いぞ。
WindowsのようにUnicodeがベースのOSや、MacのようにUnicodeベースのファイルシステムが
存在する以上、Uniode対応は仕方ない。
0772デフォルトの名無しさん2010/08/05(木) 14:44:40
>>771
> バイト列で良いって言ってるヤツは、昔WinCVSの改造版とかの設定でハマって、
> Subversion登場時に「これでやっとマトモに日本語が使える」って喜んだ経験が無いんだろうな。

これで喜んでいるのは、
ログは英語で書くことが決まりだったり、Unix上に日本語ファイル名ファイルを上げることを
禁止されていた経験が無いんだろうな。

商用UnixではSJISロケールがあったからCVSでも問題は無かったという経験は
無かったんだろうな。
0773デフォルトの名無しさん2010/08/05(木) 14:59:57
>>771
そういう経験はないな。
Linuxは10年ぐらい前まではユニコードにちゃんと対応できてなくて
EUC-JPで暮らしてる人がほとんどだった。けどツール側のせいにすることは
なかったよ。Linuxが頑張ってUTF-8に対応した。今ではロケール切り替えでも
端末エミュレータでも主要なテキストエディタも様々な文字コードに対応
してるから、柔軟に使用できる。

バイト列でもUTF-8ならWindowsでもいけるんでしょ？
プロジェクトのファイル名をUTF8で統一すればいいんじゃない？

「ユニコードだと動く確率が高い」とかあやふやな状態で履歴積み重ねるほうが不安だ。
0774デフォルトの名無しさん2010/08/05(木) 15:08:40
>>771
> >>770
> クロスプラットフォームでトラブる文字は、バイト透過型の方が非ASCII全体だから多いぞ。
> WindowsのようにUnicodeがベースのOSや、MacのようにUnicodeベースのファイルシステムが
> 存在する以上、Uniode対応は仕方ない。

なるほど、全世界で圧倒的に使われているiso8859-1の既存資産を破棄しろと。
0775デフォルトの名無しさん2010/08/05(木) 15:14:16
>>772
>> バイト列で良いって言ってるヤツは、昔WinCVSの改造版とかの設定でハマって、
>> Subversion登場時に「これでやっとマトモに日本語が使える」って喜んだ経験が無いんだろうな。
>
>これで喜んでいるのは、
>ログは英語で書くことが決まりだったり、Unix上に日本語ファイル名ファイルを上げることを
>禁止されていた経験が無いんだろうな。

反論になってない。
Unicode対応することで、安心して日本語ファイル名を使えるようになったという主張に反論するなら、
Unicode対応することで発生する問題を挙げて「よくその程度で喜べるな」っていう主張をしないと。
UnicodeはASCII文字を内包しているから、ASCII文字しか使わない環境でも問題ない。

>商用UnixではSJISロケールがあったからCVSでも問題は無かったという経験は
>無かったんだろうな。

いまはクロスプラットフォームの話をしてるんだよ？なんで特定環境で問題ないって話にするの？
0776デフォルトの名無しさん2010/08/05(木) 15:16:51
>>773
>バイト列でもUTF-8ならWindowsでもいけるんでしょ？
>プロジェクトのファイル名をUTF8で統一すればいいんじゃない？

それをツール側で自動的に統一してくれるのが、Unicode対応のバージョン管理システム。

>>774
Unicodeはiso8859-1の文字を含んでるんだから、普通に変換すればいいじゃん。
0777デフォルトの名無しさん2010/08/05(木) 15:21:53
あーｗ cvsの文字化けなつかしい
結局、ごった煮だかのEUC版使っていた気がする


当時、svn出始めにcsv2svnがWindowsでまともに動かなくて、svnに変換できなくてマジトラウマ。
結局、cvsのリポジトリ捨てたな。
最近になって少しは文字コードの知識できたから、環境用意して文字コード意識したらようやく変換できたわｗ


このソフトはバイト列で扱う、Unicodeで扱う、ロケール依存するとか少し文字コードの扱いを知ってて
使い分けられるだけ全然マシだよ！

何が言いたいかというとお前ら全然マシ


0778デフォルトの名無しさん2010/08/05(木) 15:27:12
>>773
> バイト列でもUTF-8ならWindowsでもいけるんでしょ？

現状、gitやhgに関してはツール群がUTF-8にまだまだ対応してない
上でもgitのパッチができたけど、あたりまえだけどUTF-8扱ってくれないツールに渡すと簡単に化ける
CygwinもUTF-8対応と思いつつ、化けたりする

でもgitのUTF-8対応は周辺の対応ツールの開発者がよっぽど頭カチカチじゃなければ
地味にパッチ投げ続ければ対応は時間の問題だと思う

結局UTF-8でツールに渡すのか、とかWindowsで扱いやすいUTF-16で渡すのかとか問題残ってるが

Windowsのコマンドラインに限って言えば、コマンドプロンプトがUTF-8対応してないことは問題ある
こっちはこっちでW系APIで入出力するなどの個別の対応がいるからな



hgの開発者？死ぬ
0779デフォルトの名無しさん2010/08/05(木) 15:31:40
>>775
> 反論になってない。
> Unicode対応することで、安心して日本語ファイル名を使えるようになったという主張に反論するなら、
> Unicode対応することで発生する問題を挙げて「よくその程度で喜べるな」っていう主張をしないと。
> UnicodeはASCII文字を内包しているから、ASCII文字しか使わない環境でも問題ない。

samba2、文字化け
0780デフォルトの名無しさん2010/08/05(木) 15:34:46
何でもかんでもUTF-8で取り回すスクリプト言語
　↓
WindowsのコマンドプロンプトがUTF-8対応してなくて死ぬ
　↓
Cygwinなどの入出力がUTF-8対応のターミナルを使う
　↓
Cygwinのターミナルからだとネイティブアプリのコンソールアプリにまともに入力できない
（主にインタラクティブシェル系や選択を促す系）
　↓
コマンドプロンプトだと入力できるが、化けるのでUTF-8使えない
　↓
上に戻る


いい加減これなんとかしろよ。
UTF-8だとWindowsでも大丈夫とかいう幻想は今の時点ではまともにWindows使ったことない奴の戯言

個別のアプリで対応して回る状況だし、Windows死ぬべきだと思う
0781デフォルトの名無しさん2010/08/05(木) 15:51:19
>>776
> >>774
> Unicodeはiso8859-1の文字を含んでるんだから、普通に変換すればいいじゃん。
Makefile含め全部変換するの？凄いコストだね。
0782デフォルトの名無しさん2010/08/05(木) 15:56:12
PowerShell じゃだめなの？
0783デフォルトの名無しさん2010/08/05(木) 16:03:14
非ASCIIファイル名使うのって、ソースコードじゃなくて、○○画面遷移図.ppt とか、
○○仕様書.xsl とかが多いんじゃないかな？
Makefileの中に非ASCII文字を見たこと無いな。
0784デフォルトの名無しさん2010/08/05(木) 16:09:36
>>783
それは日本人はSJIS/EUC-JP混在に慣れているから。
現在も変わらないのが悲しいけど。
Linuxのデフォルトutf-8ロケール化でやっと海外でも問題が認識されてきているんだから。
0785デフォルトの名無しさん2010/08/05(木) 16:16:39
>>784
海外製のオープンソースアプリでも、Makefileの中に非ASCII文字が入ってるの見たことない。
Latin-1からUTF-8の変換って >>781 が思っているより簡単だと思う。
0786デフォルトの名無しさん2010/08/05(木) 16:16:57
>>783
ぶっちゃけその通りで、非ASCIIのファイル名ってパワポとかワードとか
差分取れないようなファイルに付けるよね。
そういうのってフロント業務の人とかデザイナーの人とかが使うわけだから、
ソースコードとは別のリポジトリにして、そっち系の人が使いやすいTortoiseSVNとか
使ってもらえばいい。んでソースコードは開発者が使いやすい分散型。
0787デフォルトの名無しさん2010/08/05(木) 16:33:39
日本語.datとか日本語.csvとか見て途方にくれたことは無い？
0788デフォルトの名無しさん2010/08/05(木) 18:21:53
>>775
> 反論になってない。
> Unicode対応することで、安心して日本語ファイル名を使えるようになったという主張に反論するなら、
> Unicode対応することで発生する問題を挙げて「よくその程度で喜べるな」っていう主張をしないと。

波ダッシュ
全角チルダ
0789デフォルトの名無しさん2010/08/05(木) 18:29:20
>>788
それはcp932とUnicodeの変換テーブルの問題だよね？
WindowsはUnicodeネイティブだから、Unicodeファイル名をそのまま使えば変換要らないから問題なし。
0790デフォルトの名無しさん2010/08/05(木) 18:30:47
>>789
EUC-JP環境は無視？
Linuxのutf-8でもトラブるけど。
0791デフォルトの名無しさん2010/08/05(木) 21:26:29
>>775
> >商用UnixではSJISロケールがあったからCVSでも問題は無かったという経験は
> >無かったんだろうな。
>
> いまはクロスプラットフォームの話をしてるんだよ？なんで特定環境で問題ないって話にするの？

商用UnixにSJISロケールがあったから日本語Windowsと共有できた。
Linuxがglibc1の時代の話。
だからLinuxではSJISロケールが使えなかった時代の話。EUCでも半角カナに問題があった時代。
0792デフォルトの名無しさん2010/08/05(木) 21:48:05
>>790
EUC-JP 環境の人は、問題があればUTF-8でチェックアウトしたらいいじゃん。
UTF-8で何がトラブルの？
バイト透過型にしたら、それらの文字がLinuxでもMacでもWindowsでも問題なく使えるの？

>>791
何が言いたいのかさっぱりわからん。
クロスプラットフォームなバージョン管理システムがファイル名をUnicodeで扱うべきか
バイト列として扱うべきかという話に、その昔話がどう関係するの？


まず、ファイルシステムやOSのAPIがバイト列な環境とUnicodeな環境がある。
バージョン管理システムがバイト透過型の場合、前者の環境では問題ないけど、
後者の環境ではUnicodeにデコードできずにエラーになる。また、複数のエンコーディングが
1つのリポジトリに混ざる可能性もある。
バージョン管理システムがUnicode型の場合、前者の環境では、適切なエンコーディングで
デコードすればいい。UTF-8なら問題が起こらない。後者の環境では変換が起こらないので
問題ない。

結局、Windowsの事も考量した場合、「入り口で変換」して中身をUnicodeに統一しておくか、
「出口で変換」するかの違いでしかない。
クロスプラットフォームの事を考えた場合、入り口で変換して中身を正規化する方がスジが
良いのはマトモなプログラマならわかるよな？
0793デフォルトの名無しさん2010/08/05(木) 22:20:18
>>792
> >>790
> EUC-JP 環境の人は、問題があればUTF-8でチェックアウトしたらいいじゃん。
> UTF-8で何がトラブルの？

本当にトラブらない？ぐぐればいくらでも情報あるけど。

> >>791
> 何が言いたいのかさっぱりわからん。
> クロスプラットフォームなバージョン管理システムがファイル名をUnicodeで扱うべきか
> バイト列として扱うべきかという話に、その昔話がどう関係するの？

SJISなら何の変換もかからないから安心だよね。
Windows95/98の時代でもSJISならマルチプラットフォームだったって話だけど。

あと、SVNなら本当にSJIS,EUCが混在しない？
LANG=C, LANG=en_US.iso8859-1 だとどんな文字でも突っ込めるからそれこそ悲惨な目に合うけど。

0794デフォルトの名無しさん2010/08/06(金) 02:51:24
>>793
いまどきSJISが良いなんて本気で言ってるの？日本語以外どうすんだよ。
ロケールがSJIS対応したからと言って、SJISの0x5c問題が起こるアプリなんて
腐るほどあるだろうに。
0795デフォルトの名無しさん2010/08/06(金) 03:08:58
>>794
苦情はMicrosoftへ
0796デフォルトの名無しさん2010/08/06(金) 03:34:20
>>795
コマンドプロンプトはSJISだが、ファイルシステムは10年前からUnicodeだよ？
0797デフォルトの名無しさん2010/08/06(金) 03:35:53
\をセパレータにしたこと言ってんじゃないの
0798デフォルトの名無しさん2010/08/06(金) 03:54:31
>>780
＞Cygwinのターミナルからだとネイティブアプリのコンソールアプリにまともに入力できない
＞（主にインタラクティブシェル系や選択を促す系）
ネイティブアプリって、Windowsのコマンドプロンプト向けのアプリってこと？
これさえ解決できればUTF-8でいけるようになるってことかな。

しかし皆さんそんなに日本語のファイル名必須なの？
堅苦しい仕事のドキュメントなんかは日本語のファイル名付けそうだけど、
そっちだけsvnにすればいいのに。
0799デフォルトの名無しさん2010/08/06(金) 03:58:10
＼をセパレーターにしたのは
／がコマンドオプションだったから
つまり
苦情は DigitalResearch (CP/M) へ
になるはず
0800デフォルトの名無しさん2010/08/06(金) 03:59:59
>>798
そういうこと

コマンドプロンプトも
cp 65001
とかで UTF-8 対応になるんだけどバグが放置されてる
0801デフォルトの名無しさん2010/08/06(金) 08:04:00
>>794
> いまどきSJISが良いなんて本気で言ってるの？日本語以外どうすんだよ。
だからLinuxではデフォルトutf-8ロケールがそれなりに受け入れられているんじゃん。
マトモなシステムであれば、
VCSで必須の過去の状態を復元するということすら保証されない
ファイル名がUnicodeに変換されるものなんてとてもじゃないが使えない。
でもファイル名がバイト列であれば、SJIS/EUC-JP/iso8859-1/UTF-8が共存できるじゃん。
0802デフォルトの名無しさん2010/08/06(金) 09:36:36
>>801
>> いまどきSJISが良いなんて本気で言ってるの？日本語以外どうすんだよ。
> だからLinuxではデフォルトutf-8ロケールがそれなりに受け入れられているんじゃん。
なら、少なくとも新しいリポジトリに関しては、Unicodeに統一することでみんな幸せになるよね。

>ファイル名がUnicodeに変換されるものなんてとてもじゃないが使えない。
>でもファイル名がバイト列であれば、SJIS/EUC-JP/iso8859-1/UTF-8が共存できるじゃん。
ここに関しては、お互いの意見が一致することは無いだろうな。
俺は、共存していつまでも文字化けに悩むくらいなら、cvs2svnでちょっと頑張って
Unicodeに統一して、もうバイト列の世界には戻ってきたくない。


だってさ、2010年にもなって、MercurialやGitがいまだに0x5c問題とか、文字化け
とか抱えてるのって、Unicodeにしなかったからだぜ。
0803デフォルトの名無しさん2010/08/06(金) 09:58:58
Unicode, Unicode ってなんとかの一つ覚えみたいに言ってるけど文字コードの話をしているのかエンコーディングの話をしているのかはっきりしてくれ.
utf-8 なんて立派な Unicode だし Unicode の数あるエンコーディングの中でも最も優れていると(個人的には)思うのだが.

もちろん文字コードについて何も規定せずにバイト列, としてしまえば問題もあろうがリポジトリごとに適切なルールの元で使用するエンコーディングを決めればいいじゃん.
それこそ運用上の話.

utf-16 やら utf-32 やらゴミみたいなエンコーディングの話はしないでくれ.資源の無駄遣いだ.
0804デフォルトの名無しさん2010/08/06(金) 10:10:15
パス名として0x5cが問題になるのはSJISと中国簡体字だよね。
それをまともに対応するのであれば、C,C++であればTCHARとかwidecharって話になる。
そのコストを誰が払うのか、誰がテストするのか、誰が問題にならない人に説得するのか、ということ。

LinuxではwidecharでなくcharでUnicode対応できるUTF-8が主流になりつつある。
これで膨大な資産のwidechar化というコストをかけずにUnicodeを使える。

日本語WindowsがCP932でありつづける限り、両者が交わることは無いでしょう。
0805デフォルトの名無しさん2010/08/06(金) 12:10:37
昔、sambaサーバーがぶっ壊れた時にWindowsから作った日本語名のファイルが
Unixのコマンドラインからは文字化けしてツールがエラーはいてサルベージできず、
別のUnixマシンにつないでsamba経由でWindowsから恐る恐るコピーしてバックアップしたの思い出したｗ

今思うとdumpすればよかんたんじゃね？とか、LANGとかsambaの文字コードなんで気にしないで使ってたんだよと思うがｗ
0806デフォルトの名無しさん2010/08/06(金) 12:17:32
>>802
> だってさ、2010年にもなって、MercurialやGitがいまだに0x5c問題とか、文字化け
> とか抱えてるのって、Unicodeにしなかったからだぜ。

Ruby 1.9がCSI方式だっけ？内部Unicodeに統一してなくても動いているし、
Unicode統一が絶対とは思わんけど、
だからってバイト列にすればいいってもんでもないな

Rubyのm17nで調べててPython 1.6でUTF-16になってるとあるけど
A Reintroduction To Ruby M17 N
http://www.slideshare.net/nalsh/a-reintroduction-to-ruby-m17-n

gitはともかくMercurialどうしてああなってんのｗ
0807デフォルトの名無しさん2010/08/06(金) 12:30:47
>>804
これマジでなんとかならんもんかねえ

ASCII圏のどうでもいいと思っている人たちがWindowsに移植する時や実装時にA系APIで実装する
↓
問題が出る環境の人たちが延々とA系APIをW系APIに書き換えて回る作業
及び、パッチもかかずに掲示板なんかでぎゃーぎゃーさわぐ連中の構図ｗ



Cygwin 1.7でLANG=ja_JP.UTF-8で使えば、多くの場合問題ないけど
Cygwinだけで閉じてるだけならまだいいが、
結局既存のツールとの連携が面倒なことになるの変わらん(面倒でないならTortoiseGitがなんでCygwinのgitとまともに連携できないのか？)

あとCygwin 1周り遅い。氏ねよ


0808デフォルトの名無しさん2010/08/06(金) 13:26:45
>>803
内部コードがUTF-8等で統一されているならUnicode型だし、単にユーザーが
UTF-8を使うってだけならバイト透過型。
Windowsでコマンドライン引数をバイト列で受け取るならバイト透過型、
UTF-16で受け取ってUTF-8などの内部表現に変換するならUnicode型。

リポジトリごとにルールを決めて運用する場合、ツール側にUTF-8への変換をするか
しないかの設定があるなら良いけど、実際のバイト透過型バージョン管理システムって
そうなってないだろ？
Windowsユーザーにとって、UTF-8使おうとしたらcygwin使うしかないのが現状だ。

>>804
svnやbzrはそれ(wcharでWindows API呼び出し)をやってる。

>>806
RubyのCSI方式は、変換が必要ない場合まで変換するのを避けるのが目的で、
マシン間で交換するデータの場合は、RubistでもUnicode選ぶと思うよ。
0809デフォルトの名無しさん2010/08/06(金) 14:14:33
>>808
> リポジトリごとにルールを決めて運用する場合、ツール側にUTF-8への変換をするか
> しないかの設定があるなら良いけど、実際のバイト透過型バージョン管理システムって
> そうなってないだろ？

hgのfixutf8
0810デフォルトの名無しさん2010/08/06(金) 16:33:04
Windowsの日本語ロケールがUTF-8になったらすべて解決
0811デフォルトの名無しさん2010/08/06(金) 17:47:19
>>809
hgの拡張機能は、
Windowsの場合プロファイル直下のmercurial.ini、
Unix(cygwin)の場合~/.hgrcで設定すればグローバルで有効。
ここで有効にしなくても、各リポジトリの.hg/hgrcで
リポジトリ毎に有効にできる。

0812デフォルトの名無しさん2010/08/06(金) 21:19:59
結局バイト透過型はWindowsサポートするにはUTF-8頼みなんだから、
最初からsvnやbzrみたいにUCS方式にしておけばよかったのに。
0813デフォルトの名無しさん2010/08/08(日) 19:43:14
文字コード詳しくないけど、MercurialのデフォコードはUTF-8にしてしまえば
欧米の人たちにはほとんど影響が出ないで
あとは表示的な部分だけこっちに合わせればOKってなりそうだけどそんな簡単な話ではない？
0814デフォルトの名無しさん2010/08/08(日) 20:00:24
>>813
UTF-8だとWindowsでいろいろうまくいかないんだってさ
0815デフォルトの名無しさん2010/08/08(日) 20:16:05
ああ、Win日本語版だと
デフォ文字コードがSJISでW系API使ってもUTF-16か
既存の環境でも動かそうとしたら.hgで指定するぐらいしか方法なさそうだな。
でfixutf8で騙しながら使うと。

0816デフォルトの名無しさん2010/08/08(日) 21:55:29
>>813
デフォルトは既存のものとの互換性の問題があるから議論があると思う。
どちらかというとインストーラの話。

インストールもPythonなのでいろんなインストール方法がある。

hgのWindowsにはwin32mbcsとfixutf8という２つの解決方法があって、
win32mbcsはhgの本体に取り込まれている。

win32mbcsはだめなエンコード以外には機能しないしくみには
なっているんだけど、これも現状ではデフォルトでは有効になっていない。

fixutf8は本体には取り込まれていないので、自己責任。
0817デフォルトの名無しさん2010/08/08(日) 22:12:01
前にMercurialのfixutf8教えてくれた人サンクス

win32版で多分CP932で入れてしまっていたコミットログだったかファイル名だったかわすれたけど、
CygwinのUTF-8環境のhgにうまく移行できたみたいだわ

0818デフォルトの名無しさん2010/08/08(日) 22:22:07
>>817
ログはね、HGENCODINGという環境変数か、
--encoding というコマンドラインオプションがあるね。
0819デフォルトの名無しさん2010/08/28(土) 06:31:12
質問させてください。

Windowsから簡単に前のバージョンにもどしたり、特定のバージョンのものが簡単に取り出せたりできる
バージョン管理環境とツールの組み合わせはないでしょうか？

対象としてはプログラマーではない、デザイナーさんやその他の作業する人にでも使ってもらえるイメージです

現在、起こっていて困っている問題がありまして、履歴管理したいファイル郡があった場合、
それらをいかに簡単に履歴管理するか？という問題があります

例えばgitだとその場でユーザーレベルでもリポジトリを簡単に作れますが、
コマンドライン環境が主、マルチバイト絡みという点でプログラマー以外に使ってもらうのが困難です。
(日付分けしたディレクトリでいいじゃん、というのが勝ってしまうレベル)

TortoiseSVNではサブディレクトリに.svnができてしまう。
ローカルにリポジトリを作るにしてもsvnの構造を意識しないといけないようにできている
（Subversionのフロントエンドなので当たり前ですが）。

また、TortoiseSVNといえでもバージョン管理の知識が要求され、セットアップ時も
ssh接続ならputty、pageantなどの連携も必要、公開鍵、秘密鍵などの用意も個別に必要ということからセットアップ導入の敷居が高いです。
（あくまでプログラマー以外へ導入する場合の話です）

大概はDropboxは問題なく使える、個人的に使っているメンバーばかりなので、
UIや仕組みが簡単であれば導入はできそうなのですが、よい環境はないでしょうか？

pdumpfsをファイルサーバーで動かして部分的に世代管理を導入する、というのも考えたのですが、
手軽に元の古いファイルにアクセスできるようにするためには、
必要なときのみバックアップをマウントしてなどの操作が必要だったり、
ちょっとした環境を作る必要性を感じてしまいます。
0820デフォルトの名無しさん2010/08/28(土) 07:15:04
>>819
BunBackupとかで世代管理でもしてろ
0821デフォルトの名無しさん2010/08/28(土) 07:38:52
>>819
中身はバイナリ・テキストどちらですか？
0822デフォルトの名無しさん2010/08/28(土) 07:50:05
>>819
rsync --link-dest
0823デフォルトの名無しさん2010/08/28(土) 07:56:35
>>823
VSS
0824デフォルトの名無しさん2010/08/28(土) 07:58:37
>TortoiseSVNといえでもバージョン管理の知識が要求され

これが問題になるんだったら、それこそ

>日付分けしたディレクトリでいいじゃん

しかしょうがないんでは。

しかし、俺はTortoisegitって使ってないから分からんが、
Windows限定で使っても日本語とかで何か問題あるんですかね?
無いなら、亀git入れさせて「とにかくひと段落の度にコミットしろ、
そのとき変更概要コメントも書け」でもいいんじゃないの?
0825デフォルトの名無しさん2010/08/28(土) 08:06:15
>>824
亀svnでも敷居が高いんじゃ、gitなんてムリでしょ。。。
利用者の習得コストを０にしたいのであれば、日付ディレクトリしかない。
0826デフォルトの名無しさん2010/08/28(土) 08:20:40
rsyncの --link-destってのは、変更が無い場合ハードリンクを作るから容量の節約が出来る。
夜間JOBか何かで日付のディレクトリを作って、そっちをSambaなりの読み込み専用にすれば終わり。
0827デフォルトの名無しさん2010/08/28(土) 09:00:56
DAVにしてサーバ側で定期的にコミットすれば、
ユーザー側からは単なるネットワークフォルダになるよ。
0828デフォルトの名無しさん2010/08/28(土) 09:30:37
>>819
> 例えばgitだとその場でユーザーレベルでもリポジトリを簡単に作れますが、
> コマンドライン環境が主、マルチバイト絡みという点でプログラマー以外に使ってもらうのが困難です。

日本語が完璧に使えると宣伝されているbzrは？
0829デフォルトの名無しさん2010/08/28(土) 11:04:05
>>819
現状Windowsで一番導入楽なのはTortoiseSVNだろうなぁ。
サーバ側はsvnserveにすればsshとか余計なこと考える必要はない。
0830デフォルトの名無しさん2010/08/28(土) 11:11:12
導入が楽なのも、プログラマ以外が使いやすいのもVSSだろ
0831デフォルトの名無しさん2010/08/28(土) 11:15:33
どのバージョン管理ツールも多少の知識が必要なのは同じ。
リモートで SSH の設定が面倒なのも同じ。
まあ SSH に関しては、接続ユーザーとキーを同じにして手順化してしまえば、
だいぶ簡単になる。

どうしても使わせたいなら、セットアップはしてあげる、基本的なコミット＆プッシュを教えておいて、
何かあるたびに面倒見てやるしかないんじゃないかな。

残念なことだが、バージョン管理ツールはプログラマにも敷居が高いからねぇ。
0832デフォルトの名無しさん2010/08/28(土) 11:18:08
vssってなんの略なの?
Visual SourceSafe ?
Volume Shadow Copy Service ?
0833デフォルトの名無しさん2010/08/28(土) 11:22:43
>>830
VSSは、そろそろサポート的な意味で導入が面倒になってくるような気がする。
http://www.microsoft.com/japan/msdn/vstudio/campaign/vsstotfs/
こんなページがあるくらいだし。
0834デフォルトの名無しさん2010/08/28(土) 13:21:04
うちの場合一般的な業務用の文章ならGoogleDocs使ってもらうのが一番効果的でした。
結局コンフリクトの解消とかマージの仕組みまで理解をいただかないとどのバージョン管理ツール使っても共同編集は頓挫してしまいます。
親の分からんファイル持ってこられて、「マージしといて。バージョン管理できるんでしょ？」と言われるのがオチです。
0835デフォルトの名無しさん2010/08/28(土) 13:26:12
>>834
それならwikiで十分という話になっちゃう。
wikiなら履歴も残るしdiff/blameもあるし。
0836デフォルトの名無しさん2010/08/28(土) 13:35:34
WikiでVCS並みに履歴とっておいてくれるのってMediaWikiレベルじゃないとないんじゃね？
0837デフォルトの名無しさん2010/08/28(土) 13:38:23
>>836
bitbucketのwikiがMercurialで管理されているのでcloneで持ってこれます。
0838デフォルトの名無しさん2010/08/28(土) 13:47:41
trac
0839デフォルトの名無しさん2010/08/28(土) 14:08:07
Redmine
0840デフォルトの名無しさん2010/08/28(土) 14:26:10
自鯖で運用できるDropboxクローンがあればいいのにね
0841デフォルトの名無しさん2010/08/28(土) 16:02:18
>>835
それが、「エクセルとワードの格好」をしていないと触っていただけないんです。
スプレッドシートで編集中の他人のカーソルが自分の窓で見えるというのが興味をひいたようでしたね。
個人的にはgitを使ってますが使う必要のある人間に使ってもらわないと始まらない、と痛感する事しきりです。
0842デフォルトの名無しさん2010/08/28(土) 16:11:14
俺は bzr 使ってるけど、SCM 使えないアホと一緒にやってたときは、
そいつ用のブランチ作って「このフォルダで作業しろ」って渡してやって
コミット、マージは俺がやってたな。一人、二人だからそんなことできたけど。
0843デフォルトの名無しさん2010/08/28(土) 16:34:38
>>841
ワードなんかWikiでも十分だと思うけど、ワード自身が履歴とdiff/blameを持っちゃっているしね。
エクセルも表計算ソフトとして使われていない場合がほとんどだし。
0844デフォルトの名無しさん2010/08/28(土) 17:24:28
>833
Team Foundation Serverって、結構高いんだね。
2人で使うだけでも、
Team Foundation Server(380k) + Team Foundation Server CAL(\68k) * 2
+ Windows Server 2008R2 (\100k?)
で、60万円超かかるのか。
0845デフォルトの名無しさん2010/08/28(土) 17:46:15
これで良いんじゃね？
3．シャドウ・コピーによるバックアップ
ttp://www.atmarkit.co.jp/fwin2k/vista_feature/06backup/06backup_04.html
0846デフォルトの名無しさん2010/08/28(土) 18:02:43
>>844
ライセンスはよくわからないが、
2010からは、MSDN Professional 以上で入手できるのでだいぶ安くなると思うよ。
0847デフォルトの名無しさん2010/08/28(土) 23:26:49
VSSとはいったいなんだったのか。。。
MSでも黒歴史扱い？
0848デフォルトの名無しさん2010/08/29(日) 00:00:38
あれはビギナー (初心者) 向けのソフトだ。
0849デフォルトの名無しさん2010/08/29(日) 00:30:10
違うよ。情弱向けのソフトだよ
0850デフォルトの名無しさん2010/08/29(日) 00:40:55
VB5くらいの頃は十分使えたソフトだった。
Subversion他いろいろ選択肢のある今となっては使う意味がないってだけだ。
0851デフォルトの名無しさん2010/08/29(日) 00:53:22
ACCESSのコードの修正の
差分をどうやって取ればいいのですか？
VSSならできるのに・・・
0852デフォルトの名無しさん2010/08/29(日) 00:58:52
ある程度妥協点を用意したら、後は「仕事なんだから黙ってやれ。今求人すれば1日で集まるんだぞ？」で終わり
我侭言われただけでルールを運用できないシス管ほど無用な人間も居ない
0853デフォルトの名無しさん2010/08/29(日) 02:17:31
>>852
諸刃の刀だな。
0854デフォルトの名無しさん2010/08/29(日) 06:51:31
>>847
未だにバイナリを多く扱うデータの管理したいときは選択肢に入ると思うけど。
逆にバイナリ扱う人でVSSが選択肢に入らない人はいつも何を使っているか気になる
PerforceとかAlienbrain？
0855デフォルトの名無しさん2010/08/29(日) 07:04:36
このスレにバイナリを扱ってる奴なんて居ない　が正解
0856デフォルトの名無しさん2010/08/29(日) 07:29:40
>>855
このスレにはいないかもしれないけど、Subversionスレではバイナリはロックをかけるという話があった。
0857デフォルトの名無しさん2010/08/29(日) 07:36:01
>>854
海外でMercurialからgitに移った人の理由でMercurialは差分で持っているからバイナリのでかいファイルが重いけど
gitは差分じゃないから速いというのがあった。
この対応か知らないけど、Mercurialではバイナリのでかいファイルを扱う拡張がいくつか開発されている。
0858デフォルトの名無しさん2010/08/29(日) 08:44:53
>>856
Subversionを選択したときは、当然バイナリファイルにはロック使う訳なんだけど
Subversionの場合はコミットとロックが別になっているので、ヒューマンエラーが起こりやすいんだよね。
これがはなはだデザイナに評判が悪い。

>>857
一度比較的大きなプロジェクトでバイナリの転送速度がネックになったときに、
gitを検討してみたんですが、ファイルのロック機構にあたるものが見つからなくて断念しました。
本当はあるのかな？gitでバイナリを扱っている人に聞いてみたい。
0859デフォルトの名無しさん2010/08/29(日) 10:27:42
MSの中の開発陣は、昔からVSS使ってないってね。
何使ってるんだろ
0860デフォルトの名無しさん2010/08/29(日) 10:46:18
>>858
そもそもgitの場合、バイナリでロックかける必要あるのか？
0861デフォルトの名無しさん2010/08/29(日) 10:49:59
>>860
バイナリのマージってできるのか？
0862デフォルトの名無しさん2010/08/29(日) 10:56:23
>>851
Accessもバージョン管理できるよ
アドイン(アドオン?)でVSSにアクセスできるようになる
アドレスは忘れたけど、ググれば見つかる
0863デフォルトの名無しさん2010/08/29(日) 11:40:08
>>858
バイナリファイルにはロックの意味が分からないんですが、
ロックってRCSのロックみたいなの？　てかSubversionってロックあったのか。
0864デフォルトの名無しさん2010/08/29(日) 13:32:16
>>859
MSは自社のドッグフードを食べるんじゃなかったのかよ。
客にドッグフード勧めといて、自分たちはステーキを食ってたなんて。。。
0865デフォルトの名無しさん2010/08/29(日) 16:27:35
>>858
分散バージョン管理にはロックという概念自体無いような
0866デフォルトの名無しさん2010/08/29(日) 16:28:02
>864
そりゃ、VSSは少人数チーム専用の設計だから、MSが使わないのはしょうがない。
0867デフォルトの名無しさん2010/08/29(日) 16:41:56
>>865
bzrも無いの？svnっぽいのが売りのようだけど。
0868デフォルトの名無しさん2010/08/29(日) 17:03:14
Subversionに*.jar入れるのやめてくれ、って思うのだがそういうものなのか？
0869デフォルトの名無しさん2010/08/29(日) 17:05:53
UI用のpngファイルとかは入れざるを得ないだろ。
0870デフォルトの名無しさん2010/08/29(日) 17:20:53
>>868
ソースから生成されるものはバージョン管理に含める必要は無い。exeとかobjとか

ただし、リリース版の最終バイナリくらいは残したほうが便利だと思う。
0871デフォルトの名無しさん2010/08/29(日) 17:26:24
>>870
Eclipseで簡単に開発環境が構築できるって、ダウンロードした*.jarを入れているのよ。
0872デフォルトの名無しさん2010/08/29(日) 17:53:57
ダウンロード出来る.jarファイルが、いつまでダウンロード出来るかは
誰も保証してくれないからな。
0873デフォルトの名無しさん2010/08/29(日) 17:56:45
>>871
じゃあ逆に聞くが、5年後にそのソースのビルドが必要になったらお前はどうするつもりだ？
0874デフォルトの名無しさん2010/08/29(日) 18:01:19
>>871
まあリポジトリが膨れ上がらない限りはビルドに必要なものはまとめて入れておくのはありだろう。
0875デフォルトの名無しさん2010/08/29(日) 18:12:22
jar入れるのをやめてほしい理由ってなんだろう
0876デフォルトの名無しさん2010/08/29(日) 18:16:52
mavenでできることをsvnでやる理由が分からない。
ダウンロードできなくなるのも内側で別に保存しておけば良い。
0877デフォルトの名無しさん2010/08/29(日) 18:20:37
無理に使うツールを増やすこと無いだろう。
チェックアウトひとつで完全なビルド環境が再現できるほうがメリットあるだろう。
0878デフォルトの名無しさん2010/08/29(日) 18:21:19
なぜ突然mavenが出てきたのか理由が分からない。
0879デフォルトの名無しさん2010/08/29(日) 18:41:13
>>860
バイナリマージのマージができないとなると、
ロックして作業中は他の人が作業出来ないようにするか
バイナリ作成者のお互いの意思疎通で解決するしかない気がするんですが、
必要ないんですか？

>>863
RCS使ったこと無いんですけど、ドキュメント読む範囲では同じようなことを実現するためにあると思います。
もしロックが必要な理由がわからないという質問だったら、上記の通りです。
0880デフォルトの名無しさん2010/08/29(日) 18:59:51
>>879
バイナリで無くてもお互いの意思疎通は必要じゃないか？
テキストだってマージでコンフリクトするときはするんだから。
0881デフォルトの名無しさん2010/08/29(日) 19:58:33
>>879
ワード、エクセルのような仕様書なのか、画像なのか、exe・pdfなどの成果物なのかで考え方が違うと思うけど。
0882デフォルトの名無しさん2010/08/29(日) 21:36:08
>>868
悪い。*.objいれてたことある。*.oだったかも
*.objにコンパイルできなくてもリンクはできる環境だったんで、
コンパイル済みファイルも入れるのもよくやってたよ
0883デフォルトの名無しさん2010/08/29(日) 21:51:19
ゲーム作ってたときは、中間生成ファイルはいれなかったがexeやdllは入れておいたな。

バグがでたときに特定のバージョンをチェックアウトしてすぐ動かせるようにしておくと
プログラマ以外でもテストやレポートできて便利だったんだよな
0884デフォルトの名無しさん2010/08/29(日) 22:26:19
>>879
Git使ってるけど、バイナリファイル＝マージ出来ないファイル と思ってやってるな。

バイナリファイルでも個別に対応すれば差分出せるけど、人が読める差分が出せるなら
それはマージが出来るということで、マージが出来るってことはロックなんか必要ない
ってことになる。

まあバイナリか否かといってもいろいろで、リッチUIなオフィススイートが
吐き出す構造化テキストなんかはテキストとは言いつつも差分出してもワケワカメで
マージ不能だったりするから、意味的にはバイナリみたいなものだね。
0885デフォルトの名無しさん2010/08/29(日) 22:54:07
>>867
分散型の場合、特定のファイルを他人に扱わせない為には、そのレポジトリの
クローンやブランチ全てがロックしたことを知らねばならない。
そのような伝達は事実上不可能(オフラインの場合もあるから)

仮にそのような仕組みがあっても、ロックより先に別のローカルコミットされる
可能性もあるわけで、それがマージできないようなものなら、そのコミットを
破棄するしかないから、ロックが無い場合と変らない。
0886デフォルトの名無しさん2010/08/29(日) 23:38:07
つまり、必要なのはツールよりもコミュ力、って事だな。
0887デフォルトの名無しさん2010/08/30(月) 01:13:04
つまり情報伝達に無駄な手間がかかる欠陥システムって事だな
この場合は
08888842010/08/30(月) 01:25:24
>>887
その手の用途には専用のものを使えよ。VCSでタスク管理までやるほうがおかしい。
0889デフォルトの名無しさん2010/08/30(月) 02:20:45
>>888
んなもん対応できるわけねぇだろタコスケが
もっと現実を認めろ
0890デフォルトの名無しさん2010/08/30(月) 02:21:56
いや、最近のSCMの流行はタスク管理も含んでるだろ。
MSのTeam FoundationとかIBMのJAZZとか
0891デフォルトの名無しさん2010/08/30(月) 04:11:52
>>890
どうしても一体にする必要があるのかね。
LaunchpadやTracみたいにVCS連携方式のほうが、いろいろ選べて便利。
0892デフォルトの名無しさん2010/08/30(月) 04:26:23
>>891
そうか、便利で良かったな。
こっちも便利なんだよ。良いだろう。
0893デフォルトの名無しさん2010/08/30(月) 07:51:58
このスレが「バージョン管理システム」ってなっているけど、SubversionとかはあくまでSCM。
つまりソース管理。
そこにバイナリを入れるのはやっぱり違うと思うけどな。
バージョン管理っていうとmavenやらruby gemsやらのビルド管理じゃないか。
HudsonやTrac/Redmineとの連携とかも。
0894デフォルトの名無しさん2010/08/30(月) 08:17:38
？？？
0895デフォルトの名無しさん2010/08/30(月) 08:30:35
tarボールとかって、何とか-x.y.z.tar.gzってなっているじゃん。
0896デフォルトの名無しさん2010/08/30(月) 13:30:53
Linuxのバージョン管理システムはgitだそうでつね。

コンパイルやコピー等のリリースツールってのは何が使われてるのでしょう。

というか、リリースツールってどんなんがあるのでしょうか？
0897デフォルトの名無しさん2010/08/30(月) 15:37:52
>>896
http://www.jp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.4.tar.bz2
Kernelならここから落とせますので自分でコンパイルして確かめてみてくださいｗ
0898デフォルトの名無しさん2010/08/30(月) 15:58:25
>>896
make distが一般的だと思うけど、Linuxカーネルは分からない。
08998962010/08/30(月) 16:32:32
㌧

あ、Linuxやそのカーネルが知りたいのじゃなくて、
できた実行モジュールをファイルコピーしたりする
リリース用ＧＵＩツールってあるのかなぁ、と。
0900デフォルトの名無しさん2010/08/30(月) 16:39:24
Linuxのバージョン管理システムはgit、なんて書かれていたら
カーネルについて聞いていると思うのはしかたがない。
0901デフォルトの名無しさん2010/08/30(月) 16:41:42
なんで？
0902デフォルトの名無しさん2010/08/30(月) 16:49:34
>>899
また良くわからん質問だが、
rpmやdebやconfigure --prefix= のことを言っているのか？
それをGUIってことか？
0903デフォルトの名無しさん2010/08/30(月) 16:49:36
gitはlinuxカーネルの版管理に使うために作られた、は真だが、
linuxでうごくもろもろのソフトウェアの開発においてgitを使う
義務はないから。
0904デフォルトの名無しさん2010/08/30(月) 16:50:15
>>901
gitの歴史をwikipediaで読みましょう。
0905デフォルトの名無しさん2010/08/30(月) 16:56:27
夏休みって終わったんじゃなかったのか？
0906899=8962010/08/30(月) 16:57:31
>>902
いや、だから、リーナスがLinuxをmakeした後、
各サーバーにコピーするのは、
手じゃなくてツールでやってるのでは？
と。

そういうツールがあるなら欲しい。
gitはいつか使おうかと思ってるが、分散リポジトリまでまだ要らないし、、、
0907デフォルトの名無しさん2010/08/30(月) 17:02:44
>>906
Linuxカーネルは知らないが、github/bitbucketはタグが付いたものはtarボールで自動で落とせる。
09089062010/08/30(月) 17:03:49
いや、ソースの落とし方じゃなくて、
配布ツール。。。
0909デフォルトの名無しさん2010/08/30(月) 17:09:37
>>908
配布はディストリビューションのお仕事でしょ？
0910デフォルトの名無しさん2010/08/30(月) 17:10:03
>>900
ただの文盲じゃん。はっきりリリースツールって書いてあるのに。
09119082010/08/30(月) 17:15:56
>>909
単一のバイナリを全世界でテストするため、リーナスが各サーバーに配布しなきゃならんでしょ？
0912デフォルトの名無しさん2010/08/30(月) 17:22:51
>>911
単一のバイナリを全世界でテストするため、MSが(ry
0913デフォルトの名無しさん2010/08/30(月) 17:26:32
> 単一のバイナリを全世界でテストするため

そんな、やってもいないことをやるためのツールを尋ねられても……
0914デフォルトの名無しさん2010/08/30(月) 17:33:28
どこで聞きかじってきたのか知らないけど、なんかものすごい勘違いしてるねえ
0915デフォルトの名無しさん2010/08/31(火) 01:01:33
ソースしか信じない人らにバイナリの事聞いても無駄無駄
環境も文化も違う
0916デフォルトの名無しさん2010/08/31(火) 01:54:19
>>891
Team Foundationなんかは、ソースのチェックインにタスク上の問題に関連した制限がかけられる。
制限条件を通ってないとチェックイン出来ない。
制限の条件としてビルドが通ってるか？、バグが直ってるか等。
Jazzはチェックインされたソースを集めての定期ビルドのスケジューリング、直ったバグに対するリグレッションテスト等も管理できる
これからのSCMは単純なソース管理だけじゃなくて、こういう方向に向かうんじゃないかな
0917デフォルトの名無しさん2010/08/31(火) 02:17:26
＞制限条件を通ってないとチェックイン出来ない。
＞制限の条件としてビルドが通ってるか？、バグが直ってるか等。
信じがたい話だが、こういうのを有り難がる人たちも居るんだね。。。
0918デフォルトの名無しさん2010/08/31(火) 02:20:37
せっまい所の蛙ちゃんほどよく鳴く
0919デフォルトの名無しさん2010/08/31(火) 02:26:13
その辺の機能はアホ避けだからなあ。
そもそもアホを参加させないで済むなら不要。
0920デフォルトの名無しさん2010/08/31(火) 03:27:59
>>919
ケアミスしない神かお前は
そんな機械でも出来る心底下らん事に１ミリでも気を回す位なら他の生産的な事やるわ
0921デフォルトの名無しさん2010/08/31(火) 03:41:05
そのうちにスペルチェッカまで搭載するようになるのか
0922デフォルトの名無しさん2010/08/31(火) 03:44:21
オートコレクトって形でとっくに搭載されてるだろ
全部手打ちしてるなら無能としか言いようが無い
0923デフォルトの名無しさん2010/08/31(火) 04:18:10
>>922
エディタとかじゃんくて、バージョン管理システムに搭載されてんの？
すげぇな
0924デフォルトの名無しさん2010/08/31(火) 05:07:00
すまん>>921がそこまでブッ飛んだ発言だとは読み取れなかった
0925デフォルトの名無しさん2010/08/31(火) 05:18:05
ビルド通貨してないとチェックインできないんなら、
ついでにスペルチェックもしてくれても良いかもね
0926デフォルトの名無しさん2010/08/31(火) 05:41:16
>>917
余計なお世話だよな
チェックイン→テスト→幹にマージだよな。
0927デフォルトの名無しさん2010/08/31(火) 05:51:04
俺が納得した時が納期だな世界の方々は悠長で居られてうらやましすなぁ。
0928デフォルトの名無しさん2010/08/31(火) 07:25:59
>>916
> 制限条件を通ってないとチェックイン出来ない。
タスクの登録時に問題があるかどうかのテストケースがチェックインされていないとタスクが登録できない。

> 制限の条件としてビルドが通ってるか？、バグが直ってるか等。
単一バイナリでビルドが通るのが条件だから全世界のサーバに配布して
テストしないとチェックインできない。
32bit/64bit、Windows/Linux/Unixでビルドができないとチェックインできない。
外部要因もチェック要因だから、svn:externalsみたいなのを登録しないといけない。
0929デフォルトの名無しさん2010/08/31(火) 07:44:35
>>928=>>896か…
0930デフォルトの名無しさん2010/08/31(火) 07:44:40
イミフ
0931デフォルトの名無しさん2010/08/31(火) 07:46:22
俺は916と896をネタにしたアンチMS()君だと思うけどな
0932デフォルトの名無しさん2010/08/31(火) 07:47:00
問題は、このスレがSCMについて語るスレかどうかという点だ
0933デフォルトの名無しさん2010/08/31(火) 07:55:44
>>932
Source Code Management
Software Configuration Management
どっち？
0934デフォルトの名無しさん2010/08/31(火) 09:05:02
>>906
そういうのはスクリプト言語とかシェルでもいし、sshでも使えばいくらでもできそうなもんだけど

既存のライブラリとかツールセットがほしいなら、
RubyのCapistranoとかいろいろあるはず

>>916
Hudsonとか継続的インテグレーションツールってそんな感じなんじゃないの？
使ったこと無いから実際はしらんけど
0935デフォルトの名無しさん2010/08/31(火) 09:31:33
>>934
Hudson+Trac/Redmine+VCSみたいだけど
0936デフォルトの名無しさん2010/08/31(火) 12:25:32
> 単一バイナリでビルドが通る

これが既にイミフだな。
0937デフォルトの名無しさん2010/08/31(火) 12:59:30
>>933
Something Configuration Management
0938デフォルトの名無しさん2010/08/31(火) 13:00:10
>>936
JAVA/CLR
0939デフォルトの名無しさん2010/08/31(火) 15:20:50
pre-commit-hook とか書いてると
事前チェックは実際ありがたいよ。
0940デフォルトの名無しさん2010/08/31(火) 20:02:16
今時チェックイン時に自動ビルド&自動テストが普通だろ。
0941デフォルトの名無しさん2010/08/31(火) 20:54:34
あれ、WordだのExcelだののは差分表示出来るんでなかったっけ
画像とかが問題なのか
0942デフォルトの名無しさん2010/08/31(火) 21:27:13
>>940
チェックインって、RCS、VSS以外に使っている？
0943デフォルトの名無しさん2010/08/31(火) 21:35:30
>>942
subversion
0944デフォルトの名無しさん2010/08/31(火) 22:58:26
"チェックアウトの取り消し"
0945858=8792010/08/31(火) 23:06:22
皆さんレスどうもです。
>>881
画像・モデルデータ・モーションデータ等のリソースです。
これらをコンバートして実際に使用するデータに変換します。
そういう意味ではテキストではない（バイナリの)ソースとも言えるかもしれません。

>>884-885
やはりバイナリだからロックするとかってことは分散型だと出来ないんですね。
設計思想から多分そうだろうとは思っていたんですが、分散型をあまり深く使ったことがなかったので
イマイチ自信が持てませんでした。

>>880
>>886
確かにコミュニケーションも必要なんですが、デザイナが30人からいると
常時コミットするときにコミュニケーション取れっていうのも現実的でないかと。
できるだけ問題が起こらないようにツールで解決したいのです。

やはりgit等の分散型が選択できないとすると、subversionのパフォーマンスで納得できないとなると
perforceなどの製品を使用するのが現実的な選択になるんでしょうか？
0946デフォルトの名無しさん2010/09/01(水) 00:18:39
会社の方針とかもあるので一概には言えないというのを前提で。

ある程度の規模のオープンソースプロジェクトが試行錯誤の末に導いた結論は
責任あるコミッターを立てるということ。
パッチやブランチの形で提出される更新を、コミッターがマージや取捨選択して
中央のプランチに収める。ツールに頼っていては上手く行かない。

コミュニケーションが必要なのはコミットする時点ではなくて、変更する前。
コミッターが的確に指示できるか、あるいは各開発者の意見集約ができるか。
大枠さえ、ちゃんとしてれば何時コミットするかは問題では無い。
0947デフォルトの名無しさん2010/09/01(水) 00:22:03
ここは納期も関係ないし、バージョン管理上も実質2,3人しかコンフリクト起こしえないし
プロジェクトに関係するバイナリといえばアイコン画像程度な人らしか居ないよ。

有償製品を使った事がまず無いし、返ってくる答えは下らん理想論かVSS(笑)とかそのレベル。
0948デフォルトの名無しさん2010/09/01(水) 01:24:45
ここはム板なんだから製品は板違いじゃない？
0949デフォルトの名無しさん2010/09/01(水) 02:10:18
まったく同じ目的のものなのに
オープンソースは良くてプロプラは語っちゃ駄目な理由についてｋｗｓｋ
0950デフォルトの名無しさん2010/09/01(水) 07:48:21
>>945
30人は無理かもしれないが、5×6人とかは無理？
分散型の利点は中央リポジトリも分散・階層化できることだと思うが。
0951デフォルトの名無しさん2010/09/01(水) 07:55:39
お話になりませんな
現場を知らなさすぎ
0952デフォルトの名無しさん2010/09/01(水) 08:19:15
現場なんか千差万別。
モジュール化もしていない現場なんかしらない。
0953デフォルトの名無しさん2010/09/01(水) 08:36:14
まあなあ
ドキュメントですら、30人もが編集するようなファイルってないと思うんだがな
そんな現場は知らないでもいいや
0954デフォルトの名無しさん2010/09/01(水) 08:39:44
ドキュメントもモジュール化していることを知らないということが分かった。
多分ドキュメントはワード・エクセルしかないと思っているのだろう。
LaTexとかいくらでもあるのに。
0955デフォルトの名無しさん2010/09/01(水) 08:47:01
>>945
なぜロックしたいかと言うと、各自が平行して編集してしまった場合に
それぞれの作業内容がマージ出来ないようなファイルフォーマットだから
だと思うんだけど、そうやって同時編集が出来なくて作業が滞るよりは
ファイルをもっと細かく分割するか、分割出来ないのであればメンテナ担当を
決めて取りまとめしてもらうようにしたほうが効率が良いんじゃないかな。

分散型のVCSにロックを求めるのは無理だと思うので、排他制御は別途
プロジェクト管理ソフト（TracとかRedmineとか）でやるのが良いと思う。
0956デフォルトの名無しさん2010/09/01(水) 09:49:30
ビジネスで、まともに運営されてて、ある程度規模が大きいプロジェクトであれば、
意思決定がトップダウンでやれるのと、
リポジトリ管理に加えて、変更要件の管理とかを合わせて構成管理として
それらを担任する専任の担当なり部署なりを用意する事が普通は認められるから、
そんなに大変ではないよな。

例えば、
あるベースラインがあって、それに対する要望やバグ報告に由来する変更要件の山があるとして、
それらに対して次のリリースまでに対応するものを決めて、個々の変更要件に対して
変更する必要のあるリソースを見積もらせて、
それを元に同じリソースを更新する変更要件は同じ担当者・チームにやらせたり、
優先度の低い変更要件を次のリリースに先送ったり、とかの交通整理がなされるから、
そもそリソース更新のコンフリクト自体がそんなに起きないしな。
0957デフォルトの名無しさん2010/09/01(水) 10:49:24
ゲーム開発会社かはたまた3D CG制作会社かー
30人とかそんな人数で開発やったことないｗ お前らすげえな

OSSの開発だと、 >>946 みたいに責任者用意してんじゃなかったか

入門Gitのグループでの開発例で、

UIチームメンバA +-+-UIチームの共有リポジトリ --UIチームリーダー作業リポ(ry--全体の共有(ry
UIチームメンバB / /
UIチームメンバC __/

というのが少し紹介されてた。
gitでお互いをpush, pullしあう体制で
UIチームメンバがUIチームの共有リポジトリからcloneして作業した結果をpushしてく
メンバーは全体の共有リポジトリには直接上げられなくて、
UIのチームリーダーがUIチーム共有リポジトリをチェックして問題ないなら、全体のリポジトリにうｐする形式

Linux kernelの開発体制もどこかに書いてあったような気がするが忘れた

どっちにしろデザイナがいるチームでgitやhgは論外で分散バージョン管理はまだ早い気がする
bzrもTortoiseSVN使っている人間には使いにくだろう
0958デフォルトの名無しさん2010/09/01(水) 10:49:45
>>948
なんか頭悪い＆固い意見だな。
ムの品質に関わる製品もあるわけだ。
線引きは少々難しいが、板違いと言い切ってしまうのもどうかと思うぞ。
0959デフォルトの名無しさん2010/09/01(水) 10:54:22
>>955
まあロックとまではいかなくとも、今誰が編集中か確認できるぐらいの
機能は欲しいとは思う。cvs の watch だかみたいな。分散では難しいかな。
0960デフォルトの名無しさん2010/09/03(金) 13:53:32
>>957
つ TortoiseBzr
0961デフォルトの名無しさん2010/09/03(金) 14:08:19
>>960
いや、TortoiseSVNと比較してるんだけど
0962デフォルトの名無しさん2010/09/03(金) 14:32:47
subversionのリポジトリだけ貸してくれるレンタルサーバってないの？
サイトのHTMLデータとか外部の会社と共同作業するとき用に。
かといって、わざわざレンサバにsubversionインストールするのもめんどいし。
0963デフォルトの名無しさん2010/09/03(金) 14:38:38
>>962
リポジトリだけなら探せばいくらでもありますよ。
0964デフォルトの名無しさん2010/09/03(金) 14:46:36
>>962
「Subversion ホスティング」でぐぐれば望みの情報が出てくるでしょう
0965デフォルトの名無しさん2010/09/03(金) 20:57:28
>>954
ワードとかエクセルもモジュール化出来ること知らないのか。

というかLaTeX言いたいだけだろ。
仕事であんなの使えねえよ。
0966デフォルトの名無しさん2010/09/03(金) 21:46:32
LaTeXをおもちゃ呼ばわりする人がいると聞いて
0967デフォルトの名無しさん2010/09/03(金) 23:14:58
仕事で設計書とコードの同期が問題になったときにliterate programmingで行くぜ！
ってなったときにlatexはドキュメントフォーマット用ツールとして使った.l
Windowsの世界だけで飯を食ってるとなんだそれ？って感じになるのもわかるけど。
0968デフォルトの名無しさん2010/09/03(金) 23:22:21
>>965
> ワードとかエクセルもモジュール化出来ること知らないのか。
詳しく
0969デフォルトの名無しさん2010/09/03(金) 23:29:21
textile, markdown
0970デフォルトの名無しさん2010/09/04(土) 00:01:53
>>947
> プロジェクトに関係するバイナリといえばアイコン画像程度な人らしか居ないよ。
SVG
0971デフォルトの名無しさん2010/09/04(土) 05:28:58
ウチは数十メガのでかい日本語フォントファイルをcvsに突っ込んでるな。。。
hgで登録しようとしたら、デカすぎて無理と怒られた
0972デフォルトの名無しさん2010/09/04(土) 07:23:18
>>971
> ウチは数十メガのでかい日本語フォントファイルをcvsに突っ込んでるな。。。
> hgで登録しようとしたら、デカすぎて無理と怒られた
http://mercurial.selenic.com/wiki/BfilesExtension
0973デフォルトの名無しさん2010/09/05(日) 22:45:00
何社かで共同で開発する場合は
(技術的な)最大公約数的を取ってLaTeXの採用は見送られそう。

つーかドキュメントなんざ履歴付きのWikiでよくね？
0974デフォルトの名無しさん2010/09/05(日) 23:49:57
管理番号なくね？
0975デフォルトの名無しさん2010/09/06(月) 03:33:42
LaTeXとか言ってるのは学生だろ
こういう輩が得意げに語るのが、たちが悪い
0976デフォルトの名無しさん2010/09/06(月) 06:48:42
こういう、自分が社会人ってことだけが心の支えの奴って、たちが悪い
0977デフォルトの名無しさん2010/09/06(月) 06:59:28
m9
0978デフォルトの名無しさん2010/09/06(月) 07:16:59
>>974
チケット番号
0979デフォルトの名無しさん2010/09/06(月) 07:38:35
>>976
× こういう、自分が社会人ってことだけが心の支え
○ こういう、自分がドカタってことだけが心の支え
0980デフォルトの名無しさん2010/09/06(月) 07:53:25
バージョン管理システムで人間が見て意味のある差分を取れるような
ドキュメント書きツールという意味ではMS-WordやらOOoは失格なんだが、
一応「バカでも使える」ってことになってるツールを選ぶとなると……
0981デフォルトの名無しさん2010/09/06(月) 07:56:57
htmlでええやん
0982デフォルトの名無しさん2010/09/06(月) 07:58:11
>>980
MS-Wordはツールを使えば差分を取れるらしいし、OOoはzipを固めたものだし。
0983デフォルトの名無しさん2010/09/06(月) 07:59:17
>>981
つ>>969
0984デフォルトの名無しさん2010/09/06(月) 09:13:08
TeXの難易度はちゃんとしたHTML並だと思うけど、
MarkdownなりTextileなりの方が文章を構造化するのには適していると思う
TeXはなんだかんだいってレイアウト指定言語
0985デフォルトの名無しさん2010/09/06(月) 09:44:47
>>980
最近のMSWordはxmlで保存すればテキストで差分取れる
0986デフォルトの名無しさん2010/09/06(月) 10:01:01
>>985
差分は取れてもマージはほぼ不可能
0987デフォルトの名無しさん2010/09/06(月) 10:18:42
>>986
それはwordのせいなのか？xmlのせいなのか？明日はなのか？
0988デフォルトの名無しさん2010/09/06(月) 10:29:20
ワードとかのxmlは構造化してるわけじゃなくて、単に保存形式をxmlにして
誤摩化してるだけだからなぁ。
人にとって意味の分かる差分じゃないと、マージは難しい。
0989デフォルトの名無しさん2010/09/06(月) 21:18:49
いずれにしてもLaTeXはないわな
ガキは巣に帰れ
0990デフォルトの名無しさん2010/09/06(月) 21:30:36
たかが文章ごときにコンパイルとか笑わせるよな
0991デフォルトの名無しさん2010/09/06(月) 22:31:27
TeXの難易度は、記述よりも参照の環境構築にあるだろ。特にWindowsで。
HTMLと同じくらい簡単に書けたって、同じくらい簡単に見れなきゃ本末転倒。

PDFなんて手で書ける奴は極少だろうが、読むのは環境のインストール含めて誰でもできる。
0992デフォルトの名無しさん2010/09/06(月) 22:37:32
>>989
XeTeXとかLuaTeXならいい？
0993858=8792010/09/06(月) 22:44:27
せっかく色々レス頂いていたのに忙しくて放置してました。
レス返し&質問するとスレ終わっちゃいそうなので次スレ立ててみます
0994858=8792010/09/06(月) 22:52:38
立てました

バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
0995デフォルトの名無しさん2010/09/06(月) 23:10:51
なんか、余計な本スレ認定とか、勘弁
0996デフォルトの名無しさん2010/09/06(月) 23:26:31
とりあえず即死で落とすか
0997858=8792010/09/07(火) 00:04:19
>>995
まったくそんなつもりはなかったんですが・・・
そもそもどれが本スレとか殆ど行ったことないから知らないし、
わざわざ内容をしらべて、どれが本スレとか判断するような面倒なことはしません。

>>996
なるほど、その手がありましたね。
ではそういうことで・・・

0998デフォルトの名無しさん2010/09/07(火) 00:30:43
訂正入れてるんだし、このままでいいんじゃん？
0999デフォルトの名無しさん2010/09/07(火) 07:51:21
999
1000デフォルトの名無しさん2010/09/07(火) 07:52:07
1000なら今日はいい一日
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。