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

1デフォルトの名無しさん
垢版 |
2014/02/23(日) 18:17:11.03
バージョン管理システムについて語りましょう

●過去スレ
バージョン管理システムについて語るスレ
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/
2014/03/10(月) 10:33:11.63
>>144
いや、だから見せないならば、渡さなければいいじゃん
リポジトリを分けてサブモジュールで管理すればいい。
更新禁止は普通にメインリポジトリへのマージを制限すればいいだけ。

特定の人、グループの管理をするという発想は当然あって、
もちろん用意されている。gitで言えば、Git-サーバー-というのが
そういうことをしてくれる。

あんたの言ってることは、みな想定の範囲内の
すでに解決済みの話だよ。
2014/03/10(月) 10:34:24.39
>>144
理解できてないんじゃなくて、
少なくともgitの世界では解決済みの話だって言ってるんだよ。
それを理解できてないのはあんたのほうでは？
2014/03/10(月) 10:55:31.51
ま、Linuxのカーネル開発する人たちにはファイルロックも部分チェックアウトも不要な機能なんだろう
2014/03/10(月) 10:56:10.55
>>145-146
○○すれば大丈夫とか言うなら、そりゃそうだとしか言えんわな...
プロジェクトの途中でリポジトリ分ければいいじゃんとか、正気かよ？ とは思うが、git 脳だと当たり前なんだろうな (w
2014/03/10(月) 11:10:14.60
>>148
お前、何も反論してないって自分で気づいてる？
「俺は違うと思う」と言ってるだけ。
2014/03/10(月) 11:15:34.13
>>147
ロックの話をするならば、
楽観的ロックの悲観的ロック違いを知っているか？
これはどちらも「ロック」だ。

gitでは悲観的ロックではなく、楽観的ロックを
採用しているというだけのこと。
つまりコミットする時にチェックをする。

このメリットは、修正対象が小さいならば（マージできるならば）
ロックを掛けないほうが効率がいいから。

部分チェックアウトがなぜ必要になるのかは簡単で
ロック（悲観的ロック）があるからこその話。
つまりロックを掛けた時に他の人が修正できないという問題があると
認めているようなもの。gitでは全部チェックアウトしても何も問題起きない。

特定のリポジトリの権限管理についてはgitサーバーで使うとさっきも書いた。
2014/03/10(月) 11:17:54.85
技術力の差によってある種の壁ができてるんだと思う。
技術力が低い場合、もっと便利なものがあるのにそれを使えないで、
分かりやすく言えば、メールでファイルをやりとりするみたいなことしか出来ない。
普通に権限管理すればいいのに、許可されたファイルを渡して修正してもらうみたいな
無駄なワークフローをしている。

技術力が低いから、くだらない作業をしている。
そしてそれが最高の方法だと勘違いして、
もっといい方法を提示しても話を聞こうともしない。
2014/03/10(月) 11:30:04.99
結局、「日付のフォルダでいいじゃん」って事か
2014/03/10(月) 11:38:45.89
まさか、gitに日付のフォルダで対抗してたの？
さすがに日付のフォルダじゃ使えなさすぎでしょｗ
2014/03/10(月) 11:49:36.89
一体どういう管理方法をしてるんだろうな。
gitの批判をする前に、具体的にどういった
やりとりをしているのか書いてほしいね。

まずは、ディレクトリ構造と
それをどうやってアクセス制限をかけているのかを
2014/03/10(月) 11:53:19.17
こんなんだろ？ｗ

最新フォルダ
最新フォルダのコピー
○日のバックアップフォルダ
○日のバックアップフォルダ

○○さん、○○日納品分
○○さん、○○日納品分
2014/03/10(月) 11:54:40.35
たとえばCVSの日時指定チェックアウトでもbisectとか不可能じゃない。

だけど不可能じゃないからといって、なんでもかんでも人力でやるのは人力の無駄だわな。
省力化できることは省力化しなきゃ。
2014/03/10(月) 12:24:33.44
しかし、オープンソースの世界では、リポジトリにロックかける必要なんてないよな、普通。
必要ない機能は実装しないのが当然だとは思わないの？ossの外の人達がossの成果物を使う
のは勝手にどうぞ、としかいいようがないが、それで機能が足りないだの技術力がどうのと
文句いわれても、別にオープンソースの側は何とも思わないよねー。
だって必要ない機能なんだもん。
2014/03/10(月) 12:24:35.99
エクセルとかのバイナリファイルを編集する場合、ロックがないと致命的に扱いづらい
2014/03/10(月) 12:31:16.96
オープンソース界隈の人たちは、エクセルとか使わない、で終了なんだが。
2014/03/10(月) 12:40:31.63
営業やディレクターはgitなんか使わないでok
2014/03/10(月) 12:42:00.21
RCSの経験で「俺たちにはいらねーわ」って結論が出てるわけだもんな。
2014/03/10(月) 12:42:55.26
そんなにロック書けたいなら、共有ディレクトリをそのままgit管理したら？
gitだと普通のディレクトリを1コマンドでgitリポジトリできちゃう
別に他の場所を用意する必要もない。
今まで使っていたディレクトリがそのままバージョン管理できる。

もちろんこの使い方は通常のgitよりも柔軟性に欠ける。
だが通常のディレクトリよりも機能は上だ。
2014/03/10(月) 12:43:29.46
gitってなんでもできるんだなー。
2014/03/10(月) 12:53:18.85
>>149
反論？
>>124 からの流れで別に反論なんてしてないが？
git でやりづらいこともあるでしょ？ って言ってるだけ。
別に git はそんなことを想定して作ってないだろうから当たり前なんだが、バージョン管理システムの機能の話してるのに git がー、git でわー、とか俺にはそんな必要ないからとか言われてもしょうがないでしょ？
素直に、そんな機能は無いって言えばいいだけだと思うよ。
2014/03/10(月) 12:53:59.78
>>162
それやるなら、さらに--separate-git-dirを使うといいかも。
.gitディレクトリを別の所に作成できる。

つまりは、ディレクトリはほぼそのままで
（.gitディレクトリが書かれた.gitファイルができるだけ）
gitの管理下における。
2014/03/10(月) 12:54:57.53
>164
> 素直に、そんな機能は無いって言えばいいだけだと思うよ。

なんの機能の話してるの？

その機能をさっさといってよねｗ
2014/03/10(月) 12:55:32.05
今までの話でgitで出来ない機能なんて
一つも出てないなー
2014/03/10(月) 13:16:33.50
普通のディレクトリをそのままgit化できる時点で
ディレクトリ＋αの機能になるしね。
ディレクトリでできることはgitでもできる。
2014/03/10(月) 13:57:10.16
そんな面倒なことするよりsvnでロックかける方が便利だよ
2014/03/10(月) 14:09:31.22
svnでロックかけるために、
リポジトリを別ディレクトリに作って
そこにチェックインしてとかやるの？
面倒くさい。

gitで管理するの必要なのはgit init。これ一つだけだよ。
そうするだけで、ただのディレクトリがgit管理ディレクトリになる。
171デフォルトの名無しさん
垢版 |
2014/03/10(月) 15:02:36.91
制限が必要ならgitoliteだかそんなのいくつかあるだろ
2014/03/10(月) 15:12:46.90
>>150
釣りかマジかわからん...

> 部分チェックアウトがなぜ必要になるのかは簡単でロック（悲観的ロック）があるからこその話。

で、部分チェックアウトができる SVN のロック方式はどっちと思ってるんだ？
2014/03/10(月) 15:14:06.52
>>154
>>144 みてわからないなら、諦めてくれ。
2014/03/10(月) 15:15:30.69
>>166-167
はいはい、git ってすごいなー

これでいい？(w
2014/03/10(月) 15:17:46.72
>>174
いや良くない。欲しいのは論理的な反論。
それ以外は負け犬の遠吠えにしか見えないから。
2014/03/10(月) 15:18:19.61
>>173

>>144なら普通にgitでもできるよ。
これで問題解決したよね。
2014/03/10(月) 15:21:16.58
>>172
部分チェックアウトとロックには何も関係がない。

SVNは悲観的ロック（例えばチェックインを忘れたまま帰ってしまう人がいると、
そのファイルをほかの人が編集できずに作業が止まってしまうといったことがあり得る。
こうなると、開発者の待ち時間が増えてしまい、開発のスピードを遅くしやすいのだ。）
とgitと同じで優れている楽観的ロックの両方を持っている。

でも優れいている楽観的ロックがあれば
わざわざ劣った悲観的ロックを使う必要がない。
2014/03/10(月) 15:25:06.58
>>171
> gitolite

ブランチをうまく使えばいいかと思ったけど、見せないって言うのは無理なんだな。
まあ各自がリポジトリ自体を持ってしまう git だと難しいし、そもそも OSS だと必要性は薄いからなぁ。
2014/03/10(月) 15:26:38.21
>>178
話し聞いてる？

gitは普通のディレクトリをそのままgit管理できるの。
だからそのサブディレクトリ単位で公開非公開も設定できる。

このやり方はgitをちゃんと使ったやり方よりも劣るが、
単なるディレクトリよりはマシ。

なんどでも言うよ？
2014/03/10(月) 15:27:28.08
>>176
見せないこともできるの？
リポジトリを分けることについては、>>148 の後半見てね。
2014/03/10(月) 15:27:33.91
ブランチを使うという発想自体が
すでに間違ってるよね。

道具を間違った使い方をして
使いにくいと言っているだけ。

こういうのも「技術力」だからね。
2014/03/10(月) 15:29:55.85
>>180
リポジトリを分ければもっと柔軟に管理できる。

だけど、分けなくても出来ないことはない。
gitのリポジトリはただのディレクトリ上位互換。
ディレクトリでできることは全部gitリポジトリで出来る。

それはちゃんとgitを使ったやり方より劣ったやり方だけど
ただのディレクトリよりは優れている。

まあ、君の技術が追いつくまではこれ使っていればいいんじゃない？
俺からすれば不便だけどさ。あれもできないこれもできない。
2014/03/10(月) 15:32:57.11
>>177
前半は >>150 にアンカーしてくれ。

> 悲観的ロックを使う必要がない。

これは、バイナリーファイル用だよ。
ちなみにロックは他人でもはずせる。
どちらかと言うと、編集してますよと言うコミュニケーションのためのフラグみたいなもんだよ。
2014/03/10(月) 15:35:31.69
ロックを他人が勝手に外したら
意味ないだろｗ

取っていいですかーってわざわざ電話するのか？

外す前に許可とるのか？
とらないで作業続けられないのか？

ロックを他人が外すのは緊急用だろ。

そういう無駄なコミュニケーションが
開発速度を落とす。
2014/03/10(月) 15:36:21.04
>>183
> 前半は >>150 にアンカーしてくれ。

意味不明。

なんで自分で自分にレスしないといけないのか。
お前に言ってるんだよ。
2014/03/10(月) 15:36:51.11
Mercurialには、hglockエクステンションが有って、Subversionに近いロックが出来る。
2014/03/10(月) 15:39:45.39
>>181
なら >>144 を実現するための正しい方法を書いてくれ。
今のところ >>140-141 ぐらいしかやり方出てないようだけど？

>>182
> ディレクトリでできることは全部gitリポジトリで出来る。

だから、ディレクトリは特定ディレクトリを見せないって言う設定できるよね？
git でどうやるの？
2014/03/10(月) 15:43:36.98
>>184
> 取っていいですかーってわざわざ電話するのか？

そうだよ。
コミュニケーションのためって書いたでしょ？

> ロックを他人が外すのは緊急用だろ。

それなら、管理者コマンドになってるはず。

> そういう無駄なコミュニケーションが開発速度を落とす。

君にはそう思えるんだろうね。
2014/03/10(月) 15:49:23.47
>>185
ん？
自分がなに書いたのかわかってる？

> 部分チェックアウトがなぜ必要になるのかは簡単でロック（悲観的ロック）があるからこその話。

> 部分チェックアウトとロックには何も関係がない。

まさか、本人とはね (w
2014/03/10(月) 16:23:13.92
誰か、bzr-gitとかsvn-gitの乗り換えチャートでも作ってくれたりしないもんかな。
2014/03/10(月) 17:16:41.02
bzrなんか誰が使ってんの？w
2014/03/10(月) 17:20:39.54
>>191
GNU信者でしょ
2014/03/10(月) 17:21:18.71
>>187
> だから、ディレクトリは特定ディレクトリを見せないって言う設定できるよね？
> git でどうやるの？

お前根本的な所がわかってないじゃないか。
gitでもディレクトリ使ってるんだよ。
gitはディレクトリ＋αと考えればいい。
だからディレクトリでできることは全てgit使っていても出来る。
2014/03/10(月) 17:23:34.52
たぶん、単なるディレクトリが
そのままgitリポジトリになるってことが
あまりにも（その人にとって）革新的なことであり
信じられないんだと思う。

だからそんなことはない。gitを使うとディレクトリで
出来たことができなくなるはずって思っちゃう。

ディレクトリでできることはすべて
gitでもできるんだよ。
2014/03/10(月) 17:26:12.69
>>193-194
ご託はいいから、具体的なやり方書いて。
2014/03/10(月) 17:44:57.14
>>195
だから普通のディレクトリと全く同じやり方だよ。
これでわからないの？
2014/03/10(月) 18:36:20.57
先ほどからやたらとgitを否定する方がいらっしゃいますが、git使えなくて
後輩にバカにされた腹いせに書き込んでるのでしょうか？
git脳なんて言ってるけどgit使えない脳の方が問題ですね。
2014/03/10(月) 18:42:40.39
bazaar脳がemacsはgitに以降しそうだから焦ってるんだろ
2014/03/10(月) 19:05:48.64
>>196
それ君が設定してから push して外注さんが clone したら、指定したフォルダは外注さんに見えなくなるの？
まさか、ローカルで見えないから OK とか恥ずかしいこと言ってないよね？

>>197
ごめんな、git 普通に使ってるんだわ。
でも、他も使ってるから粗が見えちゃうんだな。
まあ適材適所なんだが、この手の奴はあまりバラバラにあっても管理がめんどいから、可能なら統合したいんだな。
2014/03/10(月) 19:21:31.31
じゃぁ、いいとこ取りのバージョン管理システムを新たに開発すればいいじゃん。
2014/03/10(月) 23:36:11.36
なんか伸びてるとおもたら荒れてんのぉ
202デフォルトの名無しさん
垢版 |
2014/03/11(火) 00:53:39.84
部分チェックアウトは必要だわ
Android Studio 用のプロジェクトがコミットされたリポジトリからチェックアウトして、
Eclipse の プロジェクトで使う場合とか
assets ディレクトリを部分的に別々のリポジトリからチェックアウトしておくとか
面倒だから一つのリポジトリで複数のプロジェクトを管理とか
どう考えても部分チェックアウトは必須機能
2014/03/11(火) 01:47:53.26
>>202
Android Studio側のbuild.gradleとかにある設定は手動でEclipseに反映させてんのか？
おとなしくAndroid Studio使えよ
204デフォルトの名無しさん
垢版 |
2014/03/11(火) 02:04:19.60
gnomeかなんかでmakeかなんか使ってるとかいう話を見た気がする
2014/03/11(火) 02:49:32.38
いつも思うんだが、喧嘩腰じゃないと話せない人がいるのはなんなんだ・・・
議論の一部に自分に取って有意義な話があってその辺りについて詳しい話が聞きたいと思っても
喧嘩腰な人が出てくるとまったく議論にならなくなる、というか聞く気すら起きなくなる
2014/03/11(火) 05:17:40.62
>>199
なんで普通のディレクトリではできないことの話をしてるんだ？

何回も言ってるだろう？ gitのディレクトリは普通のディレクトリだ
だから”普通のディレクトリと同じこと"はできると

お前が言ってるpushやらcloneなんてのは普通のディレクトリでは出来ないことだ。
そんなことをしたいなら、ディレクトリを使うな（gitを使え）という話になる。
2014/03/11(火) 05:27:22.22
>>202
> Android Studio 用のプロジェクトがコミットされたリポジトリからチェックアウトして、
> Eclipse の プロジェクトで使う場合とか

そんな時に使うのがgitのサブモジュールという機能だよ。

まず、Android Studio 用のプロジェクトからチェックアウトして
Eclipse の プロジェクトで使うという、そのやり方
部分チェックアウトでやると、大きな問題がある。

それはEclipse の プロジェクトで使っているのは、
Android Studio 用のプロジェクトのどのリビジョンか？という話。

「Eclipse の プロジェクトのリビジョンX0005で使っているのは
Android Studio 用のプロジェクトの一部分のY0005リビジョンである」
という情報がX0005には記録されない。だからX0004に戻した時、Y????のどれを使えばいいかわからない。
X0005にY0005のソースコード丸々入れるというやり方もあるだろうが、そうすると最新版への追尾が難しくなる。

gitのサブモジュールのやり方を教えよう。

Eclipse の プロジェクトを開発している時に、特定のコミットにしたいして
Android Studio 用のプロジェクトの、特定のコミットをひもづける。
だからX0005にY0005を紐付けたら、X0005をチェックアウトした時に、自動的にY0005になる。
もちろんX0010をチェックアウトしたら、X0010に紐付けられたY000?が自動的に使われる。
Y000?を最新にしたければ、Y000?の最新を取ってきて新たにX0011というコミットを作る。
そうすれば、X0011は最新のY000?をできる。

部分チェックアウトで頑張るよりも、はるかにスマートな方法だ。
2014/03/11(火) 07:41:35.95
>>197
git使えない人は多いと思うよ
プログラマーでもgit理解出来ない人多いんだから、営業職の人にgitを無理強い出来ないね
2014/03/11(火) 07:44:32.68
営業職の人には普通にファイルを保存してもらって
分かる人がgitで管理すればよい。

まさかgit使えないなんて言うんじゃないだろうな？
それ技術者なはずなのに、営業職レベルってことだぞｗ
2014/03/11(火) 07:52:01.12
>>201
別に荒れてないよ、git 脳が勝手に暴れて勝手に玉砕しただけ (w
2014/03/11(火) 07:53:32.10
なるほど、ということにしたい奴が荒らしていたわけか。
2014/03/11(火) 08:04:16.45
>>206
はあ？
>>144 をやりたいって話なのは理解してるんだよね？
ファイシステム云々は >>179 とかが言い出した話だよ？
俺は >>144 が git でできるって言うならやり方示して、って言ってるだけ。
まさか、これがそのまま来るとは思わんかったわ (w
> ローカルで見えないから OK とか恥ずかしいこと言ってないよね？
2014/03/11(火) 08:07:55.75
>>212
> プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ？
やりたいのはこれだよね？
なんども答え出てると思うけど、

gitは普通のディレクトリを使うので、
一部のフォルダを特定の人/グループに見せないかいうのは
ディレクトリと全く同じ設定をすればよい。

さらにもっと高度な管理がしたければ、gitサーバーを使うことで
柔軟なアクセス制限を書けられる。

submoduleを使うことで、プロジェクトの一部を
別リポジトリにすることだって可能。
2014/03/11(火) 08:08:11.18
>>211
もうみんな話変えようとしてるよ？
まだ、恥ずかしいレス続けるの？ (w
2014/03/11(火) 08:10:13.16
意訳

> もうみんな話変えようとしてるよ？

「俺は」 話変えようとしてるよ？ みんなも同調してよ！

> まだ、恥ずかしいレス続けるの？ (w

お前のレスは恥ずかしいんだ。 みんなも同調してよ！
2014/03/11(火) 08:15:43.08
>>213
> なんども答え出てると思うけど、

リポジトリ分ける以外の答あったっけ？

> さらにもっと高度な管理がしたければ、gitサーバーを使うことで
> 柔軟なアクセス制限を書けられる。

だからそのやり方書いてよ。
2014/03/11(火) 08:16:35.24
>>215
まだやるの？ (w
2014/03/11(火) 08:20:49.49
>>216

リポジトリ分ける以外の答えは>>213に書いてあるだろ？
なんで見えてないの？すごく不思議なんだけど。

gitは普通のディレクトリを使うので、
一部のフォルダを特定の人/グループに見せないかいうのは
ディレクトリと全く同じ設定をすればよい。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

さらにもっと高度な管理がしたければ、gitサーバーを使うことで
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
柔軟なアクセス制限を書けられる。
2014/03/11(火) 08:21:23.81
都合の悪いレスは見えないんだろ？
本気でそんな人がいるとはね。
2014/03/11(火) 08:25:26.44
>>216
> > さらにもっと高度な管理がしたければ、gitサーバーを使うことで
> > 柔軟なアクセス制限を書けられる。
>
> だからそのやり方書いてよ。

お前が、gitサーバーで柔軟なアクセス制限できるという事実を素直に認めたらな。

お前が今知るべきなのやり方ではなく、gitサーバーがお前の目的を
叶えてくれる道具だということを知ることだから。

http://git-scm.com/book/ja/Git-サーバー-サーバー用の-Git-の取得
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E7%94%A8%E3%81%AE-Git-%E3%81%AE%E5%8F%96%E5%BE%97

ちょっとしたセットアップ
小規模なグループ、あるいは数名の開発者しかいない組織で Git を使うなら、
すべてはシンプルに進められます。Git サーバーを準備する上でもっとも複雑なことのひとつは、
ユーザー管理です。同一リポジトリに対して「このユーザーは読み込みのみが可能、
あのユーザーは読み書きともに可能」などと設定したければ、アクセス権とパーミッションの設定は多少難しくなります。

SSH アクセス
開発者全員が SSH でアクセスできるサーバーがすでにあるのなら、リポジトリを用意するのは簡単です。
先ほど説明したように、ほとんど何もする必要はないでしょう。より複雑なアクセス制御をリポジトリ上で行いたい場合は、
そのサーバーの OS 上でファイルシステムのパーミッションを設定するとよいでしょう。

リポジトリに対する書き込みアクセスをさせたいメンバーの中にサーバーの
アカウントを持っていない人がいる場合は、新たに SSH アカウントを作成しなければなりません。
あなたがサーバーにアクセスできているということは、すでに SSH サーバーはインストールされているということです。
2014/03/11(火) 08:30:42.77
gitサーバーの一つがgithubだといえば、
馬鹿にもわかるかねぇ。

言うまでもないだろうがgithubはプライベートリポジトリと言って
外部の人には見えないリポジトリにも対応している。

さすがに「githubの使い方を教えてよ」は
技術者として恥ずかしくて言えないだろう。
2014/03/11(火) 08:44:47.35
なんか荒れてると思ったら炎上学習法やってる奴が居るのか…
2014/03/11(火) 08:46:12.56
うるさい。そのやり方書いてよ。
2014/03/11(火) 08:54:37.15
svnでいいな
2014/03/11(火) 08:57:34.91
svnの壁ってやつかね。その先を知らない人が
満足する。
2014/03/11(火) 09:02:25.87
gitはどちらかと言えば、開発者のための道具だからね。
管理者のための道具じゃない。

gitをバリバリ使っている人は、だいたい開発者。
（念のためプログラマだけじゃないよ。開発する人全員）

svnで満足しているのは、ただの管理者でしょ？
ソース貰って、その日付だけわかればいいような、そんな人。
だから日付バックアップでも成り立つ。
開発者とは違って貰ったものを修正なんかしないからね。
2014/03/11(火) 10:01:47.42
程度によるよ
多人数で開発して細かくdiffを取ってpatchを当てる続けるようなソースコードの管理する場合にはgitやmercurialの方が向いてる
そうじゃない場合はsubversionの方が有利な事もある
既出の部分チェックアウトやファイルロック
2014/03/11(火) 10:04:45.01
>>209
gitを理解出来ないプログラマーはたくさんいるよ
linuxのカーネル開発してるような優秀な人揃いのプロジェクトならいいけど、
そうじゃない低レベルなプロジェクトもたくさんあるのが現実
2014/03/11(火) 10:40:50.83
>>220
user = {dev1, dev2, co-dev1}
がいるときに、
/proj/src/app/
/proj/src/lib/
/proj/src/else
/proj/else
というディレクトリ構成で、
* dev1,dev2は全てのディレクトリ以下を参照できる
* co-dev1は/proj/src/lib以下を見ることができない。それ以外は全部参照できる
という設定をするとき、
dev-group = {dev1, dev2, co-dev1}
lib-dev-group = {dev1, dev2}
というグルーピングをし、
chgrp -R /proj dev-group
chgrp -R /proj/src/lib
chmod -R 770 /pro/src/lib
とすれば実現できるが、これをgitではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。
2014/03/11(火) 10:42:06.63
>>229
訂正。
> chgrp -R /proj/src/lib
↓
chgrp -R /proj/src/lib lib-dev-group
2014/03/11(火) 11:01:28.32
>>228
gitすら理解できないってよほどアホか覚える気が全くないかだろう
そんな奴をプログラマーと呼べるのか？最低限持っているべき知識だろ

もう世界中で使われているから
分からない事があってもググれば大抵の事は解決するし
2014/03/11(火) 11:24:53.82
>>229-230
まあそう言うこと。
たぶんわかってるけど git が劣ってるなんて許せねーって言う奴とよくわからんけど煽ってやれ、っー奴が半々ぐらいかな (w

各マシンにリポジトリ全体を持つような仕組みなので、見せないを実現しようとしたらリポジトリの仕組みにかなり手を入れないとダメだろうし、OSS だとそう言う要求はあまり無いだろうから git がこの機能を持ってないのは当たり前とすら言えると思うんだけどね。

まあ当面 svn + git (svn) で行くわ。
2014/03/11(火) 12:18:30.59
>>229
>サーバーの OS 上でファイルシステムのパーミッションを設定するとよいでしょう。
なんだから
そこまでやったらgitでは何もやることないんじゃないの
2014/03/11(火) 12:34:05.41
>>233
ネタなのかマジで言ってるのかよくわからん (w
ひょっとしてベアリポジトリの存在を知らないのか？
2014/03/11(火) 12:37:56.06
freebsdの開発チームはがsubversionを採用したんだよな
理由はsubversionの方が合ってるからって
2014/03/11(火) 12:39:49.82
>>233
だから具体的にどうやるか書け
2014/03/11(火) 12:47:54.53
いやおれhg使いだし
サブモジュールのディレクトリにパーミッション設定して終わりじゃないのか
2014/03/11(火) 12:58:42.60
>>237
何いってんの？
2014/03/11(火) 13:03:47.19
煽るだけのは邪魔だからどっか行けよ
2014/03/11(火) 13:32:01.32
>>235
Linux の世話になんかならんぞ、っーのもあるんじゃね？

まあ便利ならなんでも取り込む Linux/git に対して、ポリシーに沿わないものは取り込まない FreeBSD/Subversion って感じかな。
2014/03/11(火) 13:36:20.76
いやおまえこそ
2014/03/11(火) 13:42:31.53
GPLを排除したいFreeBSDにしてみれば
メジャーなDVCSのGit、Hg、Bzrが軒並みGPLな現状じゃ
Apacheライセンスな非DVCSのSubversionを選ぶざるを得ないってとこか
2014/03/11(火) 13:46:51.73
>>239
良く分かってないのに適当な回答かまして場をかき乱す奴よりはまし。
2014/03/11(火) 13:58:09.47
>>229
gitでの話。

drwxrwx--x dev-group:dev-group /proj ← ここ以下をgitで管理
drwxrwx--x dev-group:dev-group /proj/.git ← gitデータディレクトリ
drwxrwx--x dev-group:dev-group /proj/src/app/
drwxrwx--- lib-dev-group:lib-dev-group /proj/src/lib/
drwxrwx--x dev-group:dev-group /proj/src/else
drwxrwx--x dev-group:dev-group /proj/else

dev-group = dev1, dev2, co-dev1
lib-dev-group = dev1, dev2

こうすればいい。お前が言ったことを分かりやすく図にしただけ。
（これだと新規ファイル作成時に問題があるがね。気づいてないでしょ？慣れてないことするからｗ）

gitは普通のディレクトリなのだから、同じようにやればいいと言ってる。
これが下記のgitの使い方の一つとして述べられてる「ファイルベールのリポジトリ」

この欠点はdev-groupはgitを使えるが、それ以外はgitを使えないということと
gitを使う時に多少考える必要が有ること、gitの本領を発揮できないということ。
だがgitを使いたくなった時は、ただのディレクトリではダメな作業が
できたということなので即刻ディレクトリをやめろという話になる。

4.1 Git サーバー - プロトコル
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

利点
ファイルベースのリポジトリの利点は、シンプルであることと既存のファイルアクセス権や
ネットワークアクセスを流用できることです。チーム全員がアクセスできる共有ファイルシステムがすでに存在するのなら、
リポジトリを用意するのは非常に簡単です。ベアリポジトリのコピーをみんながアクセスできるどこかの場所に置き、
読み書き可能な権限を与えるという、ごく普通の共有ディレクトリ上での作業です。
2014/03/11(火) 14:07:09.69
linuxっていつまで経ってもaclベースのアクセス制御普及しないよな
新着レスの表示
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況