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

●関連スレ
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/

●関連サイト
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

ごめん、前スレで告知するの忘れてた。

前スレからの続きだけど、タグやブランチの扱いに関しては Subversion はかなり異端だと思う。
「機能がないから運用で回避」みたいな。

>>4
内部実装はあれでもいいんだけど、ユーザに見せるなやって思うわ

スレ立て乙

>>4
ディレクトリがあればタグやブランチはいらないと言うのがsubversionの考え方

面白いな。
リーナスに罵倒されるぐらい CVS を踏襲しようとしてるのに、
妙なところで独自性を出してるという。

ClearCaseの使い勝手ってどんな感じ？

>>9
クソってのが定説だな

>>5
ユーザが自由に運用しておくれ、という意味だと思ってた。
その割には、ベストプラクティス系のドキュメントを見たことがないが。

>>7
バージョン管理システムがなければ
フォルダを作ってこそにコピーすることになると思うけど
それと全く同じイメージで使えることを目指したんだろうね

>>8
それが svn コミュニティのあほなところ。
svn はすっ飛ばして正解だった。

>>13
一度は触っとけよ
Tortoiseの使い勝手だけは間違いなく一級品だぞ
プログラマ以外にバージョン管理を使ってもらうには未だSVNが最高でデファクト

最高でデファクトかどうかは兎も角、Tortoiseとかウェブクライアントはよくできているみたいね。
CVSからsvnに引き継いだプロジェクトは事実上死滅したし、
svnでスタートしたプロジェクトは全てbzrに引き継いだから私のところでは最早使ってないけど。

>>15
？？
RubyはCVS→SVNだけど？

15は突然自分語りを始めただけじゃねぇの

>>16
その2行目は、3行目の「私のところ」の話だろう。

いつになったらまともに日本語ファイル名を扱えるgitクライアントが出てくるんだよ。
cygwinとかいうのは無しで。

>>19
gitユーザのありがたい仰せによると、
1. Windowsダっせぇ
2. んなもんどうせバイナリファイルだろ？svn使っとけやゴルァ
等々とても前向きなので、来世紀までには改善されるでしょ。

これだからgitユーザーはクッセェんだ

>>19
UTF-8なら問題ないよ。
Windowsとかいうのは無しで。

一つの言語に対するエンコーディングが複数存在することを理解させる
複数のエンコーディングを排して統一するものとしてUNICODEでは不十分なことを理解させる

UNICODEが不十分だから他のエンコーディングを相互変換するのが気持ち悪いんじゃないの？

ファイル名にカッコ株とか携帯絵文字でもはいってんのか？

別に完璧なんか求めてなくて、svnでできる程度できれば問題ないんじゃないの？

カッコ株はunicodeにあるだろ
携帯絵文字もそのうち入るし

gitはUnicodeとか何も考えてないよ。パス名はバイト列として扱ってるだけだから。
でもWindowsのANSI APIは、パス名をローカライズされた文字列(日本ならcp932)とみなしてUnicodeに変換しちゃうから、
gitのやり方だとAscii文字列以外がおかしくなる。

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

よく知らないけどCygwin1.7はちゃんとこういう変換をやってるのかな。

Unicodeとか何も考えてないのに、Unicodeに変換しちゃうの？

この読解力の無さはすごい

変換しちゃう、のは win32 API が、じゃないの？

よくわからん。
gitが取得したパス名ってCP932と見なせるバイト列じゃないの？
WindowsのANSI APIが渡されたバイト列をCP932として評価するなら化けないと思うんだけど。

>>28
この考え方のせいでgit（とhg）はクズなんだけど、
DVCSでは一番（と二番）使われてるから今更変更きかないんだろうな。
まったく残念だ。

俺Unicodeライブラリなんか使わないけど、一度もファイル名が化けたことなんてないよ

>>32
それはそうだな
「Unicodeに変換しちゃう」のなら、gitのレポジトリにはUnicodeで送るようなイメージを受ける
>>28が詳しいなら、もうちょっと補足して欲しい

UTF-8なら日本語だろうがどうということはないのだがな・・・

>>36
だから、WindowsのクライアントがUTF-8なりなんなりでgitレポジトリに
アクセスすれば済むって話だろ？なんでそんなこともできないんだろう。
Windowsクライアントの開発者はやる気ないの？

1時間くらいソース見て、ちゃちゃっとパッチ書けるならいいんだが、
だとしたらきっともう誰かがやってるはずだから、そうはいかないん
だろうなぁ。

>>37
え？gitはUnicodeのことなんて考えてないのに、リポジトリにはUnicodeで保存するの？

Windowsクライアントってgit.exeのこと？

>>32
ごめん考察足りてないな。
確かに日本語Windowsだけで使うなら、CP932のまま扱っても問題ないはずだけど、
実際上手く扱えないのは例によって\が含まれる文字の場合じゃないかと。

>>35
gitのリポジトリに保存されてるファイル名はバイト列がそのまま保存されてる。
変換するのは、リポジトリからファイル名を取り出して、APIに渡した後の話。

>>40
msysgitとやらいうやつのことじゃね？

まぁ理由は何であれ、事実上のデファクトスタンダードであるmsysgitで正しくフィル名を
扱えるようにならないと駄目だな。

>>41
> 実際上手く扱えないのは例によって\が含まれる文字の場合じゃないかと。

実際使ってみればわかるけど、どんな日本語ファイル名でも、ファイル名全体が化けるよ。

>>33
別に今からでも、Windowsの場合だけは、
パス名の内部表現をUTF-8の文字列にして、APIに渡す前にUTF-16に変換する
って動作をするように変えてくれれば、困る人はいないんじゃないかなぁ。

>>39
>>37は>>36へのレスで、UTF-8なら問題ないってのをまともに受けて書いたレス
その疑問は>>36へどうぞ

ということは、msysgitがファイル名をUnicode(UTF-8?)でリポジトリに登録して、
持ってくるときはそれをcp932と見なして変換しちゃうということか。
どうやったらそんなタコなことできるんだよｗ

>>47
おれぁファイル名のエンコードなんぞ知ったこっちゃねぇんだよ、
とかいってansi版のWinAPIにそのままバイト列突っ込んじまえば、そうなる。

>>47
いやリポジトリにはあくまでバイト列としてしか登録されないからそんなことはしてないよ
ちょっと>>28は忘れてくれ…。
APIのUnicode変換と文字化けを関連付けたのはおかしかった。

>>48
Unicodeライブラリを使わない場合、コマンドライン引数もファイル名取得もCP932なわけだが。

ちょっと待て。
msysgitでファイルを登録して、msysgitでファイルを取得しても化けるということなのか？
それともUTF-8を使ってるUnix/Linuxで登録したものを取得したら化けるのか？

>>50
リポジトリはUTF-8って前提だから化けるわけだよね。

あとログも化けるｗ

じゃ、Windowsに閉じたグループがmsysgit使うなら何の問題もないじゃん。

>>54
>>51の後者だとは思うが、その上で、TortoiseGitでは0x5C混じりのファイル名で
コミット出来ないって問題があって、それはmsysgitをそのまま使ってるから云々って
問題があったような希ガス

今は直ってるのかも知れないけど、結局は同根の問題だと思う

A系決めうちで使ってるコード全体をW系も使うようにするのは非常に手間だから誰もやってないと思う。

やっとすっきりした。みんなサンクス。

なんか適当な考察のせいで無駄にログ伸ばしたようで申し訳ない。
結局APIうんぬん以前にmsys側の問題が大きそうだね。

誰か結論がどうなってんのかまとめてくれ

>>59
・Windowsダサい
・gitで日本語ファイル名使う男の人って…
・結局cygwinってよくできてるよね

の三本立てでお送りしました

結論：
・ファイル名がUTF-8で保存されているファイルはmsysgitを使うと化ける（いわゆる”日本語ファイル名”のみ）
・msysgitを使ってcp932のファイル名を保存する場合は\問題がある
・UTF-8でログを保存している場合は、mysgitでは化ける
・UTF-8版Cygwinでgitを使えば問題ない

なんで日本語WindowsでUTF-8をデフォルトのコードページとして使えないの？
なんかそれだけで済む気がするんだけど、結局そういうOSじゃないってこと？
スレ違いかとは思うけど…

>>60
そういうのは結論とはいわない。

>>61
ありがとう。よくわかった。

>>62
カーネル内はUnicode化されてるんだけど、FAT32がcp932でファイル名を保存する関係で
ごちゃごちゃしてるんだと推察

つか、日本語で名前付けるようなファイルって、結局は仕事で使うようなオフィス系のファイルだったり
デザイナーが使うリソースファイルだったりでしょ？
それらはどうせマージ出来ないんだから、gitとか使う意味ないし、そっちだけsvnなりでやってればいい。

>>65
「>>20まで戻る」

なんだこの不毛なスレ進行ｗ

さくらインターネットでgit入れてTortoiseGitでcloneとか
しようとしてるんだけどTortoisePlink passwordってダイアログが出て
パスワードを毎回入れるハメになるけど回避方法無いですか？

まぁgitは一生マルチプラットホーム足り得ない田舎アプリってことでしょ
どうでもいい

経緯の上でも、Linuxカーネル開発に使えれば十分なわけで。

>>67
sshの公開鍵を作ればいい。
TortoiseSVNのほうが情報充実してるから、
TortoiseSVN ssh 公開鍵 あたりのキーワードでぐぐる。

>>68
Windowsがサポートされればマルチプラットホームなのか？
どうしてだかドザって除け者にされると激しい反応を示すよな。。。。

>>70
サンクス。sshの公開鍵ね
ぐぐって試してみるわ〜

>>71
なんだこの馬鹿は
なぜ突然「Windowsがサポートされればマルチプラットホーム」とか言い出すんだ？
マルチプラットフォームの意味知らんのか？
そんなの成り立つわけが無いだろ

いや、まあ、あれだ

Windows入れてもすでにほぼマルチプラットフォームなんだ、gitは
ただ、マルチバイト文字圏ってのはなんだかんだ自助努力が必要なんだ結局
そこのところ、開発者かユーザかどっちがひっかぶるかってだけの話なんだと思うんだ
今世紀も半ばくらいには、多分解消してるよ。主にWindowsの変化によって（笑）

>>73
は？　Windowsでgitのファイル名が化けるだとかって、昨日からずーっとグダグダやってんじゃん。
Windowsでうまく動かないから田舎アプリだとか、痛いレスしちゃって。

一部を除いては、も少し建設的な情報交換もできたと思うので、そのまとめはどうかと

Windows？そんなの知るかよ！って奴等が集まってるようには、見えるなｗ
http://repo.or.cz/w/git.git

no-windows wwwww

>>77
当たり前だけどJunio C Hamano氏の活動量すげぇ

世界の70%を占めてるOSにまともに対応せずにマルチプラットホームとか(笑)
ごく簡単に対応できる問題にも対応できずに高スキル集団気取ってんなよgit共がｗｗ

>>70
できた。puttygenで生成したテキストをauthorized_keysというファイル名で
保存しサーバーの$HOME/.sshのフォルダにアップロードするという事が
分からず時間掛かったけど。
あとはpageantを常駐してadd keyさせたらパス入力聞いてこなくなった。

確かに変なのが居着いてるな
Windowsで普通にgit使いたい奴にとって非常に迷惑な奴が

>>80
WindowsならSVNを使えばいいんじゃないですかね？
無理してgit使ってWindowsの欠点に文句言うのも不毛だよね

Windowsの文字コードをUTF8にしたいんだけどどうやるの？

文字列をバイト列と考えるgit側の致命的欠陥だろ
どこの誰がパスをバイト列で指定するんだよ
根本から間違ってる

リナ糞圏のマルチバイトの弱さは特筆に価する。

>>80
世界の70%を占めてるOSの世界の70%を占めてるユーザーで問題が無いことが問題なんだな。
(細かい数字は適当だから気にするな)

>>85
だったらwinユーザーはgit使わずsvn使えば問題ない

べつにWindowsユーザーに使ってもらうために作ってるわけでもないだろうし。

>>88
なら田舎アプリと言われたからってウダウダ口出しすんな

LinuxのlocaleをEUC-JPにするとかShift-JISにするとかすれば同じ問題が起きる
Windowsのlocaleを英語にすれば(ほぼ)問題が解決する
それが問題なのか問題では無いのかの違い

というかWindowsだと問題が多発するgitをわざわざ使う必要なし
Windowsならsvn使うのが超安定

>>90
そんなにくやしいなら自分でWindows用のgit作れ
オープンソースなんだからさ

そろそろ、日本語使うなら Bazaar 使おうぜ！ って言ってもいい？

gitとかそろそろ滅びろよ

svn使ってれば？

>>94
【bzr】Bazaarでバージョン管理 Rev 2
http://pc12.2ch.net/test/read.cgi/tech/1265951333/

Bazaarって知らなかったけど面白そうだな

cygwin の git で LANG=ja_JP.utf-8 で使うというのが
現状では一番なのではないのか?
どうしてもmsysgitを使いたいっていうのならパッチ当てるしか...

まっ良く知らない奴がWindowsでgit使うと痛い目見るって事だな

ここ見た奴は周りがWinでgit使いたいって言ったら全力で引き止めろよ

いつもこの過剰な流れを見るたびに日本語ファイル名を使わなきゃ良いだけだろと思うんだけど...
ログはlogoutputencodingとcommitencodingを設定すれば問題ないし。

まあ、その辺りは、置かれてる立場によって変わってくるだろ。
一人だけでやってるならなんとでもなるが。

gitのコミッタはいい加減ガキ臭すぎると思うわ
簡単に解決できる問題をwindows憎しと言う感情のみで放置
チョン国人と同レベル過ぎる

他人の感情がわかるとか凄いエスパーだな

>>77 見ればただの野次馬な俺でも分かるってばよ・・・

>>102
君みたいな人はSubversion使うのが合ってると思うよ
Windowsの文字コードの欠点はどうしようも無いからね

あれ、svnでは解決してるんだろ？
どうしようも無いことなの？

>>106
Linuxカーネル開発する上で困ることがないのでスルー。

他の殆どのマルチプラットホームを謳うアプリで文字コードの問題を解決しているのに
git界隈ではどうしようもないと言われている
つまりはそういう事だ

まぁ、現実問題対応していないと言う事は、gitはコミュニティレベルで劣っていると言う事の証左だよね。

盛り上がっているのでmsysgitのソースコード見てみた。fopenとか使っている
んだな。gdi++.dllみたいにフックしてUTF-8変換すれば良いんじゃない?

まあMercurialで問題ないわけだしね

あるわ

Hg、なんか中途半端なんだよな
いろんな意味で

そうなのか?

金属光沢だから、固体かと思ったら液体だった、みたいな？

文字化けと言う失笑物の欠陥を直せないでいるgitよりはマシだけどね。

自分が失笑されてることにも気づけないのか

>>117
gitは検索タグがno-windowsってくらいだから、気づけないっていうか見ざる聞かざるだね

プラットフォーム間で文字化けすると言う、普通に考えて恥ずかしいレベルの初歩的欠陥も

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

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

あらゆる原動力がwindows憎し、svn憎しから始まってるから、これで妥当なんだろうけどな

根暗が負の感情を原動力にした時に発揮する力は半端無いからな

別に憎いとかじゃなくて、彼らからみれば普通に馴染みのないOSだから。
そうやってギャーギャー言われると、こっち見んなってのはあるだろうけど。

馴染みが無いと来たかｗ
それで居て田舎と言われると怒り出すｗｗ

相手してもらえないからってファビョりすぎ。自称「都会」のWindowsで遊んでなさいよ。

と、こんな時間に律儀に相手をしてる奴が何か言ってます。

>>111
Mercurialも同じ問題抱えてた気が……

Mercurialはmsys依存してるわけじゃないから、まだ何とかする余地がありそうなんだけど。

Windows だけじゃなくて Mac に持ってっても問題出るよなぁ

LANG=ja_JP.EUC-JPとかでもダメ。
要するに、汎用性は目標じゃないので、
多言語化はしたくない、ってことだろ。

現実を見据えた完全性を目標にしてる
感じのsvnやbzrとはもはや比較できない。

もともとはLinus Torvaldsのオレ専用バージョン管理システムなんだから、
「Windowsで使えねー」とか言っても「Windowsを使うな」ってなるのは
ある意味当然

しかもLinusは特段優れたソフトウェアアーキテクトでもないしｗ

誤解が無いように言っておくとWindowsで問題があるわけじゃない
変にローカライズされた一部のWindowsで問題がある
その中に日本語版Windowsが含まれるということ

その「一部」の分母が数千万以上ってだけなんですけどね。

それ以上に英語圏の分母が大きければ取るに足らんと思われても仕方ない

その「一部」って世界のLinuxの稼動数超えてるよねｗ

微妙な言い方だな。
Windows と Linux の「稼動数」の差って「ユーザ数」の差より小さいんじゃね？

問題はOS自体の稼働数じゃなくてその上でのgitの稼働数だとおも。

え？gitをまともに使えない現状でのgit稼動数を問題にするの？ｗ
そりゃ一生解決しませんわｗ

svnみたいに高品質ならwindowsでも使われまくるよ

次にお前は　だったらwinユーザーはgit使わずsvn使えば問題ない　と言う

なんかgitのこと叩いてるWindowsユーザって、ふだん高飛車でちやほやされてるご令嬢が
転校生の主人公に無視されて「わたくしを誰だと思っているの！？」って怒ってるみたいでちょっと萌えるｗ

>>139
いや、別にGitを使わなくてすむならそれでいいんだけど、
開発者のあいだでGitが人気なのはもはや止めようがなく、
好き嫌いに関わらず、使わなきゃいけない場面というのは
どうしても出てくるわけよ。
そして、Windowsで使おうとすると問題がでて困る、という話。
自分にすべて決定権があるならGit使わないという決定が
できるけど、そうじゃない人もいるよね。残念ながら。

うそーん。
git使ってる人達は問題のない使い方してるはずだから、
Windowsで使うと問題が起こるなんてことはないんだよー。

>>141
× 問題のない使い方
○ 問題に近寄らない使い方

>>125
Mercurialはダメ文字は大丈夫。でもファイル名がバイナリ列なのはgitと同じ。

あー、ダメ文字って0x5c入りの奴もそう呼ぶんだ。
マッピングできない奴だけを言うのかと思ってた。

Git使いの>>139は物語の主人公らしいｗ
流石ですｗ

>>144
個人的には、5Chが入ってる文字＝ダメ文字、で使ってきたから
マッピングできない文字をダメ文字と呼ぶ方が新鮮だったり。

>>143
fixutf8

バージョン管理システムも用途によって分化していくのかな。

>>147
Hgスレだとfixutf8でもだめっぽいけど

まぁgitもMercurialもLinux kernelの管理用に作られたわけだしな

というかそういうWindowsでしか発生しない問題なんかは
TortoiseXXXとかのGUIがなんとかすればいいだけじゃないか？
どうせWindowsでコマンドラインから使ってる奴なんて
ほとんどいないでしょ
もしコマンドラインからやりたいならCygwin使えばいいだけだし

>>151
MergurialやGitの問題です

>>149
fixutf8でファイル名の問題は解決する

>>151
無知と偏見の塊なのを自覚して黙ってた方が良いよ

最近、仕事先でgitを使ってる。
一つ不満なのが、git status やらで出てくるメッセージが英語なんだが、
これって日本語メッセージにできないの？linuxのCUIでの話。
警告とか普通に読み飛ばしてしまってなんだかなー

export LANG=ja_JP.utf-8 とかはやってみた。だめだった。
なんかパッチとか必要なのかな

>>155
ソースコードをgettext化する必要があるだろうね。
gitの配布物の中にある git gui はこれを使ってそこそこ国際化済み。

>>156
CUIはまだ国際化されてないのね
thx

WindowsはさっさとUTF8化しる！
いつまでSJISなんだよ古くさー

えっ

マジで言ってるの？

3.1の話かとｗ

158じゃないけど、エクスプローラとか
コマンドラインとかのフロントエンドは
もうUTF-8にしないのかなーとは思う。

コマンドプロンプト自体は一応UTF-8対応してるぞ

Windowsの標準アプリはほぼUnicode対応になってるはず。
CP932に依存するのってコマンドプロンプトくらいじゃないか？

標準じゃないやつだと未だにAnsi API使ってるのがいっぱいあるけどな。

cmd.exe のコードページを utf-8 にするには
chcp 65001
としたらよいのだが、今度は日本語フォントが。

>>164
甘いよ。大甘。

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

なのでOSのロケールをUTF8にしてもまともに表示できるアプリはほとんどない。

>>166
？？？

ここまで意味不明な文章もなかなかないな

なんだ、ム板だからわかるかと思ったが、このスレの住人にはわからんのか。

いや、悪かったな。意味不明な文章書いて。忘れてくれ。

これはひどい。

explorer.exeなりをバイナリエディタで開いてみれば、リソースがUnicodeで入ってることくらいすぐわかるんだが…。
（ただしVista以降ではリソースDLLに分離されてる）

notepad.exe の保存ダイアログでは文字コードの指定ができ、utf-8 もある。
メモ帳で utf-8 を表示できるだろうということは標準コントロールで表示できることを示唆している。

>>172
それはファイルの読み書きするときに変換かけてるだけだ。
EditコントロールはUTF-16でしか動かないぞ。

そもそも>>162のexplorerがUTF-8に対応するってどういう意味かわからん
NTFSがUTF-8化するってこと？

文字コード気にするやつはWindowsでgitを使うな
超安定のSubversionを使ってればいいんだよ
Windowsはもう諦めろ。無理してgit導入しても周りの迷惑にしかならん

VisualStudioのリソースエディタでUnicodeが扱えないだけ

はぁ？

ファイル名に日本語使うバカは常識的に居ないからgit使っても問題なし

はぁ？

ホームフォルダが日本語名になっちゃってる人はよく見かける

フォルダ()笑て何ですか?

>>181
Windowsで使うな！と言いたいんだな?

これだからWindowsユーザーは…
Subversionしか勧められないわけだ

Windowsは今のunicodeの実装自体にはそれほど問題無い。Macよりは。
ただ過去の無理矢理localizeの後遺症がデカい。

今時どのOSだってフォルダと言う

フォルダとディレクトリは必ずしも一致しないな

Windowsとかどうでもいいので開発陣には他のことに力を注いでもらいたい

果たしてwinだけの問題であろうか。
ファイル名を単なるバイト列としか扱ってないことを続けて良いのか。

Linux含めてUnixのfilesystemはバイト列で扱ってるからな。
WindowsはfilesystemはUnicodeとして扱う。

MicrosoftがCanonical(Ubuntuの開発元)の運営するLaunchpadを使い始めた件。
https://launchpad.net/coapp
https://launchpad.net/~garretts
おまけ
https://bugs.launchpad.net/bugs/1

＞Unixのfilesystemはバイト列で扱ってる
じゃあどうしようもないな

>>190
MSの歩み寄りに今だに感情的に反発してる馬鹿共は何なの
どこまでガキなの

>>189
そういう現状に即さない田舎OSは勘弁して欲しいな。
ファイル名がバイト列で良いならテキストファイルもバイト列として扱えるはずって事になる。
これがどれだけ無知で間抜けで短絡的かは言うまでもない。

Windowsとかパソコンに弱い初心者向けだからgitとかは対応しなくていいよ
それにWinならSubversionがあるしな

× 言うまでもない
○ 俺はバカだから説明できないが絶対正しいに決まってる

>>195
それは流石に苦しいぞｗ

gitのマルチバイト問題はUTF-8 cygwinでイケル！かと思いきや、
git-guiやgitkが文字化けしたり、文字化けしたのはファイル指定でエラーおこしたり散々ｗ
コマンドラインで使う分には問題ないんだがなあ。


githubもマルチバイトファイル名のファイルつっこむとファイルリストからクリックして見られなかったり、
たまにサーバーエラー起こすしｗ
githubにはエラーでたページからレポートしてるんだけどなかなか直してくれない。
github自身のissue トラッカーってないの？

winユーザーがgit使えなくて嫉妬するスレになってるな
問題沢山あるからgit使うのはやめとけ

文字コードにまともに対応できない無能集団が>>194見たいな事言っちゃってる姿がウザいんだよ

まあ全世界から見たら「日本語の」「windows」なんて
田舎環境を使っている方が悪いんだよ

果たしてwinだけの問題であろうか。
ファイル名を単なるバイト列としか扱ってないことを続けて良いのか。

>>201
それは、そもそも、このスレで取り上げる主旨じゃない→スレ違い。

>>200
「日本語の」だと？
馬鹿も大概にしろ

>>200
馬鹿現るｗ

英語以外はみんな問題あるだろ。
でも変換なしにがしがし書ける英語っていいよな。

問題はおまいらだ

winでgit使いたいなら使えばいいんだよ
ただ日本語のファイル名付けるバカで低脳な奴はSubversionにしとけ
日本語名付けるやつほど迷惑な奴もいないよな

日本語ファイル名が馬鹿で低脳かは、TPOによるだろ。
米国人主体でプログラム開発してるなら、日本語ファイル名なんて論外だろうけど、
日本人主体のプロジェクトで、プログラマ以外のスタッフの方が多い
ゲームとか書籍製作で使うなら、日本語ファイル名禁止なんていうほうが論外だし。
そういうこと考えずに自分の狭い視野だけで低脳と決め付けるほうが低脳。

別に日本語のファイル名つけても問題ないけど…
ただWindowsでおかしいだけでしょ？

いい加減うざいんだが

正直ドキュメントは、怪しい英語より日本語ファイル名を的確につけて欲しい
そんなものをgitに放り込むなってのは正しいんだろうが、gitとsvnの両用ってのも無駄に感じる
要はそんなとこだろ
なんでそんなにマルチバイト対応が後回しになるんだろってのは気になるな

そりゃ単にファイル名を人間が読み取る文字列だと思ってないからでは。

ここ見てると、一般にユーザーにバージョン管理の機能を落とし込んだDropboxがまさに対照的でおもしろいな。
馬鹿でも使えてTortoiseSVNよりももっと簡単（機能は少ないけど）
サーバー自前で立てる必要もない(むしろLAN用に立てさせろてほしいが)
Python利用のクライアントだがWindowsでも日本語ファイル名もOK。

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

見た目はファイル共有の側面が強いが、開発者インタビューではバージョン管理をもっと手軽に
（多分このスレでは相手にしてないデザイナさんや事務職の人相手にも）ってのを売りだといってたよ。

DropboxとSubversionを比較するのが間違い

>>208
「日本語ファイル名禁止なんていうほうが論外」なんて言うのも低脳だな
日本語ファイル名を付ける可能性があるならgitなんて使わせないのが正解

問題が起こる可能性があるのを説明も出来ないのかお前は
説明したのに使う事になってるならそんな馬鹿な奴らほっとけ

>>215
馬鹿はお前
gitが直せば良いだけの話に何を言ってるんだ？

・〇〇という奴はバカで低脳
・〇〇なんて論外

そろそろ、釣られる奴は低脳くらいいってもいいころあい

結論出ない議論を繰り返すよりgitでfilepathをUnicodeに変換して保存するコードを書いた方が建設的だわな
本家で受け入れられなくてもforkすればいいだけだし

>>215
>日本語ファイル名を付ける可能性があるならgitなんて使わせないのが正解
いや、
>日本語ファイル名禁止なんていうほうが論外
は、ほぼそういう意味で書いたんだが。
なんか勘違いしてね？

バカに正常な読解力を期待するからこうなるのだ。

>>213
RCSならリポジトリも作らずにその場で今の状態を取っとけるじゃん
自分は今でもたまに使ってる

Windowsとかよく知らないし

Linuxとかよく知らないし

わかった。

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

に対して、

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

と

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

と

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

がいるのな。

Unicodeとかよく知らないし

日本語とかよく知らないし

>>224
× Q. git で日本語ファイル名が使えません。
○ Q. Windowsでgitを使うと日本語ファイル名が使えません。

× Q. git で日本語ファイル名が使えません。
× Q. Windowsでgitを使うと日本語ファイル名が使えません。
○ Q. Windows-Linux間でgitを使うと日本語ファイル名が化けます。

問題なのはwinでgitを使いたいと思ってる奴がこのスレに来てる事
win用じゃないんだから諦めてsvn使いなよ
gitに執着してるようだけど馬鹿みたいだよ？

>>229
>問題なのはwinでgitを使いたいと思ってる奴がこのスレに来てる事
え？何で問題なの？理由は？

自分も含めたグループに使わせたい場合とか考えないんだろうな。
自分のことしか考えてないか、一人でしか仕事してないか。

そもそも仕事したことが無いんだと思うよ

gitスレはLinux板にあるってのもなｗ

OSSに関わってたり、Windowsを開発機にしてUnix鯖のwebアプリ作ってたりするとそうもいかない。
今時「win用じゃないんだから」はナンセンスじゃないか？
まー、Unix鯖で動くアプリ作るときは結局仮想マシンつかうし、その上でgit動かす分には問題ないかｗ

なんのためにgitが生まれたか知らずに語っている奴が混じってないか?

つまりMercurialも同様ということだな

>>231
他人の事を考えるならgitなんか使うな
それこそSubversion使うだろ普通

どんな普通だよｗ

でもさー、日本語ファイル名使うようなファイルってWordとかExcelみたいな、
そのへんのバージョン管理システムのdiffサブコマンドじゃーどうにもならない
ファイルばっかりだし、それこそファイル名に日付でも付けた状態でそのまま
ファイルサーバに置いて管理して欲しいと思う……

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

あ、プログラムのファイル名に日本語使う人は死んでいいから。

マルチプラットフォームで日本語ファイル名も使うプロジェクト、
という前提での「普通」だろ？

そういうプロジェクトでgitを使ってはいけない理由って別にないよね。

結局、gitは日本語ファイル名がうまく扱えないという現実を
「不具合だから直すべき」ととらえる人と、
「そういう風になっているソフトでわざわざ想定外の使い方をしなきゃいいのに」
と思ってるひととでは永久に相容れないと思う。

>>239
>あ、プログラムのファイル名に日本語使う人は死んでいいから。
業務プログラムのテストケースとかだと普通にあるけどな。
"要件XXX-価格決定-特定得意先別値引率適用Test" みたいな。

＞結局、gitは日本語ファイル名がうまく扱えないという現実を
日本語Windowsでの話だろそれ。自分の環境を前提に何でも話通そうとするなよ。

>>224
× git が日本語ファイル名に対応しろ派
○ git を日本語ファイル名に対応させろ派

つまり、要約すると、早い話が、gitは国際化対応できないって事で、FA?

日本語をgitに対応させろ派も旗揚げ

だからgitは世界のシェアの2%のLinuxの、そのまた更にシングルバイト圏でしか使う事ができない田舎アプリなんだよ
もう何も期待すんなよ

gitのWindowsでの日本語ファイル名問題だけでここまで引っ張るのはすごい

>>247
シェア高いのって何？やっぱりSVNやCVSなのかな

gitすげーさいこーっていう流れの反動と、svnみたいに簡単に
使えないことへのがっかり感とが怨念っぽくなってるんだろ

>>249
まあ、バージョン管理システムて基本大勢で使う為の物になってしまったから、
バージョン管理システム自体の「癖」を気にしながら使わなきゃなのわ。
ちょと、辛いよね。

問題はgitユーザーがとにかくSVN等を馬鹿にしていて
SVNがWindowsや文字コードに完全対応している事すら何故か見下し馬鹿にすると言う意味不明な行動を取っている事じゃなかろうか。

gitユーザーが最初に怨念染みたネガ波動を全方位に振りまいてんだから、それがそっくりそのまま帰ってきてもあたり前だろうに。

gitスゲー他のvcsは全部糞git最強とか繰り返してるのを見てwktkしながらgitを試してみたら

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

それはもう遣る瀬無い気持ちになったとさ

>>224
gitもSubversionもどうでもよくて、煽り合いたいだけの奴らが少なからず混じってるだろう

暇で必死なバカが一人いるな、という感じに見える

>>245
つまりはそういうことだね。

仮にファイル名だけ文字コード変換したとしても、
Makefileみたいにファイル名を直に書いているファイルがあるとうまくいかなくなるよな

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

だからそういう問題を忘れて、POSIX APIを仮定して（ファイル名＝バイナリ文字列）プログラムを書くというのは
それなりにわかりやすい態度だと思うのよね

GNU周りってモノはそんな悪くないんだけど、コミュニティが最悪にガキ臭いよね。
Gitが文字コード問題に取り組まないのも、大嫌いなWindowsに関わる事なんざ知ったこっちゃ無いと言う小学生レベルの理由以外は何も無いし。

>>256
ファイルの中身のエンコーディングについてはバージョン管理システムは関係ないだろう。
勝手にごっちゃにして実際に発生している問題を正当化する材料にするのはおかしくないか？

>>256
OS含め全てがマトモに文字として扱っている限りはそんな下らん問題は発生しない
問題が発生するのは、どっかのタコプログラムが文字列(ファイル名等)をただのバイト列として扱うから

>>259
> マトモに文字として扱っている

マトモな文字の扱いかたをしてるものって、EmacsとRubyぐらいしかないんじゃね？
OSなんか全滅だろ。

うん、Unix派生OSは全滅だね

つまりgitは無責任にOSに文字列の扱いを丸投げしているだけで
実際に文字化けを起こしているのはLinuxとかのタコOSなんだよ

>>257 gitはGNUが作ってるわけじゃないけど。

>>251
確かにLinusはSubversionをバカにしたけど、Windowsで日本語ファイル名がダメ
とかっていうのは、単純にWindows使わないから知らんがなーなだけ
だと思う。Windowsダッセーとかっていうのは昔から言ってるしね。別の話だよ。

gitに興味持ってこのスレ覗いたwinユーザーは安易にgitを使わないで下さい。

winでは文字化けします。

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

導入したいならWindowsを捨ててください。

日本語を捨てるのが先

または、全部ローマ字でkakebaZenbuKaiketsuDesu.

同じマルチバイトの中国語や韓国語は問題ないの？

田舎アプリユーザーはASCII以外興味ないんです
無理言わないであげてください

>>267
ASCII Onlyでないやつはすべて問題あります
それでも日本がダメだと言い張るのがこのスレのクオリティー

gitはlinuxどうしでもlocaleが違うとだめだよね

Linuxが糞なだけでgitは悪くないっしょ

Linuxの世界ではファイル名は文字列じゃなくてバイト列なんだよ
（'\0' と '/' 以外の任意のバイトが使える）

これはバグとかそういう問題じゃなくてただの文化の衝突だからどうにもならん

そんなん何十年も昔の妥協点を未だに引きずってるだけの話でしょ
文化の衝突じゃなく、単にコミュニティがascii以外に興味が無いだけとしか思えない

http://www-06.ibm.com/jp/domino01/mkt/cnpages7.nsf/page/default-007ACA9B
Windowsの方も、アプリケーションにSJISでファイル名を渡してくるような状況を変えられないとねぇ…

あと、そもそもLinuxはOSがロケールにアクセスしないから
システムコールレベルで文字コード変換を云々するのはそもそも不可能だな

>>274
知らんなら黙れ
SJIS自動変換は当たり前にOFFにできる

>>276
offってどうやるの？
別関数使うならわかるけど

馬鹿には見えないマクロ郡を使って

.netのSystem.Diagnostics.Processで引数としてファイル名をUTF-8で渡す方法は？

突然関係ない都合の良い話を始めるのはgit病の症状なの？

Git脳の恐怖

>>280
ファイル名関連はBzr病だと思う

OSがファイル名をUnicodeとして管理している場合と
OSがファイル名をただのバイト列としか思ってない場合とじゃリスクは比べるべくも無い

ここで修正パッチも出さずに、gitがWindowsでうんこといっても
暗にhgもクソ、Bzrマンセーしているようにしか見えないし

せっかく賑わってきたので現実的な解決方法を話しあいたい。

ぶっちゃけアドホックでもいいので
「Windowsで(UTF-8なcygwin環境以外でも)日本語ファイル名が
他のプラットフォームと相互運用してもSubversion並に問題ない」というような
（↑要点あってるよね間違ってたら言って)
現実的な解決方法って何かないもんなんでしょうか？
Windowsユーザー的にはツールはTortoiseGitとmsysgit辺りでなんとかなればいいんだと思う。

身も蓋もないことを言うようだが、TortoiseとかでGitやっても、Subversionと同じ使い方しか
しないような気がする。そんなことない？　失礼しました。

>>286
同じじゃだめなの？
コミットがローカルにされて、pushとpullを覚えるくらいのイメージなんだが。
ブランチだなんだと面倒なことは慣れてから理解。

いきがってstashとか使ってたら大昔のやつをpopしてしまって
コンフリクトの嵐。戻し方がわからず泣きそうになった。resetとか怖い

gitはrebase -iで履歴を組み換えるのが楽しいぞ。

>>285
>>110

Mac問題はシラネ

>>287
いや、ダメっていうか、svnと同じ使い方しかしないのなら、移行にかかる学習コストや
既出の障壁なんかを考えると、無理に導入する必要あるのかな、と。

なんども言われてる事だと思うけど>>285みたいなのはSubversion使うべき
無理にgit導入すれば周りから迷惑な奴と思われてしまうよ
さらにgitの文字コード問題を知ってる奴から見たら馬鹿な奴と思われるだけ

なぜ無意味に上に立ちたがるのか

subversionなら日本語ファイル名の相互運用が問題ないっていう妄想はどこからくるわけ?

>>293
ja_JP.UTF-8 のDebianで「十表.txt」を作成、svnでコミット。
これをWindowsのTortoiseSVNでチェックアウト。問題なし。もちろん逆も。

これくらいのことなら、もちろんGitでもできるんだよね。
これくらいのことが普通にできればそれでいいんだよ。

>>290
・ 全ディレクトリに.svnが作られ、ディレクトリのコピーが気楽にできない。
ネストしたディレクトリのコピーとか、結構面倒。そのままコミットするとsvnが錯乱する
・ 全ての編集が毎度中央レポジトリにされるので、一時保存的なコミットができない。
　 なんか恥ずかしいし、あとから見たらゴミでしかない。
・ やっぱり、ネットが切れててもコミットしたい状況はある。

別にgitじゃなきゃいけないわけじゃないけど、この辺はなんとかしたい。

終了してしまったけど、svkはローカルリポジトリの履歴を
上流にpushするときに改変できたりしないの?

>>296
svkはできるよ。svnリポジトリ間のマージにも重宝する。
ただ、けっこうかなり重たいんだよな。。。
でも
* .svnは無い
* ローカルコミット可能
* リモートにpushする時にまとめたり出来る
ってのは>>295の要望には合ってそうだね。

svnの延長として分散型使いたいならBzrは悪くない

逆に、Bazaarは何がイケてないんだろ
使い方が難しいのかな

まあ、後発だからな > bzr

社内のバージョン管理をgitで統一しようと思う
日本語ファイル名禁止のメールを全員に送らにゃならんが

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



　　　　　　　 　　　　 ｜
〜〜〜〜〜〜〜〜｜〜〜〜〜〜〜〜〜〜〜
　　　　　　　　 　　　 ｜　　　　　＞( c´,_ゝ`)
　　　　　　　　 　　　 ｜
　　　　　　　　　 　　 J　　　＞( c´,_ゝ`)
　　　　　　　　　　　　　　　　　　　　＞( c´,_ゝ`)

>>299
何でもできるような余地(集中型・分散型どっちもおkとか)を残しすぎてて、
内部の動作を理解しないと使いにくそうに見えるところ。
リポジトリとブランチは別物とか言われても、「なにそれこわい」にしかならんと思う。

>>299
むしろ逆。普段からgithubとか使ってるとなんでgitじゃねーんだよ！って感じになる

まあ、仕事でWindowsだとBazaar、趣味やOSS開発だとgitとつかいわけてもいいんだが

>>303
> 内部の動作を理解しないと使いにくそうに見える
これはまさにgitにも言えることではないかと思うんだが、gitはあれでシンプルなのか？
rebaseとか言われた時点で、あ、これ無理とか引いてしまう

構造的に最もシンプルなのはgitだろう
だからといって使う人が理解しやすいかということは別問題

gitはresetでコミットが消えるとか言われた
コミットが消えるバージョン管理とか、なにそれこわい
どこかには残ってるんだよねそう言ってよママン

正直gitには、
ttp://d.hatena.ne.jp/idesaku/20091106/1257507849
こういう情報がもっと一般的に、大量に、言い換えれば懇切丁寧に、公式に、これくらい柔らかく必要だ

>>285
msysgitはどうにもならないと思う。
TortoiseGitのバックエンドをcygwin版gitにする方が見込みがありそう。

gitは趣味に留めて業務で使わないでくれよおまいら

Gitはおもちゃだし

そのおもちゃをソースコード管理に使っているLinuxはしょせんおもちゃプロジェクトであり
シェアなど1%前後で十分ってことだ
ttp://marketshare.hitslink.com/os-market-share.aspx?qprid=9

↑Winユーザーの嫉妬はみっともないな

↑おもちゃユーザーの嫉妬はみっともないな

mercurial-1.5.2.tar.gz

なぜ hg のスレに書かずに、ここに。

バカなWinユーザーがいつまでもgitに嫉妬してるからです
早く別のを使えばいいと思います

↑gitがこんな考えしてるから無駄に叩かれるんだよ

前のほう読むと、Windowsに対応してないとか意味わかんない！　って突っかかってるように見えるが

gitにshit
yeah

>>319

>>319
そんなのLinuxをおもちゃとか言ってるバカの粘着だけだよ
お子様にはsvnを使ってもらいたいねぇ

ほら、無駄にsvnを見下してる
文字コード問題とか言う初歩的なバグを直せていないのにコレだよｗ

良いと思うならメリットを論じれば良いのに

>>323
バグじゃなく、実装されてないだけ
その違いがわからないならム板でレスしないでね

仕様って素敵やん

>>325は確実にMSの「仕様です」回答を散々馬鹿にした奴らの一人

仕様よ仕様。でもちょっとだけ仕様じゃないの。

仕様バグって奴か。
一番深刻だな。

つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
仕様って事にしたいんですね、わかりますん。

つーか想定外の用途なので欲しい人頑張って。

つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
想定外の用途って事にしたいんですね、わかりますん。

問: gitは何のために作られましたか?

Linuxで使えればOKと思われている以上……ね。
ttp://www.garbagecollect.jp/~usa/d/200904b.html#id20090417_P1
# 1年前のエントリだが。

>>332
特定のOSの開発用に作ったバージョン管理システムが、とあるプラットフォームで
動かないからクソだって罵るのは別に自由だし、他のを使えば済むことだし、
あなたの意見はよく分かったから勝手にして欲しいんだけど、いつもまでも同じ主張を
延々とやられるとウザったいからもういいよ。

つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
特定のOSの開発用に作ったって事にしたいんですね、わかりますん。

こいつもうただの荒らしだな。
Gitが何を目的にして作られたのか知らないのか？

要するに不用意にWindows版作ったgit開発者が悪い

つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
Gitが何を目的にして作られたのか知らないのか？って事にしたいんですね、わかりますん。

結論は>>338

つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
ベースではなくWindows版だけが悪かったって事にしたいんですね、わかりますん。

>>331
こういうこと言ってる奴ほどMSのこういう態度を批判するんだよなｗｗｗ

>>342
MSの場合ソースコード非公開だから、頑張りようがないと思うが

ん？頑張って他に移ってねって話では？
散々svn使えって言ってきてるじゃん

つまり、要約すると、造ってる人間達に能力がない為、
できない事を「やらないだけだよ！」って振りをする為、
svnはクソだからgitを造ったのに結局使うなって事にしたいんですね、わかりますん。

言い出しっぺの法則というものがありましてね

そうだね、Windows版作ろうとか言い出した奴は最後まで責任持たないとね

>>345
gitに嫉妬してここで文句言えば誰かがgitをWin用に対応してくれるとでも
思ってるだろお前？
幼稚なコピペばかり繰り返して頭悪いんじゃない？
造ってる人間達に能力がない為と言うなら自分で対応しろよ

嫉妬とかそういうくだらん発想で会話するから、馬鹿にされるんだよ

ここで暴れているのってgitばっかりのような気がする。

信者が必死なんだろ

誰がどう見てもアンチが必死

日本語表示できないのは事実なんだから適当に流せばいいのに
いちいち言い返さないと気がすまないもん同士でエスカレートしてるだけ

誰か他の話題たのむ。

CVSの話でもするか。

ミンナダイスキ
IBM Clear Case

で、ちょっと分散型のを使ってみようかとなったら、
・WinでもLinuxでも
・日本語ファイル名なんざ金輪際使わねぇなんてポリシーは無い
って場合には、gitは駄目で将来的にも直りそうに無いということは
分かりました。

とすると、マーキュリアルとかいうのとバザールでござ〜るの
どっちが良いんでしょうか。

>>356
その二択なら、迷わずbzrを取った方がいいような気がする。
両方コミュニティの雰囲気とかよく知らないけど。
hgのgitに対する優位って何かあるの？

hgも日本語対応のパッチはrejectされたんじゃなかったっけ？
まともに期待できるのはbzrしかなさそう

>>357
hgはgitと比べたら、基本的にpythonだけで動くところと、コマンドラインで
使いやすいのがメリットかな

そのマニアックな利点を利点と感じられる人間は、ぶっちゃけ何でも使えるだろ
gitと同じ日本語問題を抱えてるなら、乗り換え先として魅力はかなり少ないような

ちょっと本腰いれてbzr使ってみるかな
bzrは、以前触ったときにはTortoiseよりもむしろBazaar Explorerがいい感じだと思った
あとはCUI出力(log とか status)に色が付けられたら、たぶん文句なく使えそう

「日本語対応」とか言ってるから、git儲がいつまでも付け上がるんだぜ。
「国際化対応」と言えば、もちろん「できない・やらない方が悪い」。
つまり、git儲は視野が狭い独善的な国際的悪者なのだ！

またバカが来たよ

よっぽど恨みに思うようなことがあったんだろうな

国際的患者に見えたわ

Git と Mercurial が Subversion より優れている点 - tcha.org
http://tcha.org/blog/2010/02/01/dvcs-over-svn/

Subversionが（現状）GitやMercurialより優れている点

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

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

あと、Gitは自動マージに頼りすぎで、衝突の解決をさせる強制力が弱い気がする。
なんでもかんでも add . でコミットできてるんじゃねーよ。これは使う人間次第だろうけど。

>>366
それはTortoiseSVNの機能。Subversion自身にそんな機能は無い。

早くGitにもすてきGUIを作ってくれよ

>>368
あっても無駄だろ。
ファイル名を文字として認識して無いという国際化対応での駄目っぷりが直らない限り。

gitみたいな複雑な利用をするものほど、GUIの恩恵は大きいと思うんだ

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

みたいなのが、結局記憶ベースかコマンドからのテキスト読解もしはハッシュコピペベースって、
お世辞にも使いやすいとは言えない

>>368
つTortoiseGit

>>366
> 366 名前：デフォルトの名無しさん [sage]： 2010/05/05(水) 09:07:04
> Subversionが（現状）GitやMercurialより優れている点
>
> ・ 変更の確認…アイコン見るだけ。diff・mergeは右クリックでWinMergeU
> ・ その他のほぼ全ての操作…右クリックでごにょごにょ
>
> 何を言っても、全てはこれに尽きるだろ。
>
> あと、Gitは自動マージに頼りすぎで、衝突の解決をさせる強制力が弱い気がする。
> なんでもかんでも add . でコミットできてるんじゃねーよ。これは使う人間次第だろうけど。

TortoiseHg ならほとんど全部　GUI　で出来る。
コミッタに日本人２人いるから、がんがん要望を日本語であげることもできる。
メニューなどの日本語化も終わっているし。

の割にはスレにぎわってないよねえ。
不満がないのかあきらめてんのか。

俺は……まあ両方かな。bzr と併用しつつ様子見。

自分はシェルでのCUI操作とgitk(gitリポジトリ履歴ビューア)の併用で慣れてしまったし別に。
他のバージョン管理システムも、そう悪くないんじゃないかとは思うけどね。

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

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

あと、svn/git/hg/bzrに限らずバージョン管理システムのクライアントは
Tortoiseのようなエクスプローラ統合型だけでは無く、
Eclipse/NetBeansなどの統合型開発環境への組み込み型プラグインという形態もあるのだから、
用途によってはGUI等の実現はそちらの方が便利、というケースもあるんじゃ？

そんなに内容の無い長文書いてなにがしたいの？

批判されないように妥当な事ばかり書いたら何も内容が無かったと言う

>>370
俺は逆にマウスでポインタ合わせしまくらないといけないGUIのほうが疲れるな。
コード書きもGUI使わないし、マウスでコミットとか何か間違えそうで怖い。
ただマージが複雑になってくるとgitkみたいなのが無いと理解するのは難しいね。
>>370みたいな人が居るってことは、そのうち使いやすいGUIも誰か作るんじゃない？

ちょっと前、Java の Mercurial 環境の試しで、
NetBeans は NetBeans が Mercurial で開発されているので、何もしないで使えた。
Eclipse も結構いい線いってた気がした。
結局、Mercurial はコマンドラインで、Java は maven が一番快適だったが。

自分は普段はコマンドラインで使ってるけど、
人のコードを調べたり、人のコードをレビューする時の道具として使うときは
GUIとWebUIの方が楽ちんだな。

>>372
Junioって日本人として全く役に立ってないんだねぇ

>>372
TortoiseHg前に使っててすごい便利だったけど(部分的にはTortoiseSVNより便利だったところ合った気が)、
Mercurialがマルチバイトファイル名の問題が解決されないので今は様子見中だわ・・・

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

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

IDEの組み込みは便利なんだが、IDEを変えられないという欠点が…。
言語ごとに適してるIDEがあるから、下手すると言語ごとにバージョン管理システム変えるハメに（はならないかｗ

>>380
日本語メールはスパムとして弾いてるほどの人だし

>>380
JunioってGITのPLだろ？

マルチバイト圏の人間のクセにシングルバイトしか考えないこの有様
一体どれだけ無能なのやら

>>382
mjd?

>>382 >>384
そういう人じゃなきゃ、gitやhgは馴染まないってことだろ
無理して日本語Windows環境を捨てて開発しなきゃいけないとかおかしい

ぶっちゃけCygwinなんて興味ない人に使わせるの無理ありすぎだ
精々、Macオンリーまでが許容範囲じゃなかろうか

いいえ

自助努力という言葉が辞書にないのがドザ、ってことだけはよくわかった。

Windowsは関係ない
前世紀から使っているようなeucJPのNetBSD機が混在しただけでも破綻する

Mac OS Xのように、UTF-8 と UTF-8-MAC という微妙な差異も意外と苦しそう。
（主に濁点・半濁点を用いた平/片仮名文字）

>>390
gitやhgをクイックハックでなおすとすると、WindowsよりMac対応のほうが面
倒くさそうだよね

MacOSX はそれが本当に面倒でなぁ。

エンドユーザに自助努力を要求するようになったら開発者としちゃ下の下。
余計な苦労は無いに越した事はない。

例えば誰？

NFCとNFDの違いはUnicodeの仕様だから我慢するとして、
他にもMacは文字マッピングが違うところがあるらしいけど、
具体的にドレ?

その辺、普通にスレ違いにも程がある話題ではあるんだ

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

何が何でもbzrを盛り上げて、svnかbzrの二択にできないもんかね

>>389
ああっ！ってか確かにそうだよな。
Linuxなんかはいつの間にか(というと失礼と無知さらしだが)UTF-8当たり前になってたから最近はいいんだが、
以前のEUC_JPからの環境はWindowsと同じで切り捨てってことか。

>>390
最近、たまにwebでまれによく見る濁点と半濁点がかなと別に表示されている、みっともない文字のことかな？
ブラウザでテキストで選択すると一緒に選択されるもしかしてあれか？

>>397
Linuxの場合は、locale切り替えでなんとか対応出来るんじゃね？既存ファイルは別として
Windowsでもそれができれば別に問題ないとも言えそう。まあできないんだがな。

>>390
濁点とかアクセント付き文字はUnicode自身が合成済みのと分離状態
の両方の文字を持っていて、利用システムで好きな方式を採用してい
いんだけど、両方区別なく扱えるようにしてよね、ということになっ
ている。

>>396
日本語対応の観点から、現実的にはすでに svn と bzr の二択
しかないと思うが、git と mercurial はググったら日本語の
解説ページがいろいろ引っかかるのに対し、bazaar でググると
もともと日本語のページは少ないうえに、物を売るバザーの
ページもたくさん引っかかって情報収集がしにくいので、
まず情報収集しやすい git か mercurial に手を出してしまう、
という罠があると思う。

>>399
つまり、RDBMSなんかでは両方ヒットするのが正しい実装、ってことでしょ？
エディタの検索・置換なんかでもしかり。
で、gitやhgでは？…って、聞くだけ野暮なんだろうね
subversionやbazaarができてるかどうかは別にして、"ポリシー"的に

まあそろそろ、声を少しだけ大きくして言ってもいいと思う
ファイル名やましてやコミットログは、バイト列じゃないんだぜって
まずLattin-1を普通に使ってる奴をつるし上げればいいと思う

Latin-1な
それってドザだろ

忠告じゃないけど、”ドザ”って書くと「頭悪いMac信者」というアピールしているように見えるからやめた方がいいよ。
突然に中国とか韓国ネタ書くやつと大差がない。
不要に荒れる要素出す必要ないだろ

おおっと、別に >>403 が「頭悪いMac信者」だと言っているわけじゃないからな、
誤解を生みやすい表現失礼

文字=バイト列な田舎モンがドザドザ言ってるのはなんか滑稽

シェア1%でこれだけ声がデカイ奴らなんだから、相当アレな奴等じゃないと勤まらんよね

いいから黙ってアメリカ語使えおまいら

fuck you

fack you位言えよ

b*******k

gitやmercurialがUTF-8で問題ないってのも、単純に「ただそこにあったUTF-8」なら
あんまり問題ないみたいね、ってだけで、Unicodeがどうたらってことには全く無頓着
ってことでいいのかな

もちろんバージョン管理システムの開発って観点では、んなもん関心の対象じゃない
ってのはわからんでもないけど、使い勝手や発展性という点では正直、疑問だと思う

満足に「文字」として検索できない時点で、相当のタコだと思うよ
UTF-8が非常に優れた物だったから辛うじて保ってるだけ

大喧嘩の末別れた上に、今でも事ある毎に叩いてる所の技術におんぶに抱っこで恥ずかしくないのかな、彼らは

>>413
いや、そのためにUTF-8は生まれたんじゃないか。

今の時代、UTF-8専用でもかまわないと思うが、WindowsでANSI APIを使うのは
避けてほしいところだな。

いいから黙ってアメリカ語使ってろおまいら

hey boss, bull shit!

Get out of here!!

ゲラウトヒア！！

Yes, you must'nt say "ｹﾞﾗｳﾄﾋｱ!!", OK?

>>413
一体どのUTF? win linux ms どのUTFも互換性ない上に、リビジョンがあるんだけど。

>>420
バカ現る

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に対応するときに理解できるかな。

>>413
＞大喧嘩の末別れた上に、今でも事ある毎に叩いてる所の技術におんぶに抱っこで恥ずかしくないのかな、彼らは
これはドコとどこの話？

とりあえずASCIIを可変長のマルチバイトにして符号化方式も3種類くらい乱立させればいいんじゃね？
世界中が幸せになるよ

いやASCIIはASCIIだし

ASCII範囲を置き換えるくらい分かれよアスペル君

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

TortoiseSVNって? TotoiseGitの間違いだよね?

というツッコミはさておき、msysgitマターでしょう常考
ていうかmsysgitインスコ不要にしてほしいと思う俺だ。

他のバージョン管理ソフトみたいにlibgitみたいなのがあって、
それさえ読んでればgitの機能使えるとかだとできるんだろうねえ

TotoiseGit はとにかく不安定。
ソース見たら、Windows オンリーぽかった。
TotoiseHg, TotoiseBzr みたいに、PyGtk, PyQt だったら何とかなりそうな気もするんだが。

GUIが必要なのってWindowsユーザーくらいだろうから（自嘲）
ネイティブでいいと思う

gitならTortoiseGITよりgit extentionsかな

JGit - Java GIT ってのがあるみたいですね。
http://www.jgit.org/

いらねぇ

Javaって聞くだけで拒否反応が起きる俺はV2C使い

gitで間違えたユーザー名でコミットした場合はどうやってなおせばいいんでしょうか？

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

のようにしてgit log -1してみても、authorが書き変わってくれません(´･ω･`)

git commit --amend -m "saido commit" --author="new user <[email protected]>"
で行けました。

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

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

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

この辺のドキュメントはどこを見ればよいのでしょう？

国家機密レベルなら、むしろ間違えたコミットの前まで戻って
もう一度やり直す（ブランチを切り直して無かったことにする）のがいいのでは？

まあpushしなければ全てはローカルでの出来事なのは確か
push前に確信が持ちたかったら、ドキュメントはむしろソース嫁レベルじゃないかと

>>438
git gc するまではリポジトリに残ってるよ。pushした先も同様。
ドキュメントはgit help gc とか？

ありがとうございます。
git reflog
や
git log --author="old_name" -p

のように試してみたのですが、git gcしても残りますね・・・。
amendだと残ってしまうん？

x git log --author="old_name" -p
o git log --author="old_name" -g

ああ、reflogは共有されないんですね。まあ、いいのか。

ログメッセージに書くべき内容って、バージョン管理ツールのマニュアルに書いてないみたい
なんだけど、どっかに文書でまとめられてたりしない？

>>443
あなたは自分が何をすべきかご存じないのですか?

あるわけねーだろ

つ ChangeLog

>>443
コード中に書くコメントとほぼ同じに考えればいいよ。
書くべきは「何故」そういう変更をしたのか。
後は、「どういう」変更をしたのかも簡単に添えておけば、
いちいちdiffする手間がちょっと省ける。
(ここがちょっとコード中コメントとは違うかな)

関数名を変更とか、変数を追加とか、は比較的書く意味が薄いな。

>>448
なんでそうしたか書けばいいじゃん。
実態と合わない命名を修正したとか、ソース整理したとか。

そういう機能や仕様が変わらない変更は
ほとんど「リファクタリング」の一言ですましちゃうな

trivial change
trivial change
trivial change
・・・

>>449 うん、理由を書くならいいんだよ。それを否定してはいない。

最悪なのは「いろいろ修正」とかだな。ログメッセージ空のほうがまだいい。

>>453
(´；ω；｀)ｳｯ…
偉い人も
「明日の自分のためにもちゃんとログを残しておけ」
って言ってるけどなかなか実践できてないや…

ここまで総合するに，ログに書くべき内容は，
変更箇所 + 変更内容 + 理由
といったところでしょうか。
些細な変更には，変更内容と理由を合わせて "refactoring" などの一言でOKと。

ちなみに，ログの形式はどうされてますか？

変更したモジュール名だけを書くやつもおる。

>>455
自分の考えを述べてみよ。何のためにログメッセージを残す？

変更箇所と変更内容は差分を見れば自明なので、最悪の場合差分を見ればいいけど、
理由を書いてないと変更した本人以外わけがわからなくなることが多い。

お前ら何言ってんだ
ログに残すのは「何々がしたかった」に決まってんだろ
他の情報は全て蛇足でありノイズ

> 「何々がしたかった」
で、それは実現できたの？できなかったの？

>>460
バカなの？
そんなもの後になって運が良ければ分かるだけの話
「したかった事を実装した」直後には「したかった事が実現できた」など断言できん

オプションの追加や、メソッドの追加は歴然と事実としてあるんじゃないの？
それを、オプションを追加したかった、メソッドを追加したかったと記述するのには違和感がある。

多分、実装途中のログの表現について言ってるんだと思うけど、
「〜中」や、現在進行形で良いのでは？

自分の場合、
一連のコミットで共通になる事柄をTracとかRedmineとかのチケットに書いておいて、
コミットログは「○○のために××した、#xx」(#xxはチケット番号)にしてる。

遊ぶ金が欲しかった（過去形）

レスを勘違いしてたかもしれん。

「〜したかった」とそのままログに書くのではなく、
「何々がしたかった」を指針にその内容をログに書けってことかな。
理解しきれてないけど。

後からバグが発覚したときに後悔しないようなコミットログにしようぜ。orz

この変更をコミットしたのは誰だぁ
svn/git/bzr/hg blame

>>459　した事を書け！！
とレスして欲しかったんですね。わかります。

>>462
バカすぎる
お前の手書きした「メソッドを追加した」と言う情報に一体何の価値があるの？
そんなもん最もログに書く意味の無い、ノイズの極みだよ

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

これで理解できないなら、もうお前はパッチをコミットログにコピペしとけ
抜け漏れが無いことが保証されてるから幾分マシ

>>468
何も分かってねぇ
「した事」なんざDiff見りゃ分かる
「その意図」を残すのが最も重要

お手本plz

>>469
これは失礼しました。

要するに、上でも既に述べられてるけど、理由を書けってことね。
あなたの言葉を焼き直すと、動機を書けになるのかな。

いや、目的を書けだろ

>>472
何でそんなズレてんだか
動機なんてオマケだろ

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

コードを追う上で面倒だったと言う感想なんざ要らん
コードを変更した理由として動機を書くのはタコ
コードを変更した理由として目的を書くのが正しい

ユーザーから仕様変更の依頼があったので
っていう動機は？

オマケとして付いてる分にはかまわん
目的抜かして動機だけ書けば良いと思ってるなら>>472と手を取り合って死ね

目的を書く事が重要なのは同意だが、なるべく修正箇所の要約もログに残ってると便利だがなぁ。
改造目的を読んでコードの修正内容が連想できる場合は良いけど、そうでない場合に逐一Diffを
追いかけて目的のリビジョン探すなんて時間の無駄じゃね？

目的とか動機という単語は、かなりメタな言葉だ。
新規実装の時とバグ修正の時と仕様変更の時で、それぞれコミットログに求められるものが違うだろう。

>>474
その状況で「手動で〜するのが面倒だった」をログに書かないなんて、ありえない。

自動化による効率化の為、とでも書けば満足なんじゃね？
動機と目的はそんなに遠い言葉じゃないと思うので、要はwhyを書けってことかな
howやwhat、where、whoは勝手にわかるのでいらねってことかと

>>480
when が抜けてるぞ。いらないけどな

WHY > WHAT >>> （必要なら） HOW でFA？

>>481
なぜその位置にwhatがあるんだ
たとえば「変更する」を補うと
なぜ変更したか→コミットログしとけ
何を変更したか→diffがあるよ
どうやって変更したか→どうでもいい

ちょっと大きな修正の場合、「何をどうして」こうなったって記述が
必要になるケースはあるだろう

機能追加のコミットなんかは、まさにwhatがメインだな
原則さえ抑えておけば、ケースバイケースでいいじゃないか

普通、コミットログは、1行目だけは特別扱いされてる。
だから、1行目は見出しとして書くべき。2行目以降は妥協しても良し。

「それをなぜしたのか」 → why
「それは何をしたのか」 → what
「その修正はどういうロジックなのか」 → how

こんな所だろ？それぞれ必要なケースも容易に想像できそうだけど…
最初以外は、ソースのコメントに書くべきかもしれないとか、そういうことなのかな

「What」はDiff見ろって効率悪過ぎだろ
リビジョンいくつあると思ってるんだよ。

全部のWhat見て何がしたいの？
Diff見るのすら手間になるような数のコミットで、漏らさず変更箇所を書く労力は考えないの？
後で漏れてた事に気付いたらどうやって修正するの？

もちろん後の祭です(ｷﾘｯ

というか、変更箇所の要約無いとダメとか言ってるお猿さん達はpatchをgrepする脳みそを備えてないの？

例えば、こんな感じ？
Why ZZ社 特許XXXXXX 請求項nnの回避
What xxxx算出式を変更
How yyy係数を0.125の倍数に変更

>>474
結局何も新しいこと言ってないんだよな〜

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

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

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

動機 = 理由だから、理由に動機を書いてタコな理由が分からん。
目的にこだわる理由を教えてくれ。
理由も動機も目的もニュアンスは同じ。
>>447が指摘済み。

>>467
単にざっと眺めるだけならannotate, 「この行追加したの誰だ。氏ね」という
気分の時にはblameを使います

仕様の変更点を探す時はwhy、実装の変更点を探す時はwhatがあった方がいいやね

>>493
bzrだとannもblameも同じなんだが、他は違うの?
つーか、「この行消した間抜けは誰だ」ってときには使えないし。

>>492が本物のバカなのはもう疑う余地が無い
問題：「手動で〜するのが面倒だった(動機)」
解法：「自動で〜する機能を実装した(したかった事＝目的)」
計算式：Diff
で、解法が書かれていれば計算式の正しさを検証できる
問題と計算式しかない場合、想定していたであろう解法を計算式から予測するしかなく、誰にも検証できない

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

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

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

>理由も動機も目的もニュアンスは同じ。
そりゃ大層な無学だな
健康上の理由で辞職する
健康上の動機で辞職する
健康上の目的で辞職する
これじゃ日常会話にすら支障が出るわ
現に出てるし

文脈もあるよな。ログメッセージ読むってことは多少なり開発に足突っ込んでるだろうから、
簡潔な文章でも他の開発者が「意味わかんねーんだけどナニこれ？」ってならないなら
それでもいいし、けっこう突飛なこととか誤解されそうな内容だったら冗長に書く、
それでいいんじゃないかね。

>>496
問題と計算式だけあれば、問題が解決されているかどうかで変更の妥当性を検証できるんじゃないの？

>>498
できない
コードは書かれた通りにしか読めない
そのコードで本当にやりたかった事など誰にも分からない

>>499
やりたかったことは、その問題を解決したかったということに決まっているじゃないか。
具体的な方法は Diff にある。これで何が不満なの？

>>469
前任者の履歴コメントなんて見ないよ
何かを知る必要があればdiff見る

annotation知らん奴が多そうだな

>>500
いい加減日本語も不自由で人のバグを追ったことも無いタコスケは黙れば？

「手動で〜するのが面倒だった(動機、問題)」ので「〜の条件化では自動で〜する機能を実装した(目的、解法)」
で、お前の作り出した糞の塊であるコミットログには問題しか書かれて無いわけだが
その条件式の必要性と正当性はDiffから読み取れるのか？
こんなシンプルなケースすら想定できないって、どんだけの未熟者が口出ししてんだよ

>>503
何か後出し来たな・・・。まぁいいか。

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

ログに「〜の条件下では自動で〜する」と書かれていてもその条件の必要性と正当性は
結局ソースにコメントでも無いとわかんないよね？

>>504
で？だから何？
結局ソース見なきゃわかんないからログには「手動で〜するのが面倒だった(動機、問題)」だけが書かれていれば十分と主張するの？
もういいよ、お前は生まれ付いての糞転がしで、糞の塊を作り続けるのは本能なんだよな
俺には糞転がしのライフスタイルを改めさせるだけの力は無かったと言う事で終了

>>505
こちらの主張は、挙げられた例で「手動で〜するのが面倒だった(動機)」にあたるような内容こそ
ログに書くべきなのであって、それを否定するような主張（「〜はタコ」とか）は間違いだと言うこと。

別に「目的、解法」にあたる内容をログに書くことを否定しているわけじゃない。しかしそういった
内容は対象のファイル自体から（ログを追わなくても）読み取れるべきだとも考えているので、
そこがログの要点であるという主張には疑問が残る。

>>505 無意味なレッテル貼りや煽りをやめればそういう力が付くかもね。がんばれ。

目的はソースからはなかなか読み取れないと思うなぁ。
ベテランならともかく、若い子の書いたソースなんて
なんでこんなことしてるの？ってのがよくある。
そんなソースに限って、「変数を初期化する」みたいな
無意味なコメントばっかりだったりする。

>>508
それはソースのコメントで済ませるべき問題であって、ログに書くべきこととは違うんじゃない？

>>509
人と仕事したこと無い奴が人と仕事するためのルールに口出しするのはおかしいと思わない？

バグ修正は、
Fixes #xx (BTSの番号) 簡単な記述。
で十分。

>>495
subversionに文句を言ってくだしあ> <

コミットの粒度の問題もあって、
新規機能開発で、git, hg の場合、
ローカルな複数のコミットを１つのコミットにまとめて push ってのもある。
CVS, Subversion の場合、ブランチなんだろうけど。

git-svnの質問いいでしょうか？

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

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

また今後はそうするとして、
今あるローカルブランチのログを残したいのですが今からでもsvnでブランチ作成してそこにコミットすることってできないんでしょうか？

>>514
git svn dcommitするならmergeじゃなくrebaseするべし。

>>514
master でそのまま作業して dcommit すれば？

コミットログもソースのコメントも、ここの図のように、
http://doc.bazaar.canonical.com/bzr.dev/ja/user-guide/bazaar_workflows.html#id7
あまりにもおかしいやつは、ゲートキーパーが突っぱねればいいんじゃないの？

>>495
svn annotate = svn blame = svn praise
気分によってお好みで。

あ、そういうことか。

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
気軽にブランチをバンバン切りたいのです…

マスタがSubversionなら、気軽にブランチ切っちゃいけないでしょ。

>> 520
そもそもSubversionは1.5まではマージの記録が残らなかったんだから。

>>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の現在のブランチの同期を図るような感じ。

>>521-523
ありがとうございます。

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

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

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

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

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


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

>>522
そもそもまだSubversion 1.4使ってる・・・(´･ω･`)

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

"git svn rebase" じゃなくて "git rebase" とまで書かないと理解していないっぽい。

アホ過ぎて呆れるわ

gitにはgitは使えないこの皮肉
これはgit自体がgitである事の証左にもなっている

うまいこと言ってるつもりなのか。痛いなー

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

このルールだと、結合テスト・総合テストの度にマージを繰り返していたってことなのか？
マージが終わったら、"svn rm ブランチ"なのか、放置なのか？
svnでブランチだらけって考えただけで・・・

アホな俺にアドバイスくださり、ありがとうございます！！

>>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はブランチがつくりにくい(作るコストやマージしにくい)から
長期のブランチのみで運用するってことですよね？

>>531
> 普通はsvnはブランチがつくりにくい(作るコストやマージしにくい)から
> 長期のブランチのみで運用するってことですよね？

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

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

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

gitはsvnから移行したのが多そうなので、svnを踏襲しているのが多そうに見える。

>>15
しかしあれを使ってリポジトリを作成するときにFSFSを選択しないと
後で痛い目をみるという

だいぶ前からデフォルトでFSFSだぞ

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
## 同じことをリモートブランチに対して行いたいんだけど、
## どうしたらいい？

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

＞git merge master
＞git rebase master
mergeしちゃったらrebase意味ないんじゃないか？

github で、あるリポジトリをフォークしたあとに、オリジナルのリポジトリを反映させるにはどうしたらいいでしょうか。

たとえば
http://github.com/rails/rails.git （オリジナルのリポジトリ）
をフォークして
[email protected]:myname/rails.git （フォークしたリポジトリ）
を作ったとします。
そんで、手元で git clone [email protected]:myname/rails.git を実行して
ローカルにリポジトリを作成しました。
で、そこで作業するのはいいんですが、オリジナルのリポジトリも当然更新されていきます。
その更新を、フォークしたリポジトリに反映させるのはどうしたらいいのでしょうか。

>>537
remote追加してpush.

hatしてgood

>>537
オリジナルをgit remote add してそこからpull
そんでそれを自分とこにpush

>>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 がうまくいくのか心配です。

>>540
fetchしてmergeないしはrebase

>>541
ローカルリポジトリに独自のコミットが無いなら単なるミラーになるし
独自のコミットがあればマージされる。コンフリクトしてマージ失敗することも
もちろんある。
てかGitはローカルで誰にも影響与えずにちょちょいと試せるんだから、
テストリポジトリ（テストリモートetc）たくさん作って試行錯誤してみたらいいよ。
あとsvnとかCVSの感覚でいきなり始められるものじゃないから、
一度は腰据えてドキュメント読まないとダメだよ。
ttp://progit.org/book/ja/
ttp://www8.atwiki.jp/git_jp/pages/27.html

テストリモートってあるが、ローカルにbare作っていじり倒せば良い。

テトリスモードに見えた

一般的な商用RDB（oracle、Sqlserver）ぐらいの確率でいいんですが、
リポジトリの壊れないフリーのバージョン管理システムはありますか？

あるよ

>>546
> 546 名前：デフォルトの名無しさん []： 2010/06/13(日) 17:58:35
> 一般的な商用RDB（oracle、Sqlserver）ぐらいの確率でいいんですが、
> リポジトリの壊れないフリーのバージョン管理システムはありますか？
>
git, Mercurial は、分散型だから、clone自体がバックアップの一種。

普通に良く使われてるのは壊れないんじゃないか？

>>549
Subversionの最初のやつ、bdbだっけ、壊れまくったらしいが。

bdbはリモートディスクで使うとぶっ壊れる。
いまはbdbを使わないFSFSがメインだね。

CVSの ,v チェックサム入っているように見えなかったんで
コミットログをエディタでいじったりしたんだが、これってまずかったのか？

この分野はむしろ商用の方が壊れやすいという印象。

>>552
お勧めはできないけど、独りで使っているなら遠慮なくどうぞ。
後は、CVSスレへ。

mac portのdarcsがいつまでたっても直る気配ない
乗り換えろってことなのか

Macからか？

初歩的な質問なんですが、gitでbranchを切って作業をして、
別件でmasterに戻って作業をする場合は、branch側でどんな状態でもcommitしてから、
masterに戻る…というので良いんでしょうか？

>>557
そういう時はstashのほうが手軽かも

開発担当にgitを使わせたいが、commitをどれぐらいの頻度で使わせるべきですか？
促さないとcommitしないし、コメントに何を書けば良いか分からないと文句が出るし、
本当にわけわかめ。

>>559
とりあえず、そういうのはいまどきの開発者として駄目だから、切ったらいいよ。

つーかちゃんと教えてやれよ

帰る前か、忘れたときは次の朝か、１日１回以下しかコミットしないやつ
たくさん居るだろ。

>>562
チケット切ってそれ単位にさせればいい。
別にチケット管理システム使えと強制はしないけど、残タスクの管理は
なんにしろやるだろ？そのタスク単位にコミットさせればいい。

>>558
おぉ、ありがとうございます。
git stashですね。便利すぎる。

git stashしたのってオブジェクトとして保存されてる？
違うブランチでgit stash popしちゃった時が怖いから
コミット作ってるなあ

>>565
>違うブランチでgit stash popしちゃった時が怖いから
あれ、違うブランチでstash popできるのが利点だと思ってたけど違うのかな。

英語力が貧弱すぎる上に、どうでもいいことなんだけど
checkout よりも checkin の方がしっくりきてしまう…。
でも調べると out が正しいんだよね。

なんで in のほうがしっくりくる？

普段聞きなれてるからかと

ホテルからチェックインする・・・

聞き慣れてないんだが

出る/出すんだからoutだろ?
何の捻りもなくて理解しやすいと思うが

ホテルはチェックイン、チェックアウト両方あるけど
飛行機に乗る時はチェックインだけだから
チェックインのほうが使う機会は多い

>>570は飛行機にも乗らないし、ホテルにも泊らないんだろう

○ホテルにチェックインする
○ホテルからチェックアウトする

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

って言いたいんじゃ

　　　　　　／/
　　　　／　.人
　　　 / 　（＿_） ﾊﾟｶ
　　　/ ∩(＿___）　　　あ、ぽこたんインしたお！
　　 /　.|（ ・∀・）＿
　　/／ |　　　ヽ／
　　"￣￣￣"∪

>>567 は廃人

>>574
てかそれ以外の意図に読み取る方が難しいよな・・・

ふと思ったけどcheck outの記録を残すVCSってあるっけ？
副次的に残るケースは考え付くけど。
そういう意味じゃcheck〜じゃないよな。

git reflogはちがうのけ？

>>577
CVSROOT/history

>>577
なんでも残せばいいってもんでもないと
宿のチェックアウトは、入った奴が出て行った、っていう意味しかないだろ
残ってたら課金しなきゃいけないしｗ

主はあくまでもインの方で

>>578
無いかと思ったらまさにそれか

>>580
手続きを伴わなければチェックアウトという言い方はしないよ
#飛行機でチェックインは言ってもチェックアウトとは言わないのはその為

おそらく昔のVCS(RCSとかSCCSとか)でファイルを持ち出す時にロックの手続きを
行っていたからチェックアウトという呼び方になって、その名残なんじゃないかな

git reflogなんでも記録残っててすごいな
やべ、間違った・・・ってときもとりあえずgit reflog
git gcとかpushする前なら戻せるのびっくりしたわ

gitで何か新しいことをやろうとすると、
なぜかコミットを失ってわけわからん状態になるので
毎回reflogで救い出してます。reflog様々ですね

>>584
なんで、そんな状態になるのか調べたほうが早くないか？

>>584
gitで新しいことをやろうとするまえに、bzrあたりでコミットしておけばいいんじゃね？

bzr-git使えばいいんじゃね？

最初からBazaarを使えばいいんじゃね？

賢い人は最初から分かってるよね。

C++の話（本当にあった怖い話）
http://www.slideshare.net/Isoparametric/c-horror-kai


中身はバージョン管理してないとかそういう話

>>590
SVNスレの方にはSVN使ってても先祖返りされたっていう実例もあるし、VSS以前の話じゃない？

>>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がネットワークドライブに確保するスペースの量は、控えめにいっても容認できる限界を超えている。
>
(続く)

> 　速度面でも深刻な問題がある。小さなプロジェクトでさえ数百のファイルの規模になり、
> 大きいプロジェクトにいたっては何十万ファイルにもなり得る。
> SourceSafeはデータファイルをリポジトリディレクトリ構造に格納するので、
> ファイルの開閉にかかるアクセス時間は極めて長く、プログラマは最新のファイルかどうかを
> チェックするだけでも果てしなく待たされることがある。
>
> 　SourceSafeはブランチをサポートしておらず（ブランチについてはあとで触れる）、
> 枝分かれさせたかったらツリー全体の完全なコピーを作らなければならない。お話にならない。
>
> 　SourceSafeにリモートでアクセスしようなどと思ってはならない。
> 何千ものファイルをのろのろしたインターネットを介して検索するなどもってのほか。
> T1回線でもダメだ。最終的にSourceSafeのファイルインデックスデータベースは動かなくなり、
> ちょっとした分析ユーティリティにも降参し、やり直しだといってくる。
> 私は以前、壊れたデータベースでプロジェクトを乗り切ったことがあるが、
> 壊れた部分の影響が、もはや必要のない古いバージョンのファイルだけにとどまっていた。不幸中の幸いだった。
>
> 　SourceSafeには自ら壊れる癖もある。リポジトリ全体を役立たずの不可解なファイルの山にする。
> これは特に、サウンド、テクスチャ、ビデオなどの大きなバイナリ資源を格納するときに起こる。
>
> 　まだSourceSafe以外のものを使おうという気になってなければ、こういいたい。
> よく調べてほしい。Microsoft自身が使わないという噂を耳にしたことがある。
> もちろん単なる噂にすぎないかもしれないが、他の選択肢も検討してみる余地はある。
>
> バージョン管理システムの紹介で、ダメだししか書いてないよー！

元ネタ
Amazon.co.jp： ゲームコーディング・コンプリート 一流になるためのゲームプログラミング: Mike Mcshaffry, 手島 孝人, 山下 恵美子, 依田 光江, 大貫 宏美, 廉 典子, 田中 幸, 宮本 寿代: 本
http://www.amazon.co.jp/dp/4797358432

悪い引用中のスペースが崩れた・・・

専ブラ用ポップアップおいとく >>592-593

Visual SourceSafeは、MS的にも既に終了したプロダクトだろ。
だから、MSDNのVS 2010からTeam Foundation Serverをただで使わせるようにしたんだし。

>>595
それって結局VSSをマシに作り直した的なものだったりしないのかな？

クラサバ方式になってる時点で全くの別物

その悪評高いVSSはクラサバじゃないのか？
クラサバじゃないのにどうやってリポジトリ共有するの？
p2pなのかな？

調べたらVSS6.0まではファイル共有で運用だったのかｗ
それが原因でファイル壊れるとかワロタ

とはいえ2000年頭のかなり昔の話だな。今はさすがにないだろ

調べるも何も、>592-593に書いてあるのに……
おまけに>595にも終了したって書いてあるのに……

MS codeplexはhg対応したみたいだけど、gitはどうするのかな？

オープンソースは悪だってずっと言ってたけど、変わるもんだねぇ

世界中の好きモンが、世界中のユーザーにあーだこーだ言われながら作っていくんだから
完成度はメーカー製の比じゃないと思うがね。

残念ながら Linux に関しては微妙なところだが。

codeplexもそうだけどgoogle codeもDVCSでhgしか対応していないんだよね。
bzrをさわるきっかけが無い理由の１つ。

bzr-hgはbzr-gitやbzr-svnに比べて遅れてたけど、今は使い物になるのかな？
bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。

お前らよくそんなに多種多様なVCS使えるな

>>605
Pythonがhgに移行する（した？）んだからbzr-hgが実用じゃないと困るんじゃないの？

ところで分散バージョン管理のpush/pullは、なんであんなに
システムごとに概念が違うんだ。

バージョン管理ごときに脳細胞1つも使いたくない
何、管理システム乱立させてんだよ。戦国時代ごっこか？
とっとと、これ使っておけばおｋって物だせよ
いつまで待たせんだよ

>>609
明らさまにそう言う人はあまり居ないが、大半はそうなんだろうな。
これっぽっちもドキュメント読まないで2chで質問してる人が多いもの。
ある意味インフラだからなー。

>>605
> bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
> 操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。

え、マジ？
それいいな

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

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

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

分散バージョン管理使ってみたら、もうもどれないな。
もちろん細かい不都合は多々あるんだがね。
Windowsとの連携とかマルチバイトがらみの話とか、マルチバイトとか、マルチバイトとか

>>611
>>588

>>612
あ、、、

確かに

bzrとhg同じpythonだから仲良く出来ないのかな？これじゃあ・・・
http://wiki.bazaar.canonical.com/BzrVsHg
http://mercurial.selenic.com/wiki/BzrVsHg

>>608
>ところで分散バージョン管理のpush/pullは、なんであんなに
>システムごとに概念が違うんだ。

後学のために詳しく説明してください。お願いします。

何で自分で調べないの？

脳細胞1つも使いたくないんでしょｗ

>>614
hgさんは、日本語ファイル名の対応に対する開発者のメール見て脱力したから
俺は仲良く出来ないなぁ。マルチバイト圏に対する考慮というか理解が欠けすぎ。
>>615
むしろ同じものを作りたくないから違って普通じゃ無いかと。
どこをチューニングするかって目的意識の違いで設計が変わっているっぽいね。

このスレ日本語ファイル名の対応に対する開発者のメール見て脱力した人よく見るよね

TOMOYO Linuxの人みたいにがんばって対応しないといけないんだろうな・・・

>>609
http://www.ericsink.com/entries/veracity_early.html

>>619
gitやhgしかなければそうなんだろうけど
...bzr

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

ガラパゴス恐怖症なのかもね。わからなくもないけど

>>605
bzr-gitとbzr-hgどっちもpushできないって書いてあったんだけど・・・

>>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が見えちゃうけど。

bzr-svnの一発目は軽いの？
git,hgともsvnクライアントとして使おうとすると最初のcloneが重くて。

>>624
bzr-svnも重い。こればかりはsvnプロトコルの問題だからなぁ…

オープンソースのプロジェクトなら、Launchpadでimportしてしばらく待っておけば
ミラーが出来上がるので、そこから作業始めれば楽。
社内利用なら、リポジトリのコピーをローカルに持ってきて、ネットワークを通さないで
bzr-svnを使うと速い。

Launchpadってユーザ作ってプロジェクト簡単に作れるの？
github, bitbucketみたいな勝手にforkとは文化が違うみたいなんだけど。

>>626
プロジェクトは簡単に作れるよ。
forkを作るときは、 lp:~ユーザー名/プロジェクト名/ブランチ名 という感じでブランチを作る。
プロジェクトを用意するまでもないときには、プロジェクト名のところに +junk って書けば
プロジェクトに属さないブランチを登録できる。

hgのここ重宝するんだけど、bzrもあったらうれしいな。
http://mercurial.selenic.com/wiki/GitConcepts

bzr ってやたら重くない?

>>629
別に？

Bazaar Explorer は何かと重い。

ちょっと大きなリポジトリを clone するとえらい待たされるような

煙草でも吸ってればいいと思う

なら自分は嫌煙厨なので煙草が必要なbzrは捨てだな

bzr の clone(branch) は tree を再構築するから多少遅いね
gitやhgはレポジトリ丸ごとコピーな分速い
分散型の宿命で clone は SVN の checkout と比べたら、どれも十分遅いけど
最初の1回だけだから、それほど気にならないな

hgのcloneは基本は丸ごとだけど、-r でリビジョン、1.5からは -b でブランチを指定してcloneが出来る。
firefoxやopenofficeみたいな弩級のリポジトリはタグを指定してcloneしてからpullをちまちまやった方が安全。
cloneは途中で失敗すると最初からやり直しだから。

openofficeでかいからbundle配布しているみたいだね。
http://wiki.services.openoffice.org/wiki/Mercurial/Getting_Started

>>636
その辺りはgitもbzrも同様だよ。
機能的にはどれも同じようなものが揃ってる。

遅いっていっても1時間とかかかるわけじゃないし、そんなに問題じゃないでしょ。

gitとhgは機能的に似たようなもんだけど、bzrはちょっと感覚が違うなぁ。

Inkscape を clone するときなんか多少どころの遅さじゃなかったなー。 > bzr

>>635
svnのcheckoutは.svnにコピーを作るから十分遅いでしょ。
hgのcloneは-Uオプションでファイルを展開しないというのもあるので、ある意味svnのcheckoutより速い。

bzrって昔は遅かったから、リポジトリフォーマットを新しいやつにして、bzrも2.0以降を使わないと
遅くなると思う。
今LaunchpadのInkscapeブランチを見たら、「An upgrade of this branch is in progress.」って
書いてあったから、もうすぐ新しいフォーマットが使われるようになると思う。

問題は、新しいフォーマットが実験的にサポートされたのが1.16からなのに対して、
Debian lennyでも標準のパッケージは1.15なんだよな。自分で新しいやつを入れないと
いけない。

>>642
履歴がかなり古いプロジェクトを除いたら、hg/git/bzrの方が速いよね。
gitは --depth っての使ったら履歴を途中から持ってこれるから、履歴の古い
プロジェクトでも強い。Bazaarにはまだ各種コマンドが履歴がちょん切れても
動くようにしている最中で、--depth機能は無い。

>>644
hgも履歴の途中のcloneのプランはあるんだけどね。
http://mercurial.selenic.com/wiki/ShallowClone
Google Summer of Codeでやんのか。

>>605
> bzr-hgはbzr-gitやbzr-svnに比べて遅れてたけど、今は使い物になるのかな？
> bzr-gitを使うと、UTF-8ファイル名を含むgitリポジトリに対してCygwinに頼らなくても
> 操作できるんだよね。bzr-hgが実用になれば同じことが言えるはず。
これって、EUC-JPやlatin1でもいけるってこと？

>>643
アップデートの多いアプリは、標準パッケージはほとんど使わないな。
古くて使ってられん。

最近の bzr は bzr log も速くなってるのかな?
Emacs のソースツリーで bzr log --limit=4 FILE とかやると 1 分以上待たされるw

>>643
lenny-backportsなら2.0.3だよ
http://packages.debian.org/search?keywords=bzr

>>647
Debianは特にリリース間隔長いからね…

>>614
設計方針からして違うんだから仲良く出来るはずがない。
bzrはクソすぎて理解できん。
GuidoがbzrよりMercurialの方がSubversionに近いと言っているのをBazaarMLで頭がおかしいと言っているのを見て
bzrがクソな理由がよく理解できた。

Bazaarの開発者もMercurialの開発者もPythonのコミュニティ内では仲良くしているよ。
>>650
先にMercurialを理解してしまったせいで、その先入観がBazaarの理解を妨げているんじゃない？
Bazaarはブランチをうまく管理できないユーザーにsvn coと同じチェックアウトを利用して
push/pull 無しに update/commit だけで作業することもできるし、
ブランチにURLが対応するのもSubversionと似てるよ。

Mercurialの場合Subversionでのブランチはこんなのを意味するんだけど
http://hg.mozilla.org/releases/mozilla-1.9.1/
http://hg.mozilla.org/releases/mozilla-1.9.2/

>>652
ブランチどころかリポジトリも別れちゃってるから、両方cloneしたら同じリビジョンを
2回ダウンロードする必要が発生しない？

>>653
それで何が問題？
容量のことなら、Mercurialの場合あまり気にしていないけど。
Mozillaの場合、CVS文化のままっぽいから名前付きブランチが付いていて例として良くないけど。

>>654
ディスク容量よりも、ダウンロード時間やネットワーク負荷の方が問題だな。

Mercurialのブランチのポリシー、こっちの方がいい。
http://mercurial.selenic.com/wiki/DeveloperRepos
開発者はcrewを持ってくるし、
一般ユーザで上のDebianの例じゃないけど少しでも早く安定版が使いたい人はstableを持ってくる。

>>653
マジで？　それってsvnと変わらなくないか。。。？

>>657
Mozillaの場合、マルチヘッドにもなっているっぽいのであんまり良い例じゃなかったね。
hgはgitのリモートブランチという概念も中央リポジトリという概念も無いから
別にネットワーク越しに同期する必要も無いし。

>>657
どうしても２回pullがいやっていうんなら、手持ちのリポジトリを合体させておけばいい。

>>628
あー、こういうのいいね。
同様なツールの他のものとの構造の比較みたいのってはっきりいって理解の妨げになりやすい
すごく助かるわ

よく参考書でも複数買って照らし合わせたら異なる角度で書かれていてわかりやすいみたいな現象

git の cloneメチャ早くてびっくりする。githubで大き目のプロジェクトcloneしても、やたら早い
Subversionをdisるだけはあるわｗ

圧縮して固めて一括転送してるのか？あれは

Bazzarは一番シンプルな動作の組み合わせで分散バージョン管理を実現してると思うがなあ。
単機能コマンドを組み合わせて複雑な目標を達成するunix的というか。

好きなの使えばいいじゃん。
git が流行ってる理由がよくわからんが。

>>615
・bzrのpush/pull
ブランチの履歴を全く同じ状態にする。
送り元のみがマージされていないチェンジセットを持った状態でないと実行できない。

こんな感じ？

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

について、誰か頼む

お前らコマンドラインで使ってますか？

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

>>662
> 単機能コマンドを組み合わせて複雑な目標を達成するunix的というか。

実装の話だけで言えばgitがそんな感じだぞｗ

>>665
gitはコマンドラインでの使い勝手がいいから、linuxならコマンドラインで十分いけるな。
diffの時にいちいち | less つけなくていいところとか他も見習ってほしい。

Subversionの場合はTortoiseつかわないとやってられない。
リモート操作の時とかやたらパスが長くなるのとか、コマンドラインで動作が遅いとイライラするし。
もちろんTortoiseSVNの出来がよくて安定してるからってのもあるけど。

>>667
でもログはgitkでみちゃう。

>>666
bzrはdebian/ubuntu的というのが敷居の高さを感じさせる

svnはTortoiseSVNが十分成熟してるからコマンドライン使わないな。
TortoiseBBR他のは日本語パスの扱いが微妙に怪しかったりするので
コマンドラインから使ってる。

>>664
・hgのpull/push
incoming/outgoingで確認した結果を実行する。
pushは送り先でマルチヘッドになる場合怒られるが強制的に作ることも可能。
TortoiseHgに「Push new branch」という新たなオプションが付いたので変わったかもしれない。

俺もgitでログみるときはgitkだな

--graphとかもっと見やすくならんの？
サブピクセルみたいにコンソールにもっと詰め込む技術の開発が必要

>>667
Windowsでもコンソールだけでいける。
msysgitのエクスプローラの右クリックでコンソールが立ち上がるのが凄い便利。

自社内もしくは個人レベルのプロジェクトなら好きなの使えるけど
常駐先とか、他社が入った場合は、難しいよなぁ。
話しあって決められる場合はまだいいけど、指定されている場合もあるし。

>>674
>>605

gitをコンソールだけで弄っている人に聞きたいんですけど、
履歴の把握はどうしてます？
ブランチとかたくさんあるとこんがらがったり、rebaseとかmergeするときに
コンソールだけだとわけわかんない・・・


そういや、msysgitってマルチバイト大丈夫になったんだっけ？

>>676
つ>>672

>>676
gitk --all

わるい、今はgitk --all使っているんだ

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


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

それがなければ、sshでターミナルでつなぐだけですむのに、と思って
ちょっとLinux経験あさいから、もっといい方法知っている人はぜひつっこみいれてほしい

>>676
仕事でgit-svn中心で使ってたからあんまり複雑な履歴は扱ってないな
MacだとGitXってクライアントがなかなか見やすかった。

>>676
git log --graph --oneline --decorate

>>681
ありがとう、見やすくなった。
ざっと見るだけならこれでいいか。

こんなのも試してみた。
formatの%dがgit 1.6は対応してないが。1.7だと行けたが
git log --graph --date=short --pretty=format:'%Cgreen%h%d %cd %Cred%cn %Creset%s'

Macでいいならgitxが便利。gitkとかクソ。

>>683
履歴の探索に関してはgitkもgitxも同じに見えるんだが…

>>684
ああごめん、大筋の機能は同じだけど、使いやすさと美しさではgitxの圧勝。しょうがないけど。

cygwinのgitkクソすぎる。不安定すぐ固まるし。

用途次第じゃね？

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

こんな使い方するほうが悪いんだろうけどさｗ

gitのレポジトリ構造にbzrのUIなら文句無いんだけどなぁ

レポジトリの中身はユーザが意識しなくてもいいのが正道だと思うが

SVNはリポジトリが手元に無くて理解しにくいと思うが

中身はユーザが意識しなくてもいいってのは誤解を呼びそうだな。
レポジトリのフォーマットは、ユーザが意識しなくてもいいってのが言いたいこと。

>>690
手元にないのが嫌ならローカルに作ればいいじゃない

msysgit と TortoiseGit 使ってるけど、日本語コミットログ絡みでmsysgitコマンドが
うまく動かない場合を除いて、たいていコマンドラインでやっちゃうようになった。

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

つーかgitとSearchIndexerとカスペの相性災厄。

searchindexerと相性っつーか関連があったのか
やたらgit使ってると重くなるときあるなあと思ってたけど
偶然じゃなかったってことか

msysGit の UTF-8ファイル名対応版を作りました。
一応、TortoiseGit からきちんとUTF-8ファイル名を扱えることを確認済み。
http://tmurakam.org/git/
本家にもパッチ送っておいたけど、取り込まれるかな、、、？

神じゃ
神が降臨なされた

hgのfixutf8の強力なライバル出現。
fixutf8の場合リポジトリ毎に有効にするかしないか選択できるんだけど。

素晴らしいね。早く分散バージョン管理御三家にもsvn並の
マルチバイト対応がされる日が来ることを祈るよ。

>>695
神キターｵﾜﾀ＼(＾o＾)／

わるい、ｵﾜﾀ の文字消し忘れた

ちょｗ　神は死んだｗｗｗｗ

終わっちゃったよ・・・

>>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は見てくれてるみたいのようだし

>>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が間違って起動されていることはないみたい

どうもありがとうございます。

TortoiseGit 側は文字列が ANSI で出力されてくることを期待しているので、UTF-8 を ANSI に
変換して出力するような修正をいれているんですが、ログが文字化けするということはまだ直しきれて
ない箇所が残っているようです。もう少しソースを追ってみないといけないかな。
gitk で文字化けするのも同じ理由のような気がします。

>>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に行った方がいいかも

githubのissueトラッカーでやったら？

>>707
最後まで読まずに書いちゃった。>>706　の最後に書いたあった。

modern-gitってのもgithubにあるね。
やはりMinGWでの日本語の扱いをどうにかするのが目的みたいで
C++で実装しなおしてるみたい。
どこまで実装できてるかはよく分からないんだけど（個人的にWindows使わないので）

>>709
mingw前提なので華麗にスルー

bzr-git/hg-gitで使っているpythonのdulwich使えないのかな？

バージョン管理システムってどこから入ればいいの？
何を学べばいいの？

>>712
まずはソースコードの変更履歴を失わない感動から学べばいいと思う
次に、変更者が常に追跡出来ることによる疑心暗鬼の解消、心の平穏を味わえば入門は終わり

>>712
http://mercurial.selenic.com/wiki/JapaneseTutorial

>>712
他人と共同作業して足踏みまくるとこから。

>>712
IBM Rational ClearCase か Microsoft Visual SourceSafe だな

>>712
RCS

>>716
あえて最初は地雷踏ませるのか。

>>712
まずはzipとかでソースを公開しているのにバージョン管理のリポジトリをさらさないソフトの作者を罵倒したり、
HDDが吹き飛びましたので開発中止します、というソフトの開発者をこけ下ろすブログエントリーを書いたり
するところから始めたらいいと思う

何かやりとげたい目標があったとき
(この場合は例えば「バージョン管理を使いこなして他のプログラマーよりも優位性を保ちたい」といったような)
まずは自分がその目標をすでに到達しているかのように振舞ったり想像してい行動することが重要

>>719
> >>712
> まずはzipとかでソースを公開しているのにバージョン管理のリポジトリをさらさないソフトの作者を罵倒したり、
> HDDが吹き飛びましたので開発中止します、というソフトの開発者をこけ下ろすブログエントリーを書いたり
> するところから始めたらいいと思う
>
具体例が分からんが、forkすればいいだけじゃないの？

は？

夏はネタにマジレスだよな(tameiki

>>712
vadm

>>720
cvs/svn import
git/hg commit --date

>>719
×こけ下ろす
○こき下ろす(扱き下ろす)
意味は、「しごいて」落とすことだ。つまり、おまいらが日夜やっていることだな。

落としてないよageてるよ！！！！！

マジレスすれば、TortoiseSVNでローカルレポジトリを作って
自分がよく変更するファイルを管理するとこからはじめるといい。

学んでるときに、それとは関係ない文字コードだとかの問題にひっかかったり、
コマンドライン叩くのはなかなか難しいものがある。普段からコマンドラインに
慣れ親しんでる人なら話は別だが。

TortoiseCVSすらあるのにTortoiseRCSは無いのかな？

>>728
rcsは分散バージョン管理のカレントパスにレポジトリを作る仕様によって完全に
その役目を後続に明け渡したと思う。

そろそろ休ませてあげてもいいんじゃないかな。

TortoiseGit

>>729
でもまだメンテされているみたいだね。
http://git.savannah.gnu.org/cgit/rcs.git/
git?!

>>727
なぜ分散型でなくTortoiseSVNでローカルレポジトリを作るのか理由を教えてください。

GitもHgも現状日本語ファイル名の扱いに問題を抱えてるからな

サーバのセッティングは後回しでいいじゃない

>>733
SVNは問題無いのですね？

>>733
ローカルで使う分には関係ないんじゃないの？

SVNのリポジトリを作ってチェックアウトしてtrunk,branches,tagsを追加するのは初心者向けだとは思えません。

>>733
但しWindowsに限る
なんじゃなかったっけ？

>>738
違います。ロケールに限るです。
Unixではja_JP.EUC-JP,ja_JP.UTF-8であれば問題なく動きます。

ロケールだと語弊があるので、
ファイルシステムのパスがバイト列かUnicodeかの違いと
そのAPI(fopen)の違いです。

ja_JP.EUC-JPとja_JP.UTF-8だろうが、それらの相互運用は
ファイルパスが(ry

結論：Windowsに限らずまだ無理

>>741
Windows上でコミットしたものもLinux上で展開できますが。
何がどう無理なのか具体的に教えていただけませんか？

>>742
俺の勘違いならスマン

EUC-JP環境でコミットしたマルチバイトのファイル名などを
UTF-8環境と相互運用できなくない？

できなくってよ

悪い、俺の勘違いだったみたいだ
Cygwinで試したが、LANGがja_JP.EUC-JPとja_JP.UTF-8だろうが相互運用できたわ

LANG=ja_JP.EUC-JPでも、UTF-8として扱われるんだな。
マルチバイトなファイル名入れてもUTF-8で記録されて問題なかった。
checkoutやUTF-8環境からのcloneも確認した

>>743
相互運用というのが何を意味するのか知りませんが、
コンソールの設定を変えれば、または、nkfを通せばファイル名は化けずに見えますよね？
化けるまでもなくファイルの実態は存在していますが。

>>746
相互運用というのは、ja_JP.EUC-JP環境からコミットしてpushしたものが、
ja_JP.UTF-8環境へcloneしてコミットしpushやpullして問題ない
2つの環境で中央の同じリポジトリ、もしくはお互いのリポジトリを介して開発する、ということを意図してました。

でもgitやhgでそれができないというのが勘違いだったのでもういいです、、、

>>746
svnやbzrなら、ファイル名がUnicodeで管理されてチェックアウト時にlocaleに合わせてエンコードされるから、
EUCな環境の人はEUCのファイル名になるし、UTF-8な環境の人はUTF-8のファイル名になる。

相互運用性うんぬんを話しているときは、何もしなくても文字化けしない、EUC-JPのファイル名とSJISの
ファイル名とUTF-8のファイル名がリポジトリ内に混在して存在してカオスなことにならない、ということを
言っているのであって、「バイト列としてはきちんと機能しているよ」という指摘は筋違い。

>>748
それじゃあMakefileみたいなのにファイル名が書かれていて
それがファイル名変換で機能しなくなっても問題ないってことなんだね？

>>749
それはmakeの問題だから、そもそもMakefileに書くようなファイルはASCIIファイル名にする。

>>748
ユニコードってそんな万能じゃないだろ。
特に開発環境で勝手にファイル名いじられるのは怖いから要らない。

>>748
仮にEUC-JPとUTF-8のファイル名がコミットで混在しても、分散型なんだから受け入れ拒否すれば良いし、
人間がやるのがいやだったらhookかませば良い。

>>751
同感。
bzrもunicodeに変換しないという機能があれば選択肢に入るんだけど。

bzrなリポジトリに〜(波線)入りのファイル名のファイルをWindowsから突っ込んでこいや

このスレ見て、WindowsでSubversion(TortoiseSVN)が猛勢ふるっているのもわかるような気がした

ユニコードは万能じゃなかったとしても、マシな解として受け入れられてるだろ。
EUC-JPのバイト列なんてWindowsじゃチェックアウトできないんだ。バイナリ透過型より
ユニコード型の方がクロスプラットフォームで動く確率が高い。

>>754
全く問題ないよ。bzrはWindowsでは基本的にWindowsのW系APIを使うから、cp932とUnicode間の
変換はされない。ネイティブにUnicodeで動く。

>>756
＞EUC-JPのバイト列なんてWindowsじゃチェックアウトできないんだ。
Cygwinとかでもダメなの？　リポジトリがUTF8なら大丈夫とか？

>動く確率が高い

確率で片付く話なのか？

>>756
Eclipseは？
あとDBとか。

>>756
UTF-8のファイル名を、ja_JP.EUC-JPでチェックアウトできるの？

>>756
> ユニコードは万能じゃなかったとしても、マシな解として受け入れられてるだろ。
誰が受け入れたのですか？

あほですか？

>>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に移行してファイル名やコミットログの文字化けなくなって喜んでる人がたくさんいると思うけど？

>>763
> DB？なにそれ？
VCSと連携するツールでパス名をDBに保存するものがあります。

>>763
> >>761
> CVSでSJIS版とかいろいろ改造版が溢れてよくリポジトリ内で文字化けが発生していたのが、
> Subversionに移行してファイル名やコミットログの文字化けなくなって喜んでる人がたくさんいると思うけど？
CVSからSVNを経由しないでgit/hgに移行したプロジェクトもあるけど？

>>763
> >>760
> UTF-8の環境の人は、UTF-8でデコードしたユニコードのファイル名をコミットして、
> EUC-JPの環境の人は、ユニコードファイル名をEUC-JPにエンコードしてチェックアウトする。
>
EUC-JPにないユニコードの文字を含むファイルはチェックアウトできないという認識で良いのですね？

>>766
その場合は、ユーザー側でLANG=ja_JP.UTF-8とかしてからsvn coしたら良いだろ。
それでも一つのリポジトリに複数のエンコーディングが混在するよりはマシ。

>>767
ユーザにデーモンは入りますか？

すごく不毛

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

バイト列で良いって言ってるヤツは、昔WinCVSの改造版とかの設定でハマって、
Subversion登場時に「これでやっとマトモに日本語が使える」って喜んだ経験が無いんだろうな。

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

>>770
クロスプラットフォームでトラブる文字は、バイト透過型の方が非ASCII全体だから多いぞ。
WindowsのようにUnicodeがベースのOSや、MacのようにUnicodeベースのファイルシステムが
存在する以上、Uniode対応は仕方ない。

>>771
> バイト列で良いって言ってるヤツは、昔WinCVSの改造版とかの設定でハマって、
> Subversion登場時に「これでやっとマトモに日本語が使える」って喜んだ経験が無いんだろうな。

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

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

>>771
そういう経験はないな。
Linuxは10年ぐらい前まではユニコードにちゃんと対応できてなくて
EUC-JPで暮らしてる人がほとんどだった。けどツール側のせいにすることは
なかったよ。Linuxが頑張ってUTF-8に対応した。今ではロケール切り替えでも
端末エミュレータでも主要なテキストエディタも様々な文字コードに対応
してるから、柔軟に使用できる。

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

「ユニコードだと動く確率が高い」とかあやふやな状態で履歴積み重ねるほうが不安だ。

>>771
> >>770
> クロスプラットフォームでトラブる文字は、バイト透過型の方が非ASCII全体だから多いぞ。
> WindowsのようにUnicodeがベースのOSや、MacのようにUnicodeベースのファイルシステムが
> 存在する以上、Uniode対応は仕方ない。

なるほど、全世界で圧倒的に使われているiso8859-1の既存資産を破棄しろと。

>>772
>> バイト列で良いって言ってるヤツは、昔WinCVSの改造版とかの設定でハマって、
>> Subversion登場時に「これでやっとマトモに日本語が使える」って喜んだ経験が無いんだろうな。
>
>これで喜んでいるのは、
>ログは英語で書くことが決まりだったり、Unix上に日本語ファイル名ファイルを上げることを
>禁止されていた経験が無いんだろうな。

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

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

いまはクロスプラットフォームの話をしてるんだよ？なんで特定環境で問題ないって話にするの？

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

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

>>774
Unicodeはiso8859-1の文字を含んでるんだから、普通に変換すればいいじゃん。

あーｗ cvsの文字化けなつかしい
結局、ごった煮だかのEUC版使っていた気がする


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


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

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

>>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の開発者？死ぬ

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

samba2、文字化け

何でもかんでもUTF-8で取り回すスクリプト言語
　↓
WindowsのコマンドプロンプトがUTF-8対応してなくて死ぬ
　↓
Cygwinなどの入出力がUTF-8対応のターミナルを使う
　↓
Cygwinのターミナルからだとネイティブアプリのコンソールアプリにまともに入力できない
（主にインタラクティブシェル系や選択を促す系）
　↓
コマンドプロンプトだと入力できるが、化けるのでUTF-8使えない
　↓
上に戻る


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

個別のアプリで対応して回る状況だし、Windows死ぬべきだと思う

>>776
> >>774
> Unicodeはiso8859-1の文字を含んでるんだから、普通に変換すればいいじゃん。
Makefile含め全部変換するの？凄いコストだね。

PowerShell じゃだめなの？

非ASCIIファイル名使うのって、ソースコードじゃなくて、○○画面遷移図.ppt とか、
○○仕様書.xsl とかが多いんじゃないかな？
Makefileの中に非ASCII文字を見たこと無いな。

>>783
それは日本人はSJIS/EUC-JP混在に慣れているから。
現在も変わらないのが悲しいけど。
Linuxのデフォルトutf-8ロケール化でやっと海外でも問題が認識されてきているんだから。

>>784
海外製のオープンソースアプリでも、Makefileの中に非ASCII文字が入ってるの見たことない。
Latin-1からUTF-8の変換って >>781 が思っているより簡単だと思う。

>>783
ぶっちゃけその通りで、非ASCIIのファイル名ってパワポとかワードとか
差分取れないようなファイルに付けるよね。
そういうのってフロント業務の人とかデザイナーの人とかが使うわけだから、
ソースコードとは別のリポジトリにして、そっち系の人が使いやすいTortoiseSVNとか
使ってもらえばいい。んでソースコードは開発者が使いやすい分散型。

日本語.datとか日本語.csvとか見て途方にくれたことは無い？

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

波ダッシュ
全角チルダ

>>788
それはcp932とUnicodeの変換テーブルの問題だよね？
WindowsはUnicodeネイティブだから、Unicodeファイル名をそのまま使えば変換要らないから問題なし。

>>789
EUC-JP環境は無視？
Linuxのutf-8でもトラブるけど。

>>775
> >商用UnixではSJISロケールがあったからCVSでも問題は無かったという経験は
> >無かったんだろうな。
>
> いまはクロスプラットフォームの話をしてるんだよ？なんで特定環境で問題ないって話にするの？

商用UnixにSJISロケールがあったから日本語Windowsと共有できた。
Linuxがglibc1の時代の話。
だからLinuxではSJISロケールが使えなかった時代の話。EUCでも半角カナに問題があった時代。

>>790
EUC-JP 環境の人は、問題があればUTF-8でチェックアウトしたらいいじゃん。
UTF-8で何がトラブルの？
バイト透過型にしたら、それらの文字がLinuxでもMacでもWindowsでも問題なく使えるの？

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


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

結局、Windowsの事も考量した場合、「入り口で変換」して中身をUnicodeに統一しておくか、
「出口で変換」するかの違いでしかない。
クロスプラットフォームの事を考えた場合、入り口で変換して中身を正規化する方がスジが
良いのはマトモなプログラマならわかるよな？

>>792
> >>790
> EUC-JP 環境の人は、問題があればUTF-8でチェックアウトしたらいいじゃん。
> UTF-8で何がトラブルの？

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

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

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

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

>>793
いまどきSJISが良いなんて本気で言ってるの？日本語以外どうすんだよ。
ロケールがSJIS対応したからと言って、SJISの0x5c問題が起こるアプリなんて
腐るほどあるだろうに。

>>794
苦情はMicrosoftへ

>>795
コマンドプロンプトはSJISだが、ファイルシステムは10年前からUnicodeだよ？

\をセパレータにしたこと言ってんじゃないの

>>780
＞Cygwinのターミナルからだとネイティブアプリのコンソールアプリにまともに入力できない
＞（主にインタラクティブシェル系や選択を促す系）
ネイティブアプリって、Windowsのコマンドプロンプト向けのアプリってこと？
これさえ解決できればUTF-8でいけるようになるってことかな。

しかし皆さんそんなに日本語のファイル名必須なの？
堅苦しい仕事のドキュメントなんかは日本語のファイル名付けそうだけど、
そっちだけsvnにすればいいのに。

＼をセパレーターにしたのは
／がコマンドオプションだったから
つまり
苦情は DigitalResearch (CP/M) へ
になるはず

>>798
そういうこと

コマンドプロンプトも
cp 65001
とかで UTF-8 対応になるんだけどバグが放置されてる

>>794
> いまどきSJISが良いなんて本気で言ってるの？日本語以外どうすんだよ。
だからLinuxではデフォルトutf-8ロケールがそれなりに受け入れられているんじゃん。
マトモなシステムであれば、
VCSで必須の過去の状態を復元するということすら保証されない
ファイル名がUnicodeに変換されるものなんてとてもじゃないが使えない。
でもファイル名がバイト列であれば、SJIS/EUC-JP/iso8859-1/UTF-8が共存できるじゃん。

>>801
>> いまどきSJISが良いなんて本気で言ってるの？日本語以外どうすんだよ。
> だからLinuxではデフォルトutf-8ロケールがそれなりに受け入れられているんじゃん。
なら、少なくとも新しいリポジトリに関しては、Unicodeに統一することでみんな幸せになるよね。

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


だってさ、2010年にもなって、MercurialやGitがいまだに0x5c問題とか、文字化け
とか抱えてるのって、Unicodeにしなかったからだぜ。

Unicode, Unicode ってなんとかの一つ覚えみたいに言ってるけど文字コードの話をしているのかエンコーディングの話をしているのかはっきりしてくれ.
utf-8 なんて立派な Unicode だし Unicode の数あるエンコーディングの中でも最も優れていると(個人的には)思うのだが.

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

utf-16 やら utf-32 やらゴミみたいなエンコーディングの話はしないでくれ.資源の無駄遣いだ.

パス名として0x5cが問題になるのはSJISと中国簡体字だよね。
それをまともに対応するのであれば、C,C++であればTCHARとかwidecharって話になる。
そのコストを誰が払うのか、誰がテストするのか、誰が問題にならない人に説得するのか、ということ。

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

日本語WindowsがCP932でありつづける限り、両者が交わることは無いでしょう。

昔、sambaサーバーがぶっ壊れた時にWindowsから作った日本語名のファイルが
Unixのコマンドラインからは文字化けしてツールがエラーはいてサルベージできず、
別のUnixマシンにつないでsamba経由でWindowsから恐る恐るコピーしてバックアップしたの思い出したｗ

今思うとdumpすればよかんたんじゃね？とか、LANGとかsambaの文字コードなんで気にしないで使ってたんだよと思うがｗ

>>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どうしてああなってんのｗ

>>804
これマジでなんとかならんもんかねえ

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



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

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

>>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選ぶと思うよ。

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

hgのfixutf8

Windowsの日本語ロケールがUTF-8になったらすべて解決

>>809
hgの拡張機能は、
Windowsの場合プロファイル直下のmercurial.ini、
Unix(cygwin)の場合~/.hgrcで設定すればグローバルで有効。
ここで有効にしなくても、各リポジトリの.hg/hgrcで
リポジトリ毎に有効にできる。

結局バイト透過型はWindowsサポートするにはUTF-8頼みなんだから、
最初からsvnやbzrみたいにUCS方式にしておけばよかったのに。

文字コード詳しくないけど、MercurialのデフォコードはUTF-8にしてしまえば
欧米の人たちにはほとんど影響が出ないで
あとは表示的な部分だけこっちに合わせればOKってなりそうだけどそんな簡単な話ではない？

>>813
UTF-8だとWindowsでいろいろうまくいかないんだってさ

ああ、Win日本語版だと
デフォ文字コードがSJISでW系API使ってもUTF-16か
既存の環境でも動かそうとしたら.hgで指定するぐらいしか方法なさそうだな。
でfixutf8で騙しながら使うと。

>>813
デフォルトは既存のものとの互換性の問題があるから議論があると思う。
どちらかというとインストーラの話。

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

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

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

fixutf8は本体には取り込まれていないので、自己責任。

前にMercurialのfixutf8教えてくれた人サンクス

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

>>817
ログはね、HGENCODINGという環境変数か、
--encoding というコマンドラインオプションがあるね。

質問させてください。

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

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

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

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

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

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

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

pdumpfsをファイルサーバーで動かして部分的に世代管理を導入する、というのも考えたのですが、
手軽に元の古いファイルにアクセスできるようにするためには、
必要なときのみバックアップをマウントしてなどの操作が必要だったり、
ちょっとした環境を作る必要性を感じてしまいます。

>>819
BunBackupとかで世代管理でもしてろ

>>819
中身はバイナリ・テキストどちらですか？

>>819
rsync --link-dest

>>823
VSS

>TortoiseSVNといえでもバージョン管理の知識が要求され

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

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

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

しかし、俺はTortoisegitって使ってないから分からんが、
Windows限定で使っても日本語とかで何か問題あるんですかね?
無いなら、亀git入れさせて「とにかくひと段落の度にコミットしろ、
そのとき変更概要コメントも書け」でもいいんじゃないの?

>>824
亀svnでも敷居が高いんじゃ、gitなんてムリでしょ。。。
利用者の習得コストを０にしたいのであれば、日付ディレクトリしかない。

rsyncの --link-destってのは、変更が無い場合ハードリンクを作るから容量の節約が出来る。
夜間JOBか何かで日付のディレクトリを作って、そっちをSambaなりの読み込み専用にすれば終わり。

DAVにしてサーバ側で定期的にコミットすれば、
ユーザー側からは単なるネットワークフォルダになるよ。

>>819
> 例えばgitだとその場でユーザーレベルでもリポジトリを簡単に作れますが、
> コマンドライン環境が主、マルチバイト絡みという点でプログラマー以外に使ってもらうのが困難です。

日本語が完璧に使えると宣伝されているbzrは？

>>819
現状Windowsで一番導入楽なのはTortoiseSVNだろうなぁ。
サーバ側はsvnserveにすればsshとか余計なこと考える必要はない。

導入が楽なのも、プログラマ以外が使いやすいのもVSSだろ

どのバージョン管理ツールも多少の知識が必要なのは同じ。
リモートで SSH の設定が面倒なのも同じ。
まあ SSH に関しては、接続ユーザーとキーを同じにして手順化してしまえば、
だいぶ簡単になる。

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

残念なことだが、バージョン管理ツールはプログラマにも敷居が高いからねぇ。

vssってなんの略なの?
Visual SourceSafe ?
Volume Shadow Copy Service ?

>>830
VSSは、そろそろサポート的な意味で導入が面倒になってくるような気がする。
http://www.microsoft.com/japan/msdn/vstudio/campaign/vsstotfs/
こんなページがあるくらいだし。

うちの場合一般的な業務用の文章ならGoogleDocs使ってもらうのが一番効果的でした。
結局コンフリクトの解消とかマージの仕組みまで理解をいただかないとどのバージョン管理ツール使っても共同編集は頓挫してしまいます。
親の分からんファイル持ってこられて、「マージしといて。バージョン管理できるんでしょ？」と言われるのがオチです。

>>834
それならwikiで十分という話になっちゃう。
wikiなら履歴も残るしdiff/blameもあるし。

WikiでVCS並みに履歴とっておいてくれるのってMediaWikiレベルじゃないとないんじゃね？

>>836
bitbucketのwikiがMercurialで管理されているのでcloneで持ってこれます。

trac

Redmine

自鯖で運用できるDropboxクローンがあればいいのにね

>>835
それが、「エクセルとワードの格好」をしていないと触っていただけないんです。
スプレッドシートで編集中の他人のカーソルが自分の窓で見えるというのが興味をひいたようでしたね。
個人的にはgitを使ってますが使う必要のある人間に使ってもらわないと始まらない、と痛感する事しきりです。

俺は bzr 使ってるけど、SCM 使えないアホと一緒にやってたときは、
そいつ用のブランチ作って「このフォルダで作業しろ」って渡してやって
コミット、マージは俺がやってたな。一人、二人だからそんなことできたけど。

>>841
ワードなんかWikiでも十分だと思うけど、ワード自身が履歴とdiff/blameを持っちゃっているしね。
エクセルも表計算ソフトとして使われていない場合がほとんどだし。

>833
Team Foundation Serverって、結構高いんだね。
2人で使うだけでも、
Team Foundation Server(380k) + Team Foundation Server CAL(\68k) * 2
+ Windows Server 2008R2 (\100k?)
で、60万円超かかるのか。

これで良いんじゃね？
3．シャドウ・コピーによるバックアップ
ttp://www.atmarkit.co.jp/fwin2k/vista_feature/06backup/06backup_04.html

>>844
ライセンスはよくわからないが、
2010からは、MSDN Professional 以上で入手できるのでだいぶ安くなると思うよ。

VSSとはいったいなんだったのか。。。
MSでも黒歴史扱い？

あれはビギナー (初心者) 向けのソフトだ。

違うよ。情弱向けのソフトだよ

VB5くらいの頃は十分使えたソフトだった。
Subversion他いろいろ選択肢のある今となっては使う意味がないってだけだ。

ACCESSのコードの修正の
差分をどうやって取ればいいのですか？
VSSならできるのに・・・

ある程度妥協点を用意したら、後は「仕事なんだから黙ってやれ。今求人すれば1日で集まるんだぞ？」で終わり
我侭言われただけでルールを運用できないシス管ほど無用な人間も居ない

>>852
諸刃の刀だな。

>>847
未だにバイナリを多く扱うデータの管理したいときは選択肢に入ると思うけど。
逆にバイナリ扱う人でVSSが選択肢に入らない人はいつも何を使っているか気になる
PerforceとかAlienbrain？

このスレにバイナリを扱ってる奴なんて居ない　が正解

>>855
このスレにはいないかもしれないけど、Subversionスレではバイナリはロックをかけるという話があった。

>>854
海外でMercurialからgitに移った人の理由でMercurialは差分で持っているからバイナリのでかいファイルが重いけど
gitは差分じゃないから速いというのがあった。
この対応か知らないけど、Mercurialではバイナリのでかいファイルを扱う拡張がいくつか開発されている。

>>856
Subversionを選択したときは、当然バイナリファイルにはロック使う訳なんだけど
Subversionの場合はコミットとロックが別になっているので、ヒューマンエラーが起こりやすいんだよね。
これがはなはだデザイナに評判が悪い。

>>857
一度比較的大きなプロジェクトでバイナリの転送速度がネックになったときに、
gitを検討してみたんですが、ファイルのロック機構にあたるものが見つからなくて断念しました。
本当はあるのかな？gitでバイナリを扱っている人に聞いてみたい。

MSの中の開発陣は、昔からVSS使ってないってね。
何使ってるんだろ

>>858
そもそもgitの場合、バイナリでロックかける必要あるのか？

>>860
バイナリのマージってできるのか？

>>851
Accessもバージョン管理できるよ
アドイン(アドオン?)でVSSにアクセスできるようになる
アドレスは忘れたけど、ググれば見つかる

>>858
バイナリファイルにはロックの意味が分からないんですが、
ロックってRCSのロックみたいなの？　てかSubversionってロックあったのか。

>>859
MSは自社のドッグフードを食べるんじゃなかったのかよ。
客にドッグフード勧めといて、自分たちはステーキを食ってたなんて。。。

>>858
分散バージョン管理にはロックという概念自体無いような

>864
そりゃ、VSSは少人数チーム専用の設計だから、MSが使わないのはしょうがない。

>>865
bzrも無いの？svnっぽいのが売りのようだけど。

Subversionに*.jar入れるのやめてくれ、って思うのだがそういうものなのか？

UI用のpngファイルとかは入れざるを得ないだろ。

>>868
ソースから生成されるものはバージョン管理に含める必要は無い。exeとかobjとか

ただし、リリース版の最終バイナリくらいは残したほうが便利だと思う。

>>870
Eclipseで簡単に開発環境が構築できるって、ダウンロードした*.jarを入れているのよ。

ダウンロード出来る.jarファイルが、いつまでダウンロード出来るかは
誰も保証してくれないからな。

>>871
じゃあ逆に聞くが、5年後にそのソースのビルドが必要になったらお前はどうするつもりだ？

>>871
まあリポジトリが膨れ上がらない限りはビルドに必要なものはまとめて入れておくのはありだろう。

jar入れるのをやめてほしい理由ってなんだろう

mavenでできることをsvnでやる理由が分からない。
ダウンロードできなくなるのも内側で別に保存しておけば良い。

無理に使うツールを増やすこと無いだろう。
チェックアウトひとつで完全なビルド環境が再現できるほうがメリットあるだろう。

なぜ突然mavenが出てきたのか理由が分からない。

>>860
バイナリマージのマージができないとなると、
ロックして作業中は他の人が作業出来ないようにするか
バイナリ作成者のお互いの意思疎通で解決するしかない気がするんですが、
必要ないんですか？

>>863
RCS使ったこと無いんですけど、ドキュメント読む範囲では同じようなことを実現するためにあると思います。
もしロックが必要な理由がわからないという質問だったら、上記の通りです。

>>879
バイナリで無くてもお互いの意思疎通は必要じゃないか？
テキストだってマージでコンフリクトするときはするんだから。

>>879
ワード、エクセルのような仕様書なのか、画像なのか、exe・pdfなどの成果物なのかで考え方が違うと思うけど。

>>868
悪い。*.objいれてたことある。*.oだったかも
*.objにコンパイルできなくてもリンクはできる環境だったんで、
コンパイル済みファイルも入れるのもよくやってたよ

ゲーム作ってたときは、中間生成ファイルはいれなかったがexeやdllは入れておいたな。

バグがでたときに特定のバージョンをチェックアウトしてすぐ動かせるようにしておくと
プログラマ以外でもテストやレポートできて便利だったんだよな

>>879
Git使ってるけど、バイナリファイル＝マージ出来ないファイル と思ってやってるな。

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

まあバイナリか否かといってもいろいろで、リッチUIなオフィススイートが
吐き出す構造化テキストなんかはテキストとは言いつつも差分出してもワケワカメで
マージ不能だったりするから、意味的にはバイナリみたいなものだね。

>>867
分散型の場合、特定のファイルを他人に扱わせない為には、そのレポジトリの
クローンやブランチ全てがロックしたことを知らねばならない。
そのような伝達は事実上不可能(オフラインの場合もあるから)

仮にそのような仕組みがあっても、ロックより先に別のローカルコミットされる
可能性もあるわけで、それがマージできないようなものなら、そのコミットを
破棄するしかないから、ロックが無い場合と変らない。

つまり、必要なのはツールよりもコミュ力、って事だな。

つまり情報伝達に無駄な手間がかかる欠陥システムって事だな
この場合は

>>887
その手の用途には専用のものを使えよ。VCSでタスク管理までやるほうがおかしい。

>>888
んなもん対応できるわけねぇだろタコスケが
もっと現実を認めろ

いや、最近のSCMの流行はタスク管理も含んでるだろ。
MSのTeam FoundationとかIBMのJAZZとか

>>890
どうしても一体にする必要があるのかね。
LaunchpadやTracみたいにVCS連携方式のほうが、いろいろ選べて便利。

>>891
そうか、便利で良かったな。
こっちも便利なんだよ。良いだろう。

このスレが「バージョン管理システム」ってなっているけど、SubversionとかはあくまでSCM。
つまりソース管理。
そこにバイナリを入れるのはやっぱり違うと思うけどな。
バージョン管理っていうとmavenやらruby gemsやらのビルド管理じゃないか。
HudsonやTrac/Redmineとの連携とかも。

？？？

tarボールとかって、何とか-x.y.z.tar.gzってなっているじゃん。

Linuxのバージョン管理システムはgitだそうでつね。

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

というか、リリースツールってどんなんがあるのでしょうか？

>>896
http://www.jp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.4.tar.bz2
Kernelならここから落とせますので自分でコンパイルして確かめてみてくださいｗ

>>896
make distが一般的だと思うけど、Linuxカーネルは分からない。

�d

あ、Linuxやそのカーネルが知りたいのじゃなくて、
できた実行モジュールをファイルコピーしたりする
リリース用ＧＵＩツールってあるのかなぁ、と。

Linuxのバージョン管理システムはgit、なんて書かれていたら
カーネルについて聞いていると思うのはしかたがない。

なんで？

>>899
また良くわからん質問だが、
rpmやdebやconfigure --prefix= のことを言っているのか？
それをGUIってことか？

gitはlinuxカーネルの版管理に使うために作られた、は真だが、
linuxでうごくもろもろのソフトウェアの開発においてgitを使う
義務はないから。

>>901
gitの歴史をwikipediaで読みましょう。

夏休みって終わったんじゃなかったのか？

>>902
いや、だから、リーナスがLinuxをmakeした後、
各サーバーにコピーするのは、
手じゃなくてツールでやってるのでは？
と。

そういうツールがあるなら欲しい。
gitはいつか使おうかと思ってるが、分散リポジトリまでまだ要らないし、、、

>>906
Linuxカーネルは知らないが、github/bitbucketはタグが付いたものはtarボールで自動で落とせる。

いや、ソースの落とし方じゃなくて、
配布ツール。。。

>>908
配布はディストリビューションのお仕事でしょ？

>>900
ただの文盲じゃん。はっきりリリースツールって書いてあるのに。

>>909
単一のバイナリを全世界でテストするため、リーナスが各サーバーに配布しなきゃならんでしょ？

>>911
単一のバイナリを全世界でテストするため、MSが(ry

> 単一のバイナリを全世界でテストするため

そんな、やってもいないことをやるためのツールを尋ねられても……

どこで聞きかじってきたのか知らないけど、なんかものすごい勘違いしてるねえ

ソースしか信じない人らにバイナリの事聞いても無駄無駄
環境も文化も違う

>>891
Team Foundationなんかは、ソースのチェックインにタスク上の問題に関連した制限がかけられる。
制限条件を通ってないとチェックイン出来ない。
制限の条件としてビルドが通ってるか？、バグが直ってるか等。
Jazzはチェックインされたソースを集めての定期ビルドのスケジューリング、直ったバグに対するリグレッションテスト等も管理できる
これからのSCMは単純なソース管理だけじゃなくて、こういう方向に向かうんじゃないかな

＞制限条件を通ってないとチェックイン出来ない。
＞制限の条件としてビルドが通ってるか？、バグが直ってるか等。
信じがたい話だが、こういうのを有り難がる人たちも居るんだね。。。

せっまい所の蛙ちゃんほどよく鳴く

その辺の機能はアホ避けだからなあ。
そもそもアホを参加させないで済むなら不要。

>>919
ケアミスしない神かお前は
そんな機械でも出来る心底下らん事に１ミリでも気を回す位なら他の生産的な事やるわ

そのうちにスペルチェッカまで搭載するようになるのか

オートコレクトって形でとっくに搭載されてるだろ
全部手打ちしてるなら無能としか言いようが無い

>>922
エディタとかじゃんくて、バージョン管理システムに搭載されてんの？
すげぇな

すまん>>921がそこまでブッ飛んだ発言だとは読み取れなかった

ビルド通貨してないとチェックインできないんなら、
ついでにスペルチェックもしてくれても良いかもね

>>917
余計なお世話だよな
チェックイン→テスト→幹にマージだよな。

俺が納得した時が納期だな世界の方々は悠長で居られてうらやましすなぁ。

>>916
> 制限条件を通ってないとチェックイン出来ない。
タスクの登録時に問題があるかどうかのテストケースがチェックインされていないとタスクが登録できない。

> 制限の条件としてビルドが通ってるか？、バグが直ってるか等。
単一バイナリでビルドが通るのが条件だから全世界のサーバに配布して
テストしないとチェックインできない。
32bit/64bit、Windows/Linux/Unixでビルドができないとチェックインできない。
外部要因もチェック要因だから、svn:externalsみたいなのを登録しないといけない。

>>928=>>896か…

イミフ

俺は916と896をネタにしたアンチMS()君だと思うけどな

問題は、このスレがSCMについて語るスレかどうかという点だ

>>932
Source Code Management
Software Configuration Management
どっち？

>>906
そういうのはスクリプト言語とかシェルでもいし、sshでも使えばいくらでもできそうなもんだけど

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

>>916
Hudsonとか継続的インテグレーションツールってそんな感じなんじゃないの？
使ったこと無いから実際はしらんけど

>>934
Hudson+Trac/Redmine+VCSみたいだけど

> 単一バイナリでビルドが通る

これが既にイミフだな。

>>933
Something Configuration Management

>>936
JAVA/CLR

pre-commit-hook とか書いてると
事前チェックは実際ありがたいよ。

今時チェックイン時に自動ビルド&自動テストが普通だろ。

あれ、WordだのExcelだののは差分表示出来るんでなかったっけ
画像とかが問題なのか

>>940
チェックインって、RCS、VSS以外に使っている？

>>942
subversion

"チェックアウトの取り消し"

皆さんレスどうもです。
>>881
画像・モデルデータ・モーションデータ等のリソースです。
これらをコンバートして実際に使用するデータに変換します。
そういう意味ではテキストではない（バイナリの)ソースとも言えるかもしれません。

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

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

やはりgit等の分散型が選択できないとすると、subversionのパフォーマンスで納得できないとなると
perforceなどの製品を使用するのが現実的な選択になるんでしょうか？

会社の方針とかもあるので一概には言えないというのを前提で。

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

コミュニケーションが必要なのはコミットする時点ではなくて、変更する前。
コミッターが的確に指示できるか、あるいは各開発者の意見集約ができるか。
大枠さえ、ちゃんとしてれば何時コミットするかは問題では無い。

ここは納期も関係ないし、バージョン管理上も実質2,3人しかコンフリクト起こしえないし
プロジェクトに関係するバイナリといえばアイコン画像程度な人らしか居ないよ。

有償製品を使った事がまず無いし、返ってくる答えは下らん理想論かVSS(笑)とかそのレベル。

ここはム板なんだから製品は板違いじゃない？

まったく同じ目的のものなのに
オープンソースは良くてプロプラは語っちゃ駄目な理由についてｋｗｓｋ

>>945
30人は無理かもしれないが、5×6人とかは無理？
分散型の利点は中央リポジトリも分散・階層化できることだと思うが。

お話になりませんな
現場を知らなさすぎ

現場なんか千差万別。
モジュール化もしていない現場なんかしらない。

まあなあ
ドキュメントですら、30人もが編集するようなファイルってないと思うんだがな
そんな現場は知らないでもいいや

ドキュメントもモジュール化していることを知らないということが分かった。
多分ドキュメントはワード・エクセルしかないと思っているのだろう。
LaTexとかいくらでもあるのに。

>>945
なぜロックしたいかと言うと、各自が平行して編集してしまった場合に
それぞれの作業内容がマージ出来ないようなファイルフォーマットだから
だと思うんだけど、そうやって同時編集が出来なくて作業が滞るよりは
ファイルをもっと細かく分割するか、分割出来ないのであればメンテナ担当を
決めて取りまとめしてもらうようにしたほうが効率が良いんじゃないかな。

分散型のVCSにロックを求めるのは無理だと思うので、排他制御は別途
プロジェクト管理ソフト（TracとかRedmineとか）でやるのが良いと思う。

ビジネスで、まともに運営されてて、ある程度規模が大きいプロジェクトであれば、
意思決定がトップダウンでやれるのと、
リポジトリ管理に加えて、変更要件の管理とかを合わせて構成管理として
それらを担任する専任の担当なり部署なりを用意する事が普通は認められるから、
そんなに大変ではないよな。

例えば、
あるベースラインがあって、それに対する要望やバグ報告に由来する変更要件の山があるとして、
それらに対して次のリリースまでに対応するものを決めて、個々の変更要件に対して
変更する必要のあるリソースを見積もらせて、
それを元に同じリソースを更新する変更要件は同じ担当者・チームにやらせたり、
優先度の低い変更要件を次のリリースに先送ったり、とかの交通整理がなされるから、
そもそリソース更新のコンフリクト自体がそんなに起きないしな。

ゲーム開発会社かはたまた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使っている人間には使いにくだろう

>>948
なんか頭悪い＆固い意見だな。
ムの品質に関わる製品もあるわけだ。
線引きは少々難しいが、板違いと言い切ってしまうのもどうかと思うぞ。

>>955
まあロックとまではいかなくとも、今誰が編集中か確認できるぐらいの
機能は欲しいとは思う。cvs の watch だかみたいな。分散では難しいかな。

>>957
つ TortoiseBzr

>>960
いや、TortoiseSVNと比較してるんだけど

subversionのリポジトリだけ貸してくれるレンタルサーバってないの？
サイトのHTMLデータとか外部の会社と共同作業するとき用に。
かといって、わざわざレンサバにsubversionインストールするのもめんどいし。

>>962
リポジトリだけなら探せばいくらでもありますよ。

>>962
「Subversion ホスティング」でぐぐれば望みの情報が出てくるでしょう

>>954
ワードとかエクセルもモジュール化出来ること知らないのか。

というかLaTeX言いたいだけだろ。
仕事であんなの使えねえよ。

LaTeXをおもちゃ呼ばわりする人がいると聞いて

仕事で設計書とコードの同期が問題になったときにliterate programmingで行くぜ！
ってなったときにlatexはドキュメントフォーマット用ツールとして使った.l
Windowsの世界だけで飯を食ってるとなんだそれ？って感じになるのもわかるけど。