バージョン管理システムについて語りましょう
●過去スレ
バージョン管理システムについて語るスレ
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/
バージョン管理システムについて語るスレ6
http://hibari.2ch.net/test/read.cgi/tech/1270640436/
バージョン管理システムについて語るスレ7
http://hibari.2ch.net/test/read.cgi/tech/1283780922/
バージョン管理システムについて語るスレ8
http://toro.2ch.net/test/read.cgi/tech/1295493964/
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
探検
バージョン管理システムについて語るスレ10
1デフォルトの名無しさん
2014/02/23(日) 18:17:11.032014/03/03(月) 20:00:03.17
svnはロック出来るのも利点だな
バイナリはマージ出来ない以上、コンフリクトは確実に回避する必要がある
バイナリはマージ出来ない以上、コンフリクトは確実に回避する必要がある
2014/03/04(火) 10:32:25.72
帳票のテンプレートならわかるけど
設計書にExcelってワロタ
設計書にExcelってワロタ
2014/03/04(火) 12:44:55.04
2014/03/04(火) 14:29:52.36
出たよバカ自慢
2014/03/04(火) 14:34:59.06
あるかないかは問題にしてないだろ
2014/03/04(火) 22:12:44.96
プロジェクト管理ソフトに続いて、今度は設計書作成ソフトの話題ですか。
で、実際何を使ってるよ?
うちはエクセル。
で、実際何を使ってるよ?
うちはエクセル。
2014/03/04(火) 23:30:30.62
2014/03/04(火) 23:31:58.91
プロジェクト管理に使ってるエクセルのファイルをバージョン管理してるって話?
2014/03/05(水) 00:41:08.63
周りでは、Excelで設計書もスケジュール管理もやる人が多い
これは会社が変わっても一緒
おそらく、だれでもそれなりに使えるから。
じゃないかな
効率は・・・・あまり良いとは言えないが、他に良いソフトもない
で、バージョン管理は使ってないから
・設計書.xls
・設計書_最新.xls
・設計書_20140304.xls
・設計書_修正前.xls
があふれている
これも、バージョン管理に入れれば良いかも知れないが
ファイルサーバで行うのが一番使いやすいので困っている
バージョン管理ソフトでなんか良い方法はないかな
これは会社が変わっても一緒
おそらく、だれでもそれなりに使えるから。
じゃないかな
効率は・・・・あまり良いとは言えないが、他に良いソフトもない
で、バージョン管理は使ってないから
・設計書.xls
・設計書_最新.xls
・設計書_20140304.xls
・設計書_修正前.xls
があふれている
これも、バージョン管理に入れれば良いかも知れないが
ファイルサーバで行うのが一番使いやすいので困っている
バージョン管理ソフトでなんか良い方法はないかな
100デフォルトの名無しさん
2014/03/05(水) 01:10:05.72 設計書Markup Language を作って、それで書いたものをバージョン管理に追加
実際に見るときは、TeX とかPDFとかに変換
実際に見るときは、TeX とかPDFとかに変換
101デフォルトの名無しさん
2014/03/05(水) 01:13:04.44 javadoc形式でコメント書くのもだが
wordでのhtml編集みたいにマークアップの記述なしで装飾でけたらいいのに
wordでのhtml編集みたいにマークアップの記述なしで装飾でけたらいいのに
102デフォルトの名無しさん
2014/03/05(水) 01:22:54.83103デフォルトの名無しさん
2014/03/05(水) 03:21:04.47104デフォルトの名無しさん
2014/03/05(水) 07:58:53.95 日本語ファイル名が化ける時点で話にならない
105デフォルトの名無しさん
2014/03/06(木) 06:49:43.95 一昨年にfixされてる
106デフォルトの名無しさん
2014/03/06(木) 19:17:26.24 実際、化けるよね
Macも混在してるとさらに
Macも混在してるとさらに
107デフォルトの名無しさん
2014/03/07(金) 00:57:23.74 最近職場でPerforce使いはじめたけど
ローカルでファイル消したらrevertできなくて嵌った
gitが気楽でええわ
バイナリデータ扱うとカスみたいに遅いsvnは放置で
ローカルでファイル消したらrevertできなくて嵌った
gitが気楽でええわ
バイナリデータ扱うとカスみたいに遅いsvnは放置で
108デフォルトの名無しさん
2014/03/07(金) 03:16:56.38 gitってバイナリデータ扱うのに一番向いてないだろう
109デフォルトの名無しさん
2014/03/07(金) 09:22:10.23110デフォルトの名無しさん
2014/03/07(金) 10:45:20.66111デフォルトの名無しさん
2014/03/07(金) 10:52:13.21112デフォルトの名無しさん
2014/03/07(金) 19:24:07.76 そういうサイズのバイナリを管理する必要があるプロジェクトってどんなものなんだ
113デフォルトの名無しさん
2014/03/07(金) 20:45:58.04 バージョン管理システムにバイナリファイルを管理させるのは役割チガイナノ叶う。正式版リリース時点の成果物一式(ソース、実行ファイル、ドキュメント、テスト仕様書)を完成図書として管理したいなと思って。
構成管理の仕組みの範疇かも。
構成管理の仕組みの範疇かも。
114デフォルトの名無しさん
2014/03/07(金) 22:19:16.42 >>107
Mercurial
Mercurial
115デフォルトの名無しさん
2014/03/08(土) 08:42:20.94 ゲーム作ってる所はsubversionが多いらしいね
116デフォルトの名無しさん
2014/03/08(土) 08:57:37.64 Gitって別のものへの移し替えが生じたときに面倒な事になりそう。
最近でいうとCVSからSVNへの移し替えとか。
まあGitがその地位を失うことが無ければそんな面倒な自体も無いだろうけどw
最近でいうとCVSからSVNへの移し替えとか。
まあGitがその地位を失うことが無ければそんな面倒な自体も無いだろうけどw
117デフォルトの名無しさん
2014/03/08(土) 09:47:56.38 え?
118デフォルトの名無しさん
2014/03/08(土) 12:43:58.69 svnとcvsしかつこうとらんけど、何使ってもバージョン管理ができりゃええのよ
前との差分、逆櫓、これな
前との差分、逆櫓、これな
119デフォルトの名無しさん
2014/03/08(土) 13:44:51.56 バージョン管理が出来るのは最低条件だろ。
今はどれだけ開発がし易いかが重要になってる。
今はどれだけ開発がし易いかが重要になってる。
120デフォルトの名無しさん
2014/03/08(土) 15:47:59.41 おまいらレスありがとうな
>>110
すまん語弊がありました
バイナリデータたくさんな環境なの(´・ω・`)
>>111
やっぱりPerforceなのかな…
ライセンス料の問題で気軽に導入できないのが辛いとこなんだよね
去年のCEDECでPixarが使ってると聞いて入れてみたら便利ではあった
でもオープンソースでなんとかしたい、Tortoise的環境がほしいってのがあるんだ
>>112
>>115がお察しの通りコンシューマのゲーム開発なんだ
アセット100GB越えがザラだから分割してgitリポジトリ作ってる
急ぎの仕事で悩んでるので助言はありがたい
gitがベストだとも思ってないよ
>>114
試してみる
>>110
すまん語弊がありました
バイナリデータたくさんな環境なの(´・ω・`)
>>111
やっぱりPerforceなのかな…
ライセンス料の問題で気軽に導入できないのが辛いとこなんだよね
去年のCEDECでPixarが使ってると聞いて入れてみたら便利ではあった
でもオープンソースでなんとかしたい、Tortoise的環境がほしいってのがあるんだ
>>112
>>115がお察しの通りコンシューマのゲーム開発なんだ
アセット100GB越えがザラだから分割してgitリポジトリ作ってる
急ぎの仕事で悩んでるので助言はありがたい
gitがベストだとも思ってないよ
>>114
試してみる
121デフォルトの名無しさん
2014/03/08(土) 16:02:27.74 ageちまったスマソorz
122デフォルトの名無しさん
2014/03/09(日) 02:41:21.23123デフォルトの名無しさん
2014/03/09(日) 13:33:51.72 現在プログラム板のID制導入の投票を実施中です
よろしくお願いします
プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/
よろしくお願いします
プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/
124デフォルトの名無しさん
2014/03/09(日) 15:58:10.80 >>122
ブランチの作成や切り替えが一瞬(長くても数秒レベル)で終わる。
特定のコミットだけを取ってこれる。
歴史を書き直せる。
bisect
最低限この機能は必要。
あと性能も重要。開発の快適さに直結するから。
ブランチの作成や切り替えが一瞬(長くても数秒レベル)で終わる。
特定のコミットだけを取ってこれる。
歴史を書き直せる。
bisect
最低限この機能は必要。
あと性能も重要。開発の快適さに直結するから。
125デフォルトの名無しさん
2014/03/09(日) 16:18:40.18 >>124
これまた見事な git 脳
これまた見事な git 脳
126デフォルトの名無しさん
2014/03/09(日) 16:24:44.21 >>125
git関係ないよ。
まずブランチの切り替え、速いほうがいいだろ?当たり前すぎる話。
特定のコミットを取ってこれるというのは、
そりゃ複数の機能を一人・多人数で開発していれば
その必要あるでしょ。作った順に必ずしもリリースするわけじゃ無いんだから。
歴史を書き直すのも、コミットした後でミスを見つけたとか普通にあるので
必須の機能。bisectはバグを見つけるのに便利。
gitの機能を言ってるんじゃないんだよ。
開発に必要な機能の話をしている。
git関係ないよ。
まずブランチの切り替え、速いほうがいいだろ?当たり前すぎる話。
特定のコミットを取ってこれるというのは、
そりゃ複数の機能を一人・多人数で開発していれば
その必要あるでしょ。作った順に必ずしもリリースするわけじゃ無いんだから。
歴史を書き直すのも、コミットした後でミスを見つけたとか普通にあるので
必須の機能。bisectはバグを見つけるのに便利。
gitの機能を言ってるんじゃないんだよ。
開発に必要な機能の話をしている。
127デフォルトの名無しさん
2014/03/09(日) 16:37:53.34 井の中の蛙乙
128デフォルトの名無しさん
2014/03/09(日) 16:40:32.29 だからブランチという用語は慎重に使えと……
129デフォルトの名無しさん
2014/03/09(日) 23:02:24.87 >>127
じゃあ、何か言えよw
じゃあ、何か言えよw
130デフォルトの名無しさん
2014/03/09(日) 23:17:13.95 bisect始めて知った
いつも手動で二分探索してたわ…
いつも手動で二分探索してたわ…
131デフォルトの名無しさん
2014/03/09(日) 23:28:28.71 >>129
例えばセキュリティ、ファイルロック、部分チェックアウトとか git が弱いところ書いてないだろ
例えばセキュリティ、ファイルロック、部分チェックアウトとか git が弱いところ書いてないだろ
132デフォルトの名無しさん
2014/03/09(日) 23:33:39.91 gitとは関係なしに
バージョン管理システムにおけるセキュリティの問題って何?
バージョン管理システムにおけるセキュリティの問題って何?
133デフォルトの名無しさん
2014/03/09(日) 23:49:30.33134デフォルトの名無しさん
2014/03/10(月) 00:07:57.53 >>133
そういう需要があるのは理解できるけど
フォルダ毎のアクセス制限を管理するのと
最初からリポジトリとかフォルダより上位のモジュールで分けて管理するのと
どっちが合理的かというと微妙な気が……
セキュアだけどまともに運用できるかという点で
SELinuxのそれと似た印象を受ける
そういう需要があるのは理解できるけど
フォルダ毎のアクセス制限を管理するのと
最初からリポジトリとかフォルダより上位のモジュールで分けて管理するのと
どっちが合理的かというと微妙な気が……
セキュアだけどまともに運用できるかという点で
SELinuxのそれと似た印象を受ける
135デフォルトの名無しさん
2014/03/10(月) 03:18:40.78136デフォルトの名無しさん
2014/03/10(月) 03:20:06.95 特定のディレクトリでプロジェクトが閉じてるのに、なんでその親ディレクトリがリポジトリになってんの。
VCSの機能不足より、むしろ管理者の機能不全を疑ってしまう。
VCSの機能不足より、むしろ管理者の機能不全を疑ってしまう。
137デフォルトの名無しさん
2014/03/10(月) 03:23:05.75 >>133
見せたくないのなら、渡さなければいいんじゃないの?
たとえば、ライブラリはソースコードではなく
コンパイルしてオブジェクトファイルとして渡せばいいでしょう?
コンパイルできない言語であれば、それはその言語の問題だけど。
それならそれでリポジトリには含めないでおいて、
動かす必要があるのなら、クライアントからアクセス出来ない
サーバー領域に置いておけばいい。もちろんそっちは別管理。
ようはソース非公開ライブラリと同じやり方だよ。
見せたくないのなら、渡さなければいいんじゃないの?
たとえば、ライブラリはソースコードではなく
コンパイルしてオブジェクトファイルとして渡せばいいでしょう?
コンパイルできない言語であれば、それはその言語の問題だけど。
それならそれでリポジトリには含めないでおいて、
動かす必要があるのなら、クライアントからアクセス出来ない
サーバー領域に置いておけばいい。もちろんそっちは別管理。
ようはソース非公開ライブラリと同じやり方だよ。
138デフォルトの名無しさん
2014/03/10(月) 03:24:16.69 クライアントに見せてはいけないものは
設定ファイルのパスワードレベルであれば、
それは元からリポジトリに含めてはいけない情報だしなぁ。
設定ファイルのパスワードレベルであれば、
それは元からリポジトリに含めてはいけない情報だしなぁ。
139デフォルトの名無しさん
2014/03/10(月) 06:08:27.66 >>134
> どっちが合理的かというと微妙な気が……
状況次第でしょ?
リポジトリ分ければいいじゃんとか言ってる奴いるけど、プロジェクトの一部が社外には出せないと言う状況で、全部を社内で開発してる時と外注さんに任せる時でリポジトリの構成変えるの?
> どっちが合理的かというと微妙な気が……
状況次第でしょ?
リポジトリ分ければいいじゃんとか言ってる奴いるけど、プロジェクトの一部が社外には出せないと言う状況で、全部を社内で開発してる時と外注さんに任せる時でリポジトリの構成変えるの?
140デフォルトの名無しさん
2014/03/10(月) 06:24:12.14 >>139
えとさ、どういうディレクトリ構成なのさ?
それ言ってくれんとわからん。
なんか、話を聞いていると、一つのディレクトリのあちこちに、
社内に公開できる部分、出来ない部分があってごちゃごちゃ
混ざってるように思えるんだけど?
もしそうだとしたら、それ人為的ミスで間違って
ファイルわたしてしまう可能性があるから修正した方がいいよ。
簡略化するとこういう感じ
root
├メインプロジェクト(自社開発)
└外注さんに任せるライブラリ
もしくは
root
├メインプロジェクト(外注さんと共同開発)
└自社専用ライブラリ
ライブラリ部分はgitで言えばsubmoduleという機能を使えばいい。
submoduleは外部のリポジトリを自分のリポジトリに埋め込む機能。
もちろん別々のリポジトリとして扱える。
submoduleはルート直下にしか置けない。
メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、
そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。
えとさ、どういうディレクトリ構成なのさ?
それ言ってくれんとわからん。
なんか、話を聞いていると、一つのディレクトリのあちこちに、
社内に公開できる部分、出来ない部分があってごちゃごちゃ
混ざってるように思えるんだけど?
もしそうだとしたら、それ人為的ミスで間違って
ファイルわたしてしまう可能性があるから修正した方がいいよ。
簡略化するとこういう感じ
root
├メインプロジェクト(自社開発)
└外注さんに任せるライブラリ
もしくは
root
├メインプロジェクト(外注さんと共同開発)
└自社専用ライブラリ
ライブラリ部分はgitで言えばsubmoduleという機能を使えばいい。
submoduleは外部のリポジトリを自分のリポジトリに埋め込む機能。
もちろん別々のリポジトリとして扱える。
submoduleはルート直下にしか置けない。
メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、
そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。
141140
2014/03/10(月) 06:36:10.29 なかなかいいサンプルが見つからないが、submoduleを使うとこういう感じになる。
https://github.com/bocon13/datacenter_mptcp (この人は俺とは無関係)
util @ 75d064d ってなってる所がサブモジュールで
クリックするとわかるように「外部のリポジトリ@コミット番号」に
紐付いている。
このutilディレクトリの中身は、この人から見れば
リンク先のファイルがそのまま有るように見える。
この人達が知り合いかどうかは知らないが、
ソースコード上はこうやって無関係のリポジトリを
取り込むことができている。
これと同じ仕組みを使えばいいだけだよ。
https://github.com/bocon13/datacenter_mptcp (この人は俺とは無関係)
util @ 75d064d ってなってる所がサブモジュールで
クリックするとわかるように「外部のリポジトリ@コミット番号」に
紐付いている。
このutilディレクトリの中身は、この人から見れば
リンク先のファイルがそのまま有るように見える。
この人達が知り合いかどうかは知らないが、
ソースコード上はこうやって無関係のリポジトリを
取り込むことができている。
これと同じ仕組みを使えばいいだけだよ。
142デフォルトの名無しさん
2014/03/10(月) 07:51:24.77143デフォルトの名無しさん
2014/03/10(月) 08:38:35.22144デフォルトの名無しさん
2014/03/10(月) 10:17:47.96 >>143
プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ?
理解できない?
派遣の外注さんに応援頼むんだけと、社外秘のソースとかとかお客さんとの契約でここは関係者以外には見せちゃダメとか、色々あるんだわ。
お前んとこでそんな状況になったこと無いから問題なしとか言うならいちいちでしゃばってくんなよ。
プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ?
理解できない?
派遣の外注さんに応援頼むんだけと、社外秘のソースとかとかお客さんとの契約でここは関係者以外には見せちゃダメとか、色々あるんだわ。
お前んとこでそんな状況になったこと無いから問題なしとか言うならいちいちでしゃばってくんなよ。
145デフォルトの名無しさん
2014/03/10(月) 10:33:11.63 >>144
いや、だから見せないならば、渡さなければいいじゃん
リポジトリを分けてサブモジュールで管理すればいい。
更新禁止は普通にメインリポジトリへのマージを制限すればいいだけ。
特定の人、グループの管理をするという発想は当然あって、
もちろん用意されている。gitで言えば、Git-サーバー-というのが
そういうことをしてくれる。
あんたの言ってることは、みな想定の範囲内の
すでに解決済みの話だよ。
いや、だから見せないならば、渡さなければいいじゃん
リポジトリを分けてサブモジュールで管理すればいい。
更新禁止は普通にメインリポジトリへのマージを制限すればいいだけ。
特定の人、グループの管理をするという発想は当然あって、
もちろん用意されている。gitで言えば、Git-サーバー-というのが
そういうことをしてくれる。
あんたの言ってることは、みな想定の範囲内の
すでに解決済みの話だよ。
146デフォルトの名無しさん
2014/03/10(月) 10:34:24.39147デフォルトの名無しさん
2014/03/10(月) 10:55:31.51 ま、Linuxのカーネル開発する人たちにはファイルロックも部分チェックアウトも不要な機能なんだろう
148デフォルトの名無しさん
2014/03/10(月) 10:56:10.55 >>145-146
○○すれば大丈夫とか言うなら、そりゃそうだとしか言えんわな...
プロジェクトの途中でリポジトリ分ければいいじゃんとか、正気かよ? とは思うが、git 脳だと当たり前なんだろうな (w
○○すれば大丈夫とか言うなら、そりゃそうだとしか言えんわな...
プロジェクトの途中でリポジトリ分ければいいじゃんとか、正気かよ? とは思うが、git 脳だと当たり前なんだろうな (w
149デフォルトの名無しさん
2014/03/10(月) 11:10:14.60150デフォルトの名無しさん
2014/03/10(月) 11:15:34.13 >>147
ロックの話をするならば、
楽観的ロックの悲観的ロック違いを知っているか?
これはどちらも「ロック」だ。
gitでは悲観的ロックではなく、楽観的ロックを
採用しているというだけのこと。
つまりコミットする時にチェックをする。
このメリットは、修正対象が小さいならば(マージできるならば)
ロックを掛けないほうが効率がいいから。
部分チェックアウトがなぜ必要になるのかは簡単で
ロック(悲観的ロック)があるからこその話。
つまりロックを掛けた時に他の人が修正できないという問題があると
認めているようなもの。gitでは全部チェックアウトしても何も問題起きない。
特定のリポジトリの権限管理についてはgitサーバーで使うとさっきも書いた。
ロックの話をするならば、
楽観的ロックの悲観的ロック違いを知っているか?
これはどちらも「ロック」だ。
gitでは悲観的ロックではなく、楽観的ロックを
採用しているというだけのこと。
つまりコミットする時にチェックをする。
このメリットは、修正対象が小さいならば(マージできるならば)
ロックを掛けないほうが効率がいいから。
部分チェックアウトがなぜ必要になるのかは簡単で
ロック(悲観的ロック)があるからこその話。
つまりロックを掛けた時に他の人が修正できないという問題があると
認めているようなもの。gitでは全部チェックアウトしても何も問題起きない。
特定のリポジトリの権限管理についてはgitサーバーで使うとさっきも書いた。
151デフォルトの名無しさん
2014/03/10(月) 11:17:54.85 技術力の差によってある種の壁ができてるんだと思う。
技術力が低い場合、もっと便利なものがあるのにそれを使えないで、
分かりやすく言えば、メールでファイルをやりとりするみたいなことしか出来ない。
普通に権限管理すればいいのに、許可されたファイルを渡して修正してもらうみたいな
無駄なワークフローをしている。
技術力が低いから、くだらない作業をしている。
そしてそれが最高の方法だと勘違いして、
もっといい方法を提示しても話を聞こうともしない。
技術力が低い場合、もっと便利なものがあるのにそれを使えないで、
分かりやすく言えば、メールでファイルをやりとりするみたいなことしか出来ない。
普通に権限管理すればいいのに、許可されたファイルを渡して修正してもらうみたいな
無駄なワークフローをしている。
技術力が低いから、くだらない作業をしている。
そしてそれが最高の方法だと勘違いして、
もっといい方法を提示しても話を聞こうともしない。
152デフォルトの名無しさん
2014/03/10(月) 11:30:04.99 結局、「日付のフォルダでいいじゃん」って事か
153デフォルトの名無しさん
2014/03/10(月) 11:38:45.89 まさか、gitに日付のフォルダで対抗してたの?
さすがに日付のフォルダじゃ使えなさすぎでしょw
さすがに日付のフォルダじゃ使えなさすぎでしょw
154デフォルトの名無しさん
2014/03/10(月) 11:49:36.89 一体どういう管理方法をしてるんだろうな。
gitの批判をする前に、具体的にどういった
やりとりをしているのか書いてほしいね。
まずは、ディレクトリ構造と
それをどうやってアクセス制限をかけているのかを
gitの批判をする前に、具体的にどういった
やりとりをしているのか書いてほしいね。
まずは、ディレクトリ構造と
それをどうやってアクセス制限をかけているのかを
155デフォルトの名無しさん
2014/03/10(月) 11:53:19.17 こんなんだろ?w
最新フォルダ
最新フォルダのコピー
○日のバックアップフォルダ
○日のバックアップフォルダ
○○さん、○○日納品分
○○さん、○○日納品分
最新フォルダ
最新フォルダのコピー
○日のバックアップフォルダ
○日のバックアップフォルダ
○○さん、○○日納品分
○○さん、○○日納品分
156デフォルトの名無しさん
2014/03/10(月) 11:54:40.35 たとえばCVSの日時指定チェックアウトでもbisectとか不可能じゃない。
だけど不可能じゃないからといって、なんでもかんでも人力でやるのは人力の無駄だわな。
省力化できることは省力化しなきゃ。
だけど不可能じゃないからといって、なんでもかんでも人力でやるのは人力の無駄だわな。
省力化できることは省力化しなきゃ。
157デフォルトの名無しさん
2014/03/10(月) 12:24:33.44 しかし、オープンソースの世界では、リポジトリにロックかける必要なんてないよな、普通。
必要ない機能は実装しないのが当然だとは思わないの?ossの外の人達がossの成果物を使う
のは勝手にどうぞ、としかいいようがないが、それで機能が足りないだの技術力がどうのと
文句いわれても、別にオープンソースの側は何とも思わないよねー。
だって必要ない機能なんだもん。
必要ない機能は実装しないのが当然だとは思わないの?ossの外の人達がossの成果物を使う
のは勝手にどうぞ、としかいいようがないが、それで機能が足りないだの技術力がどうのと
文句いわれても、別にオープンソースの側は何とも思わないよねー。
だって必要ない機能なんだもん。
158デフォルトの名無しさん
2014/03/10(月) 12:24:35.99 エクセルとかのバイナリファイルを編集する場合、ロックがないと致命的に扱いづらい
159デフォルトの名無しさん
2014/03/10(月) 12:31:16.96 オープンソース界隈の人たちは、エクセルとか使わない、で終了なんだが。
160デフォルトの名無しさん
2014/03/10(月) 12:40:31.63 営業やディレクターはgitなんか使わないでok
161デフォルトの名無しさん
2014/03/10(月) 12:42:00.21 RCSの経験で「俺たちにはいらねーわ」って結論が出てるわけだもんな。
162デフォルトの名無しさん
2014/03/10(月) 12:42:55.26 そんなにロック書けたいなら、共有ディレクトリをそのままgit管理したら?
gitだと普通のディレクトリを1コマンドでgitリポジトリできちゃう
別に他の場所を用意する必要もない。
今まで使っていたディレクトリがそのままバージョン管理できる。
もちろんこの使い方は通常のgitよりも柔軟性に欠ける。
だが通常のディレクトリよりも機能は上だ。
gitだと普通のディレクトリを1コマンドでgitリポジトリできちゃう
別に他の場所を用意する必要もない。
今まで使っていたディレクトリがそのままバージョン管理できる。
もちろんこの使い方は通常のgitよりも柔軟性に欠ける。
だが通常のディレクトリよりも機能は上だ。
163デフォルトの名無しさん
2014/03/10(月) 12:43:29.46 gitってなんでもできるんだなー。
164デフォルトの名無しさん
2014/03/10(月) 12:53:18.85165デフォルトの名無しさん
2014/03/10(月) 12:53:59.78 >>162
それやるなら、さらに--separate-git-dirを使うといいかも。
.gitディレクトリを別の所に作成できる。
つまりは、ディレクトリはほぼそのままで
(.gitディレクトリが書かれた.gitファイルができるだけ)
gitの管理下における。
それやるなら、さらに--separate-git-dirを使うといいかも。
.gitディレクトリを別の所に作成できる。
つまりは、ディレクトリはほぼそのままで
(.gitディレクトリが書かれた.gitファイルができるだけ)
gitの管理下における。
166デフォルトの名無しさん
2014/03/10(月) 12:54:57.53 >164
> 素直に、そんな機能は無いって言えばいいだけだと思うよ。
なんの機能の話してるの?
その機能をさっさといってよねw
> 素直に、そんな機能は無いって言えばいいだけだと思うよ。
なんの機能の話してるの?
その機能をさっさといってよねw
167デフォルトの名無しさん
2014/03/10(月) 12:55:32.05 今までの話でgitで出来ない機能なんて
一つも出てないなー
一つも出てないなー
168デフォルトの名無しさん
2014/03/10(月) 13:16:33.50 普通のディレクトリをそのままgit化できる時点で
ディレクトリ+αの機能になるしね。
ディレクトリでできることはgitでもできる。
ディレクトリ+αの機能になるしね。
ディレクトリでできることはgitでもできる。
169デフォルトの名無しさん
2014/03/10(月) 13:57:10.16 そんな面倒なことするよりsvnでロックかける方が便利だよ
170デフォルトの名無しさん
2014/03/10(月) 14:09:31.22 svnでロックかけるために、
リポジトリを別ディレクトリに作って
そこにチェックインしてとかやるの?
面倒くさい。
gitで管理するの必要なのはgit init。これ一つだけだよ。
そうするだけで、ただのディレクトリがgit管理ディレクトリになる。
リポジトリを別ディレクトリに作って
そこにチェックインしてとかやるの?
面倒くさい。
gitで管理するの必要なのはgit init。これ一つだけだよ。
そうするだけで、ただのディレクトリがgit管理ディレクトリになる。
171デフォルトの名無しさん
2014/03/10(月) 15:02:36.91 制限が必要ならgitoliteだかそんなのいくつかあるだろ
172デフォルトの名無しさん
2014/03/10(月) 15:12:46.90 >>150
釣りかマジかわからん...
> 部分チェックアウトがなぜ必要になるのかは簡単でロック(悲観的ロック)があるからこその話。
で、部分チェックアウトができる SVN のロック方式はどっちと思ってるんだ?
釣りかマジかわからん...
> 部分チェックアウトがなぜ必要になるのかは簡単でロック(悲観的ロック)があるからこその話。
で、部分チェックアウトができる SVN のロック方式はどっちと思ってるんだ?
173デフォルトの名無しさん
2014/03/10(月) 15:14:06.52174デフォルトの名無しさん
2014/03/10(月) 15:15:30.69175デフォルトの名無しさん
2014/03/10(月) 15:17:46.72176デフォルトの名無しさん
2014/03/10(月) 15:18:19.61177デフォルトの名無しさん
2014/03/10(月) 15:21:16.58 >>172
部分チェックアウトとロックには何も関係がない。
SVNは悲観的ロック(例えばチェックインを忘れたまま帰ってしまう人がいると、
そのファイルをほかの人が編集できずに作業が止まってしまうといったことがあり得る。
こうなると、開発者の待ち時間が増えてしまい、開発のスピードを遅くしやすいのだ。)
とgitと同じで優れている楽観的ロックの両方を持っている。
でも優れいている楽観的ロックがあれば
わざわざ劣った悲観的ロックを使う必要がない。
部分チェックアウトとロックには何も関係がない。
SVNは悲観的ロック(例えばチェックインを忘れたまま帰ってしまう人がいると、
そのファイルをほかの人が編集できずに作業が止まってしまうといったことがあり得る。
こうなると、開発者の待ち時間が増えてしまい、開発のスピードを遅くしやすいのだ。)
とgitと同じで優れている楽観的ロックの両方を持っている。
でも優れいている楽観的ロックがあれば
わざわざ劣った悲観的ロックを使う必要がない。
178デフォルトの名無しさん
2014/03/10(月) 15:25:06.58 >>171
> gitolite
ブランチをうまく使えばいいかと思ったけど、見せないって言うのは無理なんだな。
まあ各自がリポジトリ自体を持ってしまう git だと難しいし、そもそも OSS だと必要性は薄いからなぁ。
> gitolite
ブランチをうまく使えばいいかと思ったけど、見せないって言うのは無理なんだな。
まあ各自がリポジトリ自体を持ってしまう git だと難しいし、そもそも OSS だと必要性は薄いからなぁ。
179デフォルトの名無しさん
2014/03/10(月) 15:26:38.21 >>178
話し聞いてる?
gitは普通のディレクトリをそのままgit管理できるの。
だからそのサブディレクトリ単位で公開非公開も設定できる。
このやり方はgitをちゃんと使ったやり方よりも劣るが、
単なるディレクトリよりはマシ。
なんどでも言うよ?
話し聞いてる?
gitは普通のディレクトリをそのままgit管理できるの。
だからそのサブディレクトリ単位で公開非公開も設定できる。
このやり方はgitをちゃんと使ったやり方よりも劣るが、
単なるディレクトリよりはマシ。
なんどでも言うよ?
180デフォルトの名無しさん
2014/03/10(月) 15:27:28.08181デフォルトの名無しさん
2014/03/10(月) 15:27:33.91 ブランチを使うという発想自体が
すでに間違ってるよね。
道具を間違った使い方をして
使いにくいと言っているだけ。
こういうのも「技術力」だからね。
すでに間違ってるよね。
道具を間違った使い方をして
使いにくいと言っているだけ。
こういうのも「技術力」だからね。
182デフォルトの名無しさん
2014/03/10(月) 15:29:55.85 >>180
リポジトリを分ければもっと柔軟に管理できる。
だけど、分けなくても出来ないことはない。
gitのリポジトリはただのディレクトリ上位互換。
ディレクトリでできることは全部gitリポジトリで出来る。
それはちゃんとgitを使ったやり方より劣ったやり方だけど
ただのディレクトリよりは優れている。
まあ、君の技術が追いつくまではこれ使っていればいいんじゃない?
俺からすれば不便だけどさ。あれもできないこれもできない。
リポジトリを分ければもっと柔軟に管理できる。
だけど、分けなくても出来ないことはない。
gitのリポジトリはただのディレクトリ上位互換。
ディレクトリでできることは全部gitリポジトリで出来る。
それはちゃんとgitを使ったやり方より劣ったやり方だけど
ただのディレクトリよりは優れている。
まあ、君の技術が追いつくまではこれ使っていればいいんじゃない?
俺からすれば不便だけどさ。あれもできないこれもできない。
183デフォルトの名無しさん
2014/03/10(月) 15:32:57.11184デフォルトの名無しさん
2014/03/10(月) 15:35:31.69 ロックを他人が勝手に外したら
意味ないだろw
取っていいですかーってわざわざ電話するのか?
外す前に許可とるのか?
とらないで作業続けられないのか?
ロックを他人が外すのは緊急用だろ。
そういう無駄なコミュニケーションが
開発速度を落とす。
意味ないだろw
取っていいですかーってわざわざ電話するのか?
外す前に許可とるのか?
とらないで作業続けられないのか?
ロックを他人が外すのは緊急用だろ。
そういう無駄なコミュニケーションが
開発速度を落とす。
185デフォルトの名無しさん
2014/03/10(月) 15:36:21.04186デフォルトの名無しさん
2014/03/10(月) 15:36:51.11 Mercurialには、hglockエクステンションが有って、Subversionに近いロックが出来る。
187デフォルトの名無しさん
2014/03/10(月) 15:39:45.39188デフォルトの名無しさん
2014/03/10(月) 15:43:36.98 >>184
> 取っていいですかーってわざわざ電話するのか?
そうだよ。
コミュニケーションのためって書いたでしょ?
> ロックを他人が外すのは緊急用だろ。
それなら、管理者コマンドになってるはず。
> そういう無駄なコミュニケーションが開発速度を落とす。
君にはそう思えるんだろうね。
> 取っていいですかーってわざわざ電話するのか?
そうだよ。
コミュニケーションのためって書いたでしょ?
> ロックを他人が外すのは緊急用だろ。
それなら、管理者コマンドになってるはず。
> そういう無駄なコミュニケーションが開発速度を落とす。
君にはそう思えるんだろうね。
189デフォルトの名無しさん
2014/03/10(月) 15:49:23.47 >>185
ん?
自分がなに書いたのかわかってる?
> 部分チェックアウトがなぜ必要になるのかは簡単でロック(悲観的ロック)があるからこその話。
> 部分チェックアウトとロックには何も関係がない。
まさか、本人とはね (w
ん?
自分がなに書いたのかわかってる?
> 部分チェックアウトがなぜ必要になるのかは簡単でロック(悲観的ロック)があるからこその話。
> 部分チェックアウトとロックには何も関係がない。
まさか、本人とはね (w
190デフォルトの名無しさん
2014/03/10(月) 16:23:13.92 誰か、bzr-gitとかsvn-gitの乗り換えチャートでも作ってくれたりしないもんかな。
191デフォルトの名無しさん
2014/03/10(月) 17:16:41.02 bzrなんか誰が使ってんの?w
レスを投稿する
ニュース
- 【中国外務省】日中関係悪化は高市氏に責任と名指しで非難… ★5 [BFU★]
- 【インバウンド】中国からの“渡航自粛”…ツアー1000人分の直前キャンセル「キャンセル料は免除してくれ」 ことしいっぱいキャンセルに [1ゲットロボ★]
- XやChatGPTで広範囲の通信障害 投稿や閲覧できず [蚤の市★]
- 「国民の憤りを引き起こした」中国側“高市首相発言の撤回改めて要求” [どどん★]
- 【サッカー】日本代表、ボリビアに3発快勝 森保監督通算100試合目を飾る…鎌田、町野、中村がゴール [久太郎★]
- 【ローソン】ロゴの「L」で誤解生んだコーヒーカップ、デザイン変更へ 在庫使い切る3か月後にリニューアル [ぐれ★]
- 【悲報】SANA、発言撤回拒否 [769931615]
- 岡田克也「軽々しく存立危機事態とか言うべきじゃない」高市早苗「台湾で武力攻撃が発生したらどう考えても日本の存立危機事態」 [931948549]
- 米シンクタンク「アメリカは台湾問題で"あいまい戦略"を取っている。高市早苗はこの方針から逸脱している」 [603416639]
- ジャーナリストがテレビで解説「台湾問題は高市総理から言ったのではなく、立憲民主が日本の対応可能能力を暴こうとしたから」 [359572271]
- 俺性格悪いなって思った瞬間あげてけ
- 船井「ククク…♥残念やけどカイジさんはこれで別室行きや…♥」黒服「来いっ…♥」カイジ「やめろ!やめてくれっ…!」
