- 1 名前：デフォルトの名無しさん mailto:sage [2011/07/12(火) 01:53:58.45 ]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆前スレ
Git 2
hibari.2ch.net/test/read.cgi/tech/1284467898/
◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/
- 636 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 22:33:45.10 ]
- インデックスに登録するのは初めの一度だけで、あとはgit commit -all使えばいいだけなのに、
何をそんなに騒いでいるのか分からないなぁ。
- 637 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 23:26:44.54 ]
- >>627
いや、だから、何度も言うとおりコミットに査閲と承認が必要な環境があるんだよ
- 638 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 23:36:15.64 ]
- git使ったらコミットに査閲と承認が必要なくなるのかって。
それは運営方法の話だろ
バージョン管理システムの話してるんだけど馬鹿なの
- 639 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 23:55:06.16 ]
- TortoiseGitの1.7.5.0が出てた
もうバグが増えないといいな
- 640 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 23:55:17.27 ]
- チーム内のソース共有とかコードレビューの時にコミットが必要になるだろ
そんな時いちいち承認とかしてられないだろ
で、チーム内ローカルのリポジトリがあって、ひと通りのレビューが終わってから中央リポジトリにコミットすれば楽だろ
そういう時にチーム内ローカル→git 中央リポジトリ→svnだと管理が楽なんだよ
ローカルリポジトリをsvnにしてしまうと中央リポジトリへの反映が大変だし。
本当は中央リポジトリもgitにしてもらうか、承認を簡単にしてもらうほうがいいんだけど
中央は発注元だしあちらさんの社内文化を変えてもらう労力のが大変で、
gitの二重管理で自分たちだけ防衛したほうが工数少ないでしょうとかそんな色々な理由。
- 641 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 00:00:42.44 ]
- >>640
なるほど。参考になった。
- 642 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 01:48:49.24 ]
- Git していろ
- 643 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 04:26:03.72 ]
- SVN使いは、ビルド通らないソースをコミットするカスや
作業コピー以外で編集して他人のコミットを先祖返りさせるボケが
いるから嫌いなんだよな
ソース管理スキルに関していえば
Git使い＞＞＞（越えられない壁）＞＞＞SVN使い＞フォルダコピー使い
- 644 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 04:46:54.60 ]
- それだけ広く素人にも使われてるってことだろ
gitがsvnを超えて普及すれば同じ事言われるよ
- 645 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 08:33:26.23 ]
- >>644
もうgitはsvnを抜いているよ
qa.debian.org/popcon-graph.php?packages=bzr,cvs,darcs,git,git-core,mercurial,monotone,rcs,subversion&show_installed=on&want_legend=on&beenhere=1
- 646 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 09:37:15.15 ]
- 母数がDebianのパッケージマネージャって時点で、お前の言うカスやボケが含まれると思うか？
- 647 名前：デフォルトの名無しさん [2011/11/20(日) 09:42:36.39 ]
- DebianはUbuntuとの２重管理のうんこ
- 648 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 09:46:27.84 ]
- >>645
インストールされていることと、使われていることの区別も付かんのか。
- 649 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 09:50:10.31 ]
- >>648
gitはインストールされているけど、使われていない、使えないのですね。わかります。
- 650 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 09:50:54.45 ]
- >716 ：デフォルトの名無しさん [↓] ：2011/11/20(日) 08:53:00.84
>コミットA→コミットB→コミットC
>
>上のコミットBに間違えてfoo.txtをaddしてコミットしまって今すごい周りに迷惑かけちゃってまして
>なんとかfoo.txtを自分のローカルのsvnの管理対象から除外して
>新しいコミットDからはfoo.txtがなかったようにしたいのですが、
>この場合どうすればいいんでしょう。。
svnユーザーの現実
- 651 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 09:58:58.43 ]
- Ａ，Ｂ，Ｃで3重管理してるのがそもそもおかしい
- 652 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 10:08:38.68 ]
- >>639
それよりmsysgitのsvnが古いのを何とかしてほしい
svnが1.7で互換性をブチ切ったりしなけりゃ古いままでも問題なかったんだが
- 653 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 10:53:57.35 ]
- 無料RPG製作ツール「ロープレジェネレーター」
直感的操作で簡単なゲームが作れます。 簡単に配布可能な状態に出力する
ことができます。(HSP製のソースコード付きで、スクリプトの知識があれば
自由度の非常に高いカスタマイズができます）
他にも仲間預かり機能（100人も）や、仲間の状態/状態異常を細かく設定
できたり、乗り物が作れたり、ゲーム中に画像を差し込んだり、回転や
フラッシュなどのエフェクトなんかも簡単に作れる様です。
移動は矢印キーの他に、キャラがマウスを追っかけたりするとのこと。
戦闘はデフォだとドラクエ系。
・次期バージョンのロープレジェネレーター2.00アルファ版2を公開しました。(2011/10/29)
- 654 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 12:48:41.16 ]
- >>651
>Ａ，Ｂ，Ｃで3重管理してるのがそもそもおかしい
３重管理？
- 655 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 17:09:38.33 ]
- Gitで多重管理とかって何のこと指してんだろ
- 656 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 18:01:31.77 ]
- もはや多重管理言いたいだけちゃうんかと
- 657 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 19:00:05.40 ]
- そもそも分散リポジトリ使ってて、めんどくさいと感じたことなんかないんだが。
むしろ馬鹿が中央リポジトリにヘンなのコミットしても
自分とこだけは一時的に防衛できるので作業効率よくなった
- 658 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 19:15:59.00 ]
- うるせえ、「重管理」NGワードにすっぞ
- 659 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 19:16:42.95 ]
- あ、>>657に言ってるんじゃないので
- 660 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 19:24:18.13 ]
- >>658
してなかったのかよ、NGワード多重管理君。
もちろんもはやn重管理はネタだろ。
- 661 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 19:31:15.27 ]
- NGワード指定するほどレスないだろ、この板。
- 662 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 21:07:34.76 ]
- Linuxのカーネルとかだと100重管理ぐらいいってるかな?w
- 663 名前：デフォルトの名無しさん [2011/11/20(日) 21:46:50.54 ]
- >>662
９９重=苦渋苦渋管理
- 664 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 23:26:00.19 ]
- ぐしゅぐしゅ。
発狂しそうなパッチ・版多重管理をこなせたのがBKで
それの跡を継いだのがGitだろ?
ただ、CVS/SVNを経験してGitに慣れたヤツがSVNに戻れるか? と言われたら
例外なく戻れないだろう。反例求む。(SVN反Git厨は釣られないように)
- 665 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 00:34:15.31 ]
- 周りに合わせざるを得ないので svn はまだ使ってる
git svn は糞なので使えない
- 666 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 01:28:49.87 ]
- 戻れるかと言ったら普通に戻れるけど、利点はないな。
強いて言えば日本語の対応とか。
- 667 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 02:41:12.64 ]
- 戻るメリットっていったら、日本語ファイル名が正しく使えることくらいか
あとはWindowsで使うときにはSubversionのがすこし安定してる気がする
しかしそんだけのために戻る気はしないな
- 668 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 12:35:59.44 ]
- たすけてください
git commit -m "test"
で間違えてコミットしてしまったのを取り消したくて
git revert HEAD
としたのですが
取り消しを取り消したい場合はどうしたらいいのでしょうか？
git revert HEADの後ににファイルを編集したので
もう一度コミットするとおかしくなってしまいますのでたすけてください
- 669 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 12:42:59.04 ]
- とりあえずdiffとっといてgit reset --hardで、問題ないとこまで戻るとか
状況はわからんけど、やりようはいくらでもありそう
- 670 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 13:14:26.61 ]
- ProGitみたいな親切なドキュメントあるのに読まない奴ってなんなの？
- 671 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 13:26:31.67 ]
- 管理の仕方についてアドバイスお願いします
C:\sourcecode\python
C:\sourcecode\ruby
C:\sourcecode\perl
とあります
これら言語別にフォルダ分けがされており、フォルダの中にもまたプロジェクトごとにフォルダが分けられてます
C:\sourcecode\python\helloworld
C:\sourcecode\python\mywiki
C:\sourcecode\python\mycms
こういう場合リポジトリを作成する場合は
コマンドプロンプトでC:\sourcecodeをカレントディレクトリにしてgit initをするものでしょうか？
それとも書くプロジェクトごとにgit initをするものでしょうか？
- 672 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 13:48:26.47 ]
- >>668
git revert HEAD をもう一度。
という身も蓋もない回答は置いといて
git log とか git reflog して、戻したい場所を見つけたら
git reset (所望のsha1)
git reset が怖かったら
git checkout -b tekitouna_ichijitekina_branch (戻したいsha1) だ。
俺はこの手合いの作業は detached branch 上でやっちゃうけどなw
- 673 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 13:50:00.33 ]
- >>671
全部まとめてひとつのリポジトリにしてしまうのが、さしあたっての管理は楽。
git-submodule という機構もあるが、初心者が使うとぜったい事故る。
- 674 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 15:18:01.46 ]
- >>664
mergeしない・branchしないってわかってる用途限定ならsvnに戻れる
他に大きな理由がなければ戻りたくはないが
- 675 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 16:03:18.66 ]
- リモートリポジトリからファイルを取得するときに
git clone C:\test\. ってやってるんですが
ローカルのディレクトリに一つでもディレクトリやファイルがあるとエラーになるので毎回ローカル側のファイルやディレクトリ(.gitも含む)を消してからcloneを実行してます
こういうものなんですか？
- 676 名前：デフォルトの名無しさん [2011/11/21(月) 16:39:04.24 ]
- それfetchとかpullとかするところ。cloneは初回だけ。
- 677 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 16:42:47.68 ]
- >>675
そんなものではない。
git clone した後は、簡単な場合 git pull とか git fetch & git merge で済む。
(ついでにいうと pull とか fetch はそれなりに速い)
git clone C:\test\. って git clone (URL) C:\test\. の間違いだよな?
- 678 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 16:46:22.05 ]
- >>676
いろいろコマンドがあるんですね
ちょっとその単語で練習してみます
>>677
すいませんcdを載せ忘れました
本来は
cd C:\local
git clone C:\test\.
です
- 679 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 16:46:25.72 ]
- >>664
commit もしない、ローカルでの変更もしない、だったら戻れなくもないが俺何か道を間違えてるよな。
- 680 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 18:08:54.19 ]
- >>674
svnでbranchしたら二重管理になっちゃうだろ！
- 681 名前：デフォルトの名無しさん [2011/11/21(月) 18:15:31.26 ]
- >>680
svnにbranchはありません
- 682 名前：671 mailto:sage [2011/11/21(月) 22:19:49.69 ]
- >>673
間違えてへんなことして全部まとめて逝ったら困るので最初は分けて管理して見たいと思います
リモートリポジトリ (Dドライブ)
D:\sourcecode\python
D:\sourcecode\ruby
D:\sourcecode\perl
ローカルリポジトリ (Cドライブ)
C:\sourcecode\python
C:\sourcecode\ruby
C:\sourcecode\perl
MSDOS上からやったこと
cd D:\sourcecode\python
git --bare init
cd C:\sourcecode\python
git init
git add .
git commit -m "1"
git push D:\sourcecode\python master
git remote add origin D:\sourcecode\python
とやってpython用のを作りました,ruby用とperl用も同じようにして作りました
ここで疑問なんですが
git pushってやるとローカルリポジトリのデータがリモートリポジトリに反映されますが
これはgitを実行したカレントディレクトリを見て、どこにpushするか自動判別しているのでしょうか？
例えばpython用のところでgit pushってしたらperl用の所にpushされてしまうってことはございませんか？
- 683 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 23:24:53.83 ]
- git remote -v ってやってみろ
- 684 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 00:25:19.63 ]
- remote が remove に見えた。セフセフ。
- 685 名前：671 mailto:sage [2011/11/22(火) 11:31:56.18 ]
- あれ？pythonのフォルダでgit remote -vってやったら
origin D:\sourcecode\python (fetch)
origin D:\sourcecode\python (push)
って出ました
rubyとperlでもやったらちゃんと別々になりました
gitってどのカレントフォルダでコマンドを実行したかで自動でpush先を選択してくれるんですね！
今までバージョン管理って怖くていつもzipで全部固めてたんですが(サイズが832MBぐらい)
git使うとHDDの寿命も延びそうだし楽なのを覚えました
- 686 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 04:24:25.98 ]
- .git/objects以下ってコミットするごとにファイル増えていくと思うんだけど、
どの位まで性能でるの？
- 687 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:43:49.07 ]
- >>686
git gc
- 688 名前：デフォルトの名無しさん [2011/11/25(金) 22:19:44.08 ]
- 復帰
- 689 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 12:44:07.29 ]
- subversionからgitへ移行しています。
ちょっと解らないところがあるので教えてください。
webアプリを開発していて、開発用ブランチと本番環境用ブランチを作成して作業しています。
開発用ブランチに開発用のコード(DB設定やデバッグ用コード)を記述したとき、
subversionでは merge --record-only を使用してそのコードが本番環境にマージされない様にしていました。
git の場合はどのように処理すればいいのでしょうか？
今は本番環境にマージするときに --no-commit を指定して手作業で開発用コードを削除しているのですが、
本番環境から開発環境へマージするときに、今度は開発用コードが削除されます。
いい手があればアドバイスいただけませんか。
- 690 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 14:43:17.03 ]
- >>689
db設定やデバッグ用のエラー出力on/offとかは
アプリケーションの設計時に一つのiniファイルかなんかにまとめるようにしてignore
その他の実験用コードは開発用ブランチからのブランチで隔離実験ってのが基本じゃないですか？
- 691 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 14:53:42.70 ]
- >>689
Subversionの「マージ」という言葉を忘れよう。
あれはマージとは言わない。
Gitで言う所のcherry-pick。
Gitのスマートなマージが理解できたら、自然と運用ルールが定まるだろう。
- 692 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 20:03:39.46 ]
- >>689
環境設定はテンプレだけコミットしておいて実行環境に合わせて別のignoreするファイルに
追い出しておくのがいいと思う。それかコミットする環境設定ファイルは常に本番用に保って
おいて各自はデプロイで上書きするとか。
どこかの開発環境の設定でコミットとか、人によっては激怒するぜ。。。
あとsvnってmergeinfoとかいうのが出来たのか。svkみたいなもん？
- 693 名前：689 mailto:sage [2011/11/28(月) 17:01:46.95 ]
- アドバイスいただきありがとうございます。
subversionと同じような運営の仕方はできないのですね。
iniファイルの仕様変更とか入ったときに管理しやすいし、
設定項目が多い場合なんかは便利だったんですが。
> どこかの開発環境の設定でコミットとか、人によっては激怒するぜ。。。
ブランチ切って merge --record-only しておけば、
それを防ぎつつ設定ファイルまで管理できてたんです。
> あとsvnってmergeinfoとかいうのが出来たのか。svkみたいなもん？
svk見たいな外部ツールとは違い、標準で組み込まれた機能です。
マージしたときにどのリビジョンをマージしたかがプロパティに記録されるので、
次回マージするときにマージ済みの分は自動でスキップされます。
- 694 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 12:11:28.27 ]
- >>693
本番環境から開発環境へのマージはどういう変分を反映させることを期待しているのだろう？
- 695 名前：689 mailto:sage [2011/11/29(火) 17:48:42.12 ]
- >>694
開発環境でのテストでは問題なかったのに、
本番環境へ持っていったら動かなかった場合、
本番環境上で直接修正を行う場合があります。
あとは、客先の担当さんが直接変更を加える場合があるので、
それを取り込む場合があります。
その場合、本番ブランチに一旦コミット後、開発ブランチへマージ、
機能修正等を行ったあと本番ブランチにマージといった流れでやってます。
- 696 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 18:24:52.29 ]
- >>695
Gitスレで運用の話をしても満足する回答はないよ。総合スレ行ったら？
Git/Mercurial/BazaarはDAGだから、Subversionと同じ感覚だと違和感があるよ。
それこそ>>664のようにSubversionに戻れなくなるから。
- 697 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 23:36:55.67 ]
- なんかデスマテンプレートみたいな運用だな
確かに本番だけ動かん、というケースは存在するし、
結果的にぶっつけで本番直すことあるが、
根本的に手順が間違ってる。
スレチすまん。
- 698 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 23:38:41.40 ]
- ＞マージしたときにどのリビジョンをマージしたかがプロパティに記録されるので、
＞次回マージするときにマージ済みの分は自動でスキップされます。
いつの間にかsubversionのマージも進化してたんだな
俺が使ってた頃はリビジョン範囲指定しなければならなくて
使いづれーなっておもってた
調べてみたら各フォルダにsvnができるのも改善されたんだな
- 699 名前：デフォルトの名無しさん mailto:sage [2011/11/30(水) 00:25:39.28 ]
- >>693
開発ブランチから本番ブランチへは cherry-pick、
その後開発ブランチで本番をマージ。
もしくは開発ブランチでrebaseしてマージで持っていきたくない
履歴を先頭に追いやる。
てか何でろくにドキュメント読まずに移行しようとするんだ。
「svnのように」使いたいなら無理せずsvn使っとけば？
- 700 名前：デフォルトの名無しさん mailto:sage [2011/11/30(水) 01:31:03.11 ]
- >>695
>451のリリースブランチってのを参考にするとよい。
svnで本番ブランチに直接コミットすることが間違っているとは思うが。
- 701 名前：デフォルトの名無しさん mailto:sage [2011/12/02(金) 23:55:59.23 ]
- >>699,700
>451のモデルと合わせて考えれば
・開発ブランチからリリースブランチを作るときにcherry-pickでリリース対象のコミットだけ分離
・本番ブランチへリリースブランチをマージするときに開発ブランチへもマージ
で目的を果たせそうだな
一度除外したデバッグコミットは次のリリースからは含まれないし、デバッグコミットのログルールを決めておけば、cherry-pickも自動化出来そう
- 702 名前：デフォルトの名無しさん mailto:sage [2011/12/03(土) 02:41:56.10 ]
- >>701
ほんとにクソみたいなデバッグログは add -p で除外して stash に溜め込むか、
デバッグのコミットを一個作って rebase してる。
あんま激しくなってくると rebase でコンフリクトしちゃんだけどね。
- 703 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 04:42:14.03 ]
- 閑古鳥がないてますなあ
いまのバージョンでも十分安定してるし、機能不足も感じないから
話題がないか
- 704 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 04:55:30.66 ]
- 普通に使えてるし特に言うことないな
- 705 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 09:12:25.29 ]
- 外注先の奴らに使わせるには日本語がまともに使えることとGUIが必要だな
- 706 名前：デフォルトの名無しさん [2011/12/10(土) 09:57:42.87 ]
- >>705
日本の外注を使わなければ良いだけの話
- 707 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 10:10:42.81 ]
- SCM のために、慣れないなんちゃって英語でバグ作りこまれた上に
レビューもろくろくできなくなるなんて愚を犯す奴は馬鹿でしょ。
- 708 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 10:23:10.61 ]
- >>707
日本人のレビューアーが馬鹿なだけでしょ。
インド人は英語うまいよ。
- 709 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 10:38:03.77 ]
- ここは、日本で発注者も日本人だって客に言われたら、
SCM の都合でできませんって答えるのか？
馬鹿だろ。
- 710 名前：デフォルトの名無しさん [2011/12/10(土) 10:43:30.68 ]
- gitが使えない外注先が淘汰されるのに何が問題なわけ？
- 711 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 10:45:51.46 ]
- 問題の理解力もないところの人でしたか、それは失礼。
まあ、せいぜい git で遊んでてください。
- 712 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 10:46:56.91 ]
- 分散型普及の壁になっているのは外注より元締め。
開発者は今でもgit-svnとか使っている。
- 713 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 10:49:06.75 ]
- >>711
コミットログは日本語使えるし、GUIはEclipseとか揃っているし、
日本語が問題になるのはWindowsのファイル名だけでしょ。
これのどこが問題なわけ？
- 714 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 11:31:51.25 ]
- >>713
>日本語が問題になるのはWindowsのファイル名だけでしょ。
>これのどこが問題なわけ？
自分で「問題になるのは」って書いてて、「どこが問題？」って頭おかしいのか？
- 715 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 11:38:51.42 ]
- >>714
Windowsのファイル名が問題になるのだったら、それまでのプロジェクトが問題であって、
その問題を解決すれば問題にならない。
- 716 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 11:51:41.61 ]
- だからお客さんの都合だとどうしようもないだろって書いてるんだが、
やはり理解力が相当足りないみたいだな。
- 717 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 11:56:32.91 ]
- windows のファイル名に日本語が使えないと致命的に駄目
- 718 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 11:58:29.94 ]
- >>716
お客さんが日本語ファイル名ファイルをscmで管理するように要求しているのか？
ならば、そのファイル名ファイルだけ、日本語ファイル名で問題無いと思われているscmのままにしておけば良いじゃないか。
それ以外のところはgitに移行して何ら問題ないわけだ。
- 719 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 12:12:37.52 ]
- git のために、別々に管理しろって？
構成管理理解してない馬鹿のたわごとだな。
- 720 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 12:18:50.13 ]
- >>719
svnのように全部一ヶ所にまとめろって？
危機管理理解していない馬鹿のたわごとだな。
- 721 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 12:26:04.23 ]
- Bazaar の出番ですね。
- 722 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 12:39:21.56 ]
- そもそも受託開発なんて底辺仕事なんざ興味ねぇよ
底辺は勝手にやってろよ
- 723 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 12:43:04.80 ]
- 受託開発の底辺はsvnの一元管理で悶えて市ね
- 724 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 12:44:39.02 ]
- 多重管理地獄で悶えて氏ね
- 725 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 13:34:09.63 ]
- >>720
>危機管理理解していない馬鹿のたわごとだな。
別地保管も知らんのか...。
git だと分散だからと言ってバックアップもイラネーとか言い出したりしてな。(w
>>722-723
はいはい、こんな馬鹿なところじゃ受託すらできんわな。(w
- 726 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 13:41:07.33 ]
- >>725
危機管理＝バックアップだという認識なのか、おめでたいな
- 727 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 13:43:09.53 ]
- >>725
> 別地保管も知らんのか...。
svnで別置保管がどうすれば可能なのか教えてくれ
- 728 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 13:53:20.51 ]
- >>725
> git だと分散だからと言ってバックアップもイラネーとか言い出したりしてな。(w
hgだと要らないね。落ちた前スレで議論されている。
gitの場合、ブランチを消せるから全く要らないわけではないが。
- 729 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 14:18:52.99 ]
- >>726
>危機管理＝バックアップだという認識なのか、おめでたいな
じゃあどういう意味か書いてみな。
>>727
適当なデータセンタに電話して聞いてみればいいと思うよ。
うちは、支社があるから自社でやってるけど。
>>728
> hgだと要らないね。
まだ、こんなこと言ってるアホがいるのか...。
- 730 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 14:24:26.86 ]
- >>729
> >>726
> >危機管理＝バックアップだという認識なのか、おめでたいな
> じゃあどういう意味か書いてみな。
Linusがsvnを叩いた講演。
どこかの馬鹿が馬鹿なコミットをすることを防ぐこと。
> >>727
> 適当なデータセンタに電話して聞いてみればいいと思うよ。
> うちは、支社があるから自社でやってるけど。
svnだとデータセンタが必要なわけね。
分散型ならそんなの必要ない。
> >>728
> > hgだと要らないね。
> まだ、こんなこと言ってるアホがいるのか...。
アホはおまえだ。
hgは全リビジョン同期でリビジョンの削除はしないから、
同期されていれば、バックアップなど必要ない。
- 731 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 14:52:26.47 ]
- >>730
>どこかの馬鹿が馬鹿なコミットをすることを防ぐこと。
まともな運用もできていない組織だとツール側で必要なんだろうな。
>>727
>分散型ならそんなの必要ない。
結局複数サーバーで管理するってことだろ？
まさかとは思うが、ローカルにあるからいいジャンとか本気で言ってそうだな。
>>728
>同期されていれば、バックアップなど必要ない。
管理者のミスとか SCM 自体のバグとか考えたこともないんだろうな...。
素人乙。
- 732 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 15:03:19.66 ]
- >>731
> >>730
> >どこかの馬鹿が馬鹿なコミットをすることを防ぐこと。
>
> まともな運用もできていない組織だとツール側で必要なんだろうな。
外注先、オフサイトで馬鹿なコミットされるの防ぐために、
わざわざコードレビューしに出張するわけか。
高コストなこと。
> >>727
> >分散型ならそんなの必要ない。
>
> 結局複数サーバーで管理するってことだろ？
> まさかとは思うが、ローカルにあるからいいジャンとか本気で言ってそうだな。
分散型にサーバという概念はありませんが？
> >>728
> >同期されていれば、バックアップなど必要ない。
>
> 管理者のミスとか SCM 自体のバグとか考えたこともないんだろうな...。
> 素人乙。
gitにバグがあったらLinuxはこの世に存在していないけど。
分散型の管理者って誰？
git/hgはリポジトリフォーマットはほとんど変わっていないけど、
その論理だと、リポジトリフォーマットが頻繁に変わるsvn/bzrなんか使ってられないね。
- 733 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 15:21:41.82 ]
- >>732
>わざわざコードレビューしに出張するわけか。
TV会議システムもない職場乙。
>分散型にサーバという概念はありませんが？
まさかの方だったな。(w
>gitにバグがあったらLinuxはこの世に存在していないけど。
今までがよかったからこれからも大丈夫って言うわけね。
笑うしかないが。
>その論理だと、リポジトリフォーマットが頻繁に変わるsvn/bzrなんか使ってられないね。
意味不明。
- 734 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 15:33:01.54 ]
- >>733
> TV会議システムもない職場乙。
TV会議システムがないと品質も保証されない職場乙。
> >gitにバグがあったらLinuxはこの世に存在していないけど。
> 今までがよかったからこれからも大丈夫って言うわけね。
> 笑うしかないが。
大丈夫。
分散型を理解していないみたいだからこれ以上説明しても無駄みたいだけど。
それよりもsvnの将来心配したら？
> >その論理だと、リポジトリフォーマットが頻繁に変わるsvn/bzrなんか使ってられないね。
> 意味不明。
svnのbdbが壊れやすかったって知らないのね。
svn1.7でまた変わったんじゃないの？使ってないから知らないけど。
バージョンアップしたら過去のバックアップが使えないんだったら、
バックアップの意味ないけど。
- 735 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 15:46:48.50 ]
- >>734
>TV会議システムがないと品質も保証されない職場乙。
ひょっとして貧乏会社なの？
最近結構まともな奴が安いから入れたら？
>大丈夫。
それは、よかったな。
まあ、ビジネスに使ってないこと祈るよ。
>svnのbdbが壊れやすかったって知らないのね。
そうだね、壊れやすかったな。アホが使うと。
申し訳ないが、うちでは壊れたことはないよ。
そもそも今時 bdb なんて使ってないし。
>バージョンアップしたら過去のバックアップが使えないんだったら、
>バックアップの意味ないけど。
馬鹿は bdb は知ってるのに svndump には思いが至らないらしい。
まあ、よくいる中途半端な知ったかなんだろうな。
- 736 名前：デフォルトの名無しさん mailto:sage [2011/12/10(土) 15:52:43.55 ]
- >>735
> >>734
> >TV会議システムがないと品質も保証されない職場乙。
>
> ひょっとして貧乏会社なの？
> 最近結構まともな奴が安いから入れたら？
日本人は欧米とTV会議するため毎日夜勤ですか。
お疲れ様です。
>
> 馬鹿は bdb は知ってるのに svndump には思いが至らないらしい。
> まあ、よくいる中途半端な知ったかなんだろうな。
あなたのその理屈だと、そのsvndumpにバグがあったらどうするの？
svndumpが動いていると信じていたら実は取れていませんでした、
ってそれこそ管理者のミスを心配しないと。
|
 |
