バージョン管理システムについて語るスレ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/

2デフォルトの名無しさん2014/02/23(日) 18:19:58.71
●関連スレ
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
CVS導入スレ〜 Rev.3 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1113141518/
subversion バージョン管理【サブバージョン】 [Linux板]
http://engawa.2ch.net/test/read.cgi/linux/1154701996/
Subversion r14 [プログラム板]
http://toro.2ch.net/test/read.cgi/tech/1326806859/
Git 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/
【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://toro.2ch.net/test/read.cgi/tech/1356521407/

3デフォルトの名無しさん2014/02/23(日) 18:20:47.21
●関連サイト
Apache Subversion
ttp://subversion.apache.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/

4デフォルトの名無しさん2014/02/23(日) 18:22:15.09
●チュートリアル
Git入門
ttp://www8.atwiki.jp/git_jp/
git チュートリアル (バージョン 1.5.1 以降用)
ttp://www8.atwiki.jp/git_jp/pub/Documentation.ja/tutorial.html
Pro Git
ttp://git-scm.com/book/ja/
5分でわかるBazaar − Bazaar v2.6.0dev2 documentation
ttp://doc.bazaar.canonical.com/latest/ja/mini-tutorial/
Mercurial の使い方のチュートリアル
ttp://mercurial.selenic.com/wiki/JapaneseTutorial

5デフォルトの名無しさん2014/02/23(日) 18:23:14.75
以上テンプレ
消滅してるとことか削除させてもらった

6デフォルトの名無しさん2014/02/23(日) 18:54:18.97
インターネットアーカイブに残ってたので一応
●関連サイト
CVS
ttp://web.archive.org/web/20101130125020/http://ximbiot.com/cvs/wiki/
●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://web.archive.org/web/20090205132701/http://subversion.bluegate.org/

7デフォルトの名無しさん2014/02/24(月) 15:42:18.04
おつ
少なくともどれかがないとコード書けない体になったわ

8デフォルトの名無しさん2014/02/24(月) 22:08:41.96
>>1

9デフォルトの名無しさん2014/02/25(火) 19:06:56.33

10デフォルトの名無しさん2014/02/25(火) 23:10:01.95
セーブがわりにくだらんコミットすんじゃないと俺だけローカルリポジトリになったし

11デフォルトの名無しさん2014/02/26(水) 11:40:24.24
今の職場は、コミット時にはコミットレビューなるものを行わないとコミットできない。
さすがにやり過ぎではないかと。

12デフォルトの名無しさん2014/02/26(水) 13:43:47.94
commitは好きにやればいいだろ
そのままpush済んなって話であって

13デフォルトの名無しさん2014/02/26(水) 14:01:13.54
git脳

14デフォルトの名無しさん2014/02/26(水) 19:28:02.16
VCSごとにコミットやブランチの意味が異なるとかヤメテー

15デフォルトの名無しさん2014/02/26(水) 19:36:52.07
コミットやブランチはそんなに混乱してないだろ
コミットの場合は何処にコミットするかって話なだけだし

問題はチェックアウトだ

16デフォルトの名無しさん2014/02/26(水) 22:00:00.42
コミットは集中型と分散型で意味が違うだけで、それぞれの中では一緒だよね
ブランチはそれなりに違うと思う

17デフォルトの名無しさん2014/02/27(木) 01:47:00.68
svnとgitとhgに限れば、コミットは同じような概念だな
ブランチはsvnの場合、異質
チェックアウトはsvnは部分チェックアウト出来るのがメリット大きい

18デフォルトの名無しさん2014/02/27(木) 13:28:12.01
今でもファイル名に日本語使ってるような文書ファイルなんかは一応 bzr で管理してる。
hg が unicode サポートすれば不要なんだが。

19デフォルトの名無しさん2014/02/27(木) 23:18:28.02
コミットってビルド出来るならしていいんだろ?

20デフォルトの名無しさん2014/02/27(木) 23:22:11.74
スクリプト言語とかだとろくにテストもしないでコミットしとる場合が多い

21デフォルトの名無しさん2014/02/27(木) 23:38:04.66
ビルドできない状態のを大量にコミットしてました
すんません

22デフォルトの名無しさん2014/02/28(金) 00:17:07.64
Mercurial でのプルリクエストをサポートしました
http://sourceforge.jp/projects/sourceforge/news/24580


キター!!

23デフォルトの名無しさん2014/03/02(日) 00:53:25.99
gitにはサブモジュールっていう別のgitリポジトリを参照することできるけど
バイナリ管理にはSVNがいいっていうんなら
gitのサブモジュールみたいな機能で、テキストはgitのような分散で、バイナリはSVNという複合なリポジトリとか作れたりしないん?

24デフォルトの名無しさん2014/03/02(日) 01:07:43.33
バイナリ管理にSVNがいいなんて誰も言ってないよ。
テキストデータでないものはバージョン管理は無理

っていうか、バージョンの意味が違うんだよ。
gitなどのバージョン管理システムっていうのは
ソースコードの機能の違いをバージョンと評してこれを管理するもの

バイナリファイルはデータの違い。バージョンではなく
入れ替え可能なデータ。画像の違いなんてものは違う
データというだけでバージョンというものは当てはまらない。

25デフォルトの名無しさん2014/03/02(日) 01:16:49.50
そんな俺定義のバージョン管理語られても

前スレの後半でバイナリ管理の話もあったのに

26デフォルトの名無しさん2014/03/02(日) 01:21:34.48
そういや今は過去スレ見放題なんだっけ?

27デフォルトの名無しさん2014/03/02(日) 01:36:08.82
バイナリなんてファイル管理しておけば
バージョン管理する必要なんてないでしょ。

28デフォルトの名無しさん2014/03/02(日) 01:47:58.53
じゃあテキストは何でバージョン管理するの?

バイナリのバージョン管理の必要や需要はあるけど
ツールが無いってのが現状じゃないの

29デフォルトの名無しさん2014/03/02(日) 02:16:30.05
officeファイルのバージョン管理なら、大きな企業だとシェアポイント使ってる

30デフォルトの名無しさん2014/03/02(日) 02:23:28.86
適当な差分をとれさえすればいいんだろ。
例えば.xlsxならzip圧縮されたxmlなんだからテキストとして差分をとることも可能だろうし、
画像にしても画素単位で差分をとれるだろうし。
問題は、そこまでする手間に見合うかじゃないの?

31デフォルトの名無しさん2014/03/02(日) 02:45:36.92
それは見当違い

32デフォルトの名無しさん2014/03/02(日) 02:48:39.78
それとはどこよ

33デフォルトの名無しさん2014/03/02(日) 02:55:07.97
適当な差分という意味では
多くのGUIアプリケーションがUndo/Redoを実装しているんだから
そのスタック(とは限らないけど)を
シリアライズ/デシリアライズする標準フォーマットがあればいいと思うんだけど
まぁそういうのを作って採用するインセンティブが無いよね

34デフォルトの名無しさん2014/03/02(日) 02:59:45.93
画像はマージしないからな。

ファイル単体で管理すればいいなら
わざわざバージョン管理ツールを使う必要はない。
バックアップさえあれば十分だ。

35デフォルトの名無しさん2014/03/02(日) 03:04:54.01
xmlファイルで差分を取るとかマージするとか、現実に行うとどうなるか考えてみよう
sharepointはシステム化の進んだ企業では非常にポピュラーな存在
ソースコードの管理には不向きだから、この板では知名度が低いというだけ

36デフォルトの名無しさん2014/03/02(日) 03:12:38.24
>>34
画像の場合
複数ユーザの同時変更によるコンフリクトの修正は
現実的でないかもしれんが
複数のバージョンのパーツを融合させるというのは
ありふれた工程だと思う

てか>>34の理屈が通るなら
何でソースコードのバージョン管理してんの?

37デフォルトの名無しさん2014/03/02(日) 03:42:56.25
>>36
画像は成果物をソースコードに混ぜ込んでるだけだよ。

画像にもソースというものはあって、それはオリジナル画像のこと。
オリジナル画像は解像度が高かったりイラストレーター形式だったりする。

ウェブ用にはそのオリジナルの画像を変換したものを使う。
バージョン管理するのは、ウェブ用に生成したファイル。

オリジナル画像の方はバックアップはとるが
バージョン管理はする必要がない。

というかオリジナル画像とかサイズが数MBになるものが大量にあったりして
そんなものをソースコードに混ぜ込んだりしたら、チェックアウトするたびに
ファイルコピーで時間がかかって、やってられないんだわ。

38デフォルトの名無しさん2014/03/02(日) 03:46:28.39
画像に関して言えば
バージョン管理するのは、「どの画像を使うか」という
情報であって、画像そのもののバージョン管理じゃないんだわ。

39デフォルトの名無しさん2014/03/02(日) 03:53:12.45
何勝手にウェブ用とかソースコードと一緒に管理する話に限定してるの?
対象を限定して議論を深めるならともかく
そんなわかり切った話されても

ム板だからって視野狭すぎでは?

40デフォルトの名無しさん2014/03/02(日) 03:54:15.08
>>39
じゃあ違う場合の話しろよ。

文句ばかり言って終わりか。
お前のレスに価値がない。

41デフォルトの名無しさん2014/03/02(日) 03:55:48.55
バイナリっていうのは人間が
直接編集できるものじゃないんだから
何かのツールの生成物になるんだよ。
バージョン管理に生成物を含めないのは言うまでもないよね。

42デフォルトの名無しさん2014/03/02(日) 04:01:29.34
数年後にビルド環境を整えられる自信がない時は、生成物入れちゃってもいいと思うわ。

43デフォルトの名無しさん2014/03/02(日) 04:14:39.84
IDE使ってたら色んなもの勝手に生成してくれちゃうと思うんだけど
そういうのはバージョン管理しちゃいけないの?

リポジトリに含めないってのは
バージョン管理が不要という意味とは少し違うんじゃないか?

それに人間が直接編集することを想定してない
テキストデータだっていくらでもあるし
ツールの一種であるテキストエディタと同程度に
人間が編集できるバイナリデータだって
いくらでもあると思うんだが

44デフォルトの名無しさん2014/03/02(日) 04:19:33.84
> 人間が直接編集する

さっきからミナサンが使ってるこれが理解不能

45デフォルトの名無しさん2014/03/02(日) 04:25:17.35
「直接」ってのは感覚的な違いでしかないと思うけどね
だから本質じゃないでしょってのが>>43の後半の話だけど

46デフォルトの名無しさん2014/03/02(日) 05:20:55.92
>>43
> IDE使ってたら色んなもの勝手に生成してくれちゃうと思うんだけど
> そういうのはバージョン管理しちゃいけないの?

はい、いけません。

(どうせ、どのファイルがなんのファイルかわからないから
なにも考えずに全部登録してるだけだろ。それが他人の迷惑になるかもしれないのに、
そんなこと言わずに、管理しちゃいけないの?とか聞いてることからわかる)

勝手に生成するものを含めたらIDEが勝手に書き換えて
編集中ってなるだろうが、それをコミットして他人が
チェックアウトしたらどうなる。めちゃくちゃだ。

47デフォルトの名無しさん2014/03/02(日) 08:40:46.29
svn だとディレクトリごとにチェックアウトしたり、アクセス制限かけたりできるけど、git だと無理そうだね
毎回リポジトリ内を全て落としていそう

Android Studio 用に作られたワークスペースを、Eclipse で使う場合って、
OS で シンボリックリンク使えよってこと?

48デフォルトの名無しさん2014/03/02(日) 10:36:35.98
>>42
> 生成物入れちゃってもいいと思うわ。

品証とかお客さんへ出すときなどはやってる。
VS だと環境整えても全く同じバイナリは生成できないから。

49デフォルトの名無しさん2014/03/02(日) 10:54:12.10
特定のバージョンのライブラリが必要な場合は入れることある。

何でもかんでも入れるのはよくないけど、ソースコード以外はダメだってのも極端すぎ。
そういうのはプロジェクトやその会社の運用次第だから。

ソースはバージョン管理システムで管理してるのに、ワードやエクセルなんかのファイルは
ファイル名に日付つけたりoldディレクトリ作ったりとかするくらいなら、それらも突っ込んどけ
よって思う。
バイナリファイルはdiffとったりしないけど、プロジェクトの成果物の一元管理という点から
同じ所に入れてほしいね。

50デフォルトの名無しさん2014/03/02(日) 11:02:48.47
>>49
そういうのはプロジェクト管理
ソフトを使うんだよ。

なんでもソースコード扱いにするな。

51デフォルトの名無しさん2014/03/02(日) 12:31:52.46
>>46
含めたらプロジェクト構造が保てない自動生成ファイルもあるんだけどなあ…
結局、IDEの生成物に関しては
「分からないものをどうするか」なんて考え自体が変で
各自動生成ファイルがどういう役割か、程度の理解は要るよ。

52デフォルトの名無しさん2014/03/02(日) 12:48:30.70
Javaで、mavenやivyリポジトリから自動ダウンロードさせたjarファイルって、
どうしてる?

バージョン管理に入れとかないと、数年後には手に入らなくなってるのも
有るんじゃないかと思うんだけど。

53デフォルトの名無しさん2014/03/02(日) 12:59:42.27
本来はソースコード、画像、ドキュメントはそれぞれ別のアプローチでバージョン管理すべきだが、どうしても一つのリポジトリに全部入れがちになる
その点、svnは日本語ファイル名でトラブルが少ない、圧縮効率がいい、部分チェックアウト出来る、WindowsのGUIクライアントの出来がいいって事で、比較的そういう使い方に向いてる

54デフォルトの名無しさん2014/03/02(日) 13:28:31.19
>>50
どんなプロジェクト管理ソフトがおすすめ?
wordやexcelの管理するソフトを探してた
出来れば外出先で編集して、帰ってきてから簡単にマージしたい

55デフォルトの名無しさん2014/03/02(日) 20:23:22.02
>>54
訳あってなに使っているかは言えないけど、
条件としては、メールに頼らない、
WordやExcelを使わない。
そういうのがオススメだね。

理由はメールだと関係者宛のメールが面倒くさい。
プロジェクトに入っているならば
その人全員でいいはずなのにいちいち個人宛てとか
CCとか面倒くさい作業になる。
話が時系列でおえない。新しく参加した人が知ることが出来ない。
まあデメリットだらけ。

WordやExcelを使わないのは、今誰の行動待ちとか
今どういう状態にあるのか全く管理できないから。
プロジェクト管理において機能不足で使えない。

56デフォルトの名無しさん2014/03/02(日) 20:24:47.90
>>52
数年後に手に入れられることが確実なら、リポジトリに入れないわけでしょ?
なら答え出てる。リポジトリにいれないが正解。

数年後に手に入れる方法なら別にリポジトリを使わなくてもできるから。

57デフォルトの名無しさん2014/03/02(日) 20:25:42.29
??

58デフォルトの名無しさん2014/03/02(日) 20:31:33.30
>>55
wordやexcelはバージョン仮管理ソフトではなく、プロジェクト管理ソフトを利用するべき。
と、>>50 で主張されていたので
どんなソフト使ってるか?聞いたんだけど・・・・・
wordやexcelを使わないって・・・・・
全く話がかみ合わない
俺の理解が悪いのか?

59デフォルトの名無しさん2014/03/02(日) 20:39:35.28
>>58
> wordやexcelの管理するソフトを探してた
って書いてあるからだろ。

そもそもそれらを使うなって話。

60デフォルトの名無しさん2014/03/02(日) 20:41:44.57
そもそもプロジェクトの進捗管理と
プロジェクトの成果物は別のものなんだよね。
これらを一緒に管理しようとすると
めちゃくちゃになる。

61デフォルトの名無しさん2014/03/02(日) 20:43:25.05
プロジェクト管理ってVisual Studioみたいな感じかな

62デフォルトの名無しさん2014/03/02(日) 20:44:45.88
違う

マイルストーンとかそういう話。

63デフォルトの名無しさん2014/03/02(日) 20:47:55.12
>>59
なら50はなんなの?

64デフォルトの名無しさん2014/03/02(日) 20:51:44.86
>>50はなんなのって
プロジェント管理には(WordやExcelではなく)
プロジェクト管理ソフトを使えって話だろ

65デフォルトの名無しさん2014/03/02(日) 20:54:57.70
テキストエディタを使って絵をかけないように、
(正確に言えばSVGとかでかけるがものすごく効率が悪い)
WordやExcelやメールではプロジェクト管理ができないってことが
出発点なんだよね。

できないからなにを使うのがいいかという話。

66デフォルトの名無しさん2014/03/02(日) 21:08:20.84
>>64
49の日本語を理解しろよ
プロジェクト管理をやるとは書いてない
成果物としてのWordやExcelの管理をどうするか
という話題にしか読めないが
どう読んだらプロジェクト管理をExcelでやるなんて読めるんだ?

67デフォルトの名無しさん2014/03/02(日) 21:18:08.44
プロジェクト管理≠バージョン管理

68デフォルトの名無しさん2014/03/02(日) 21:22:57.47
プロジェクトの指すものが違う奴居るよな
ossプロジェクトみたいなのとvsとかvcでのプロジェクトと

>>55
MLとそのアーカイブ使えばいいだけだな
個人宛にるのは内緒話とかあるからなんともいえん

69デフォルトの名無しさん2014/03/02(日) 21:27:09.58
プロジェクト管理といえば、redmain

70デフォルトの名無しさん2014/03/02(日) 21:29:25.86
なんで、WordやExcelが成果物になるんだ?
プログラマーの成果物がWordやExcelだなんていう話は
聞いたことがないぞ。事務員が紛れこんでるのか?

71デフォルトの名無しさん2014/03/02(日) 21:44:15.42
バイナリのリソースがソースコードと密接に絡んでるようなものを作ってる立場だと、
「ソースコードのバージョン管理システムにバイナリを入れる奴が悪い。入れるな」って意見は正しいけど原理主義的だと思うんだよな。
そういうものを管理するのにGitをだましだまし使ってるところが問題なんだろうけど、これといった決定打がないんだよなあ。

72デフォルトの名無しさん2014/03/02(日) 21:48:28.76
>>69
名前も覚えてないのに定番みたいに紹介する男の人って

73デフォルトの名無しさん2014/03/02(日) 22:29:39.32
おいおい
設計書も作らない素人が紛れてるのか

74デフォルトの名無しさん2014/03/02(日) 22:41:52.06
横から初心者(というか、アマチュアな…でしょうか)質問で、すみません
プロジェクト管理ソフトって定番とかあるんでしょうか

75デフォルトの名無しさん2014/03/02(日) 22:47:20.44
Microsoft Project。

76デフォルトの名無しさん2014/03/02(日) 22:54:44.63
>>75
それガントチャートアプリだろ
プロジェクト管理じゃない

77デフォルトの名無しさん2014/03/02(日) 23:03:46.27
Comparison of project management software - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_project_management_software

定番ってどれだろうねえ

78デフォルトの名無しさん2014/03/02(日) 23:05:09.47
プロジェクトマネジメントだろ

79デフォルトの名無しさん2014/03/02(日) 23:05:24.75
Project management software - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Project_management_software
> Basecamp, Podio, Project.net, Asana, Sharepoint, Framebench, Brightpod etc

ここらがメジャーどこかな

80デフォルトの名無しさん2014/03/02(日) 23:13:11.77
>>76
れっきとしたプロジェクト管理である。
何か勘違いしてらっしゃるようで。

81デフォルトの名無しさん2014/03/02(日) 23:14:36.97
>>74
Excel

82デフォルトの名無しさん2014/03/03(月) 00:49:59.39
>>70
まともな会社なら設計仕様とかテスト仕様書とかって、当然プログラマーの成果物でしょ?
まさか、ソースコードだけ作って仕様書作らないとか・・・?
でもプロジェクト管理ソフトの話をしてるし、プロジェクト管理ソフト使うレベルの会社が
そんな専門学校生の同人ゲーム並の開発体制とってるなんてことはないだろうし・・・。

83デフォルトの名無しさん2014/03/03(月) 07:48:45.74
>>76
ガントチャートしか書いたこと無いのかよ (w

84デフォルトの名無しさん2014/03/03(月) 07:51:27.27
>>70
>事務員が紛れこんでるのか?

働いたことことない無職が紛れ込んでいたというオチ (w

85742014/03/03(月) 08:26:59.77
ありがとうございました
プロの方は色々やってるんだなあ…

86デフォルトの名無しさん2014/03/03(月) 08:55:57.71
excelだのwordだので仕様書を書いたりする人は、oss界隈には多分いない
と思うよ(自分の知る限り)。だから、gitにしろmercurialにしろ、ossな
バージョン管理システムは、そういったプロの人達には使いにくいかも
しれないねぇ。気の毒に…
素人くさいossなんかやめて、プロはプロ向けの道具を使えばいい。

87デフォルトの名無しさん2014/03/03(月) 11:30:10.72
>>53
>本来はソースコード、画像、ドキュメントはそれぞれ別のアプローチでバージョン管理すべきだが、どうしても一つのリポジトリに全部入れがちになる

でも画像とソースコードを同じシステムで管理しないと、別々のリビジョンになって意味なくなってしまわない?
別々に管理するとこのリソースでこのコードの時は正常に動作していたがとか、
ベータ版のときのソースはいつのでリソースはどれだっけみたいなことって結構あると思うが

もちろん開発してる環境によって色々あるとは思うけど、本来はソースコード、画像、ドキュメントは同一システムで管理すべきだが、
今はツールやチェックアウトにかかる時間などの制約で、やむなく別々に管理しないといけないことがあるってのが現状じゃないかと思う。

88デフォルトの名無しさん2014/03/03(月) 14:55:57.93
画像を例えばsvnで管理するなら先にsvnに画像コミットしておいて
本体側ではsvnのrevだけ管理したらいい

89デフォルトの名無しさん2014/03/03(月) 15:14:49.09
>>88
そんな事するぐらいなら
Mercurialのlargefile使う

90デフォルトの名無しさん2014/03/03(月) 19:21:28.28
画像入れない派の人は、1KBにも満たないようなアイコンファイルとかも入れないわけ?

91デフォルトの名無しさん2014/03/03(月) 20:00:03.17
svnはロック出来るのも利点だな
バイナリはマージ出来ない以上、コンフリクトは確実に回避する必要がある

92デフォルトの名無しさん2014/03/04(火) 10:32:25.72
帳票のテンプレートならわかるけど
設計書にExcelってワロタ

93デフォルトの名無しさん2014/03/04(火) 12:44:55.04
>>92
> 設計書にExcelってワロタ

普通にあるだろ。
無職なのか?

94デフォルトの名無しさん2014/03/04(火) 14:29:52.36
出たよバカ自慢

95デフォルトの名無しさん2014/03/04(火) 14:34:59.06
あるかないかは問題にしてないだろ

96デフォルトの名無しさん2014/03/04(火) 22:12:44.96
プロジェクト管理ソフトに続いて、今度は設計書作成ソフトの話題ですか。
で、実際何を使ってるよ?
うちはエクセル。

97デフォルトの名無しさん2014/03/04(火) 23:30:30.62
>>96
他のなにを検討した結果エクセルになった?
それともエクセルにしたのは使えるのがそれだけだから?

98デフォルトの名無しさん2014/03/04(火) 23:31:58.91
プロジェクト管理に使ってるエクセルのファイルをバージョン管理してるって話?

99デフォルトの名無しさん2014/03/05(水) 00:41:08.63
周りでは、Excelで設計書もスケジュール管理もやる人が多い
これは会社が変わっても一緒
おそらく、だれでもそれなりに使えるから。
じゃないかな
効率は・・・・あまり良いとは言えないが、他に良いソフトもない

で、バージョン管理は使ってないから
・設計書.xls
・設計書_最新.xls
・設計書_20140304.xls
・設計書_修正前.xls
があふれている

これも、バージョン管理に入れれば良いかも知れないが
ファイルサーバで行うのが一番使いやすいので困っている

バージョン管理ソフトでなんか良い方法はないかな

100デフォルトの名無しさん2014/03/05(水) 01:10:05.72
設計書Markup Language を作って、それで書いたものをバージョン管理に追加
実際に見るときは、TeX とかPDFとかに変換

101デフォルトの名無しさん2014/03/05(水) 01:13:04.44
javadoc形式でコメント書くのもだが
wordでのhtml編集みたいにマークアップの記述なしで装飾でけたらいいのに

102デフォルトの名無しさん2014/03/05(水) 01:22:54.83
>>99
gitでもhgでも良いと思うぞ
因みにうちは共有物は全てSVNに突っ込んでる
俺個人のファイルは全てhgに突っ込んでる

103デフォルトの名無しさん2014/03/05(水) 03:21:04.47
>>99
sparkle share でドキュメント投げてもらう。
んでそれをリモートブランチとして取り込む。

104デフォルトの名無しさん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も混在してるとさらに

107デフォルトの名無しさん2014/03/07(金) 00:57:23.74
最近職場でPerforce使いはじめたけど
ローカルでファイル消したらrevertできなくて嵌った
gitが気楽でええわ
バイナリデータ扱うとカスみたいに遅いsvnは放置で

108デフォルトの名無しさん2014/03/07(金) 03:16:56.38
gitってバイナリデータ扱うのに一番向いてないだろう

109デフォルトの名無しさん2014/03/07(金) 09:22:10.23
>>108
容量は食うけど、とにかくsvnより早いから使ってたんだが
バイナリ向けにいいのあったら教えてほしい

110デフォルトの名無しさん2014/03/07(金) 10:45:20.66
>>107
svn がバイナリデータで他より遅い?
svn がアホみたいに遅くなるのはファイル数が増えたときだろう。

111デフォルトの名無しさん2014/03/07(金) 10:52:13.21
>>107
大きなバイナリ扱うのが上手いのはそれこそPerforceだとおもうけど
ギガバイト超えてくるとかなり差があると思う

112デフォルトの名無しさん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

115デフォルトの名無しさん2014/03/08(土) 08:42:20.94
ゲーム作ってる所はsubversionが多いらしいね

116デフォルトの名無しさん2014/03/08(土) 08:57:37.64
Gitって別のものへの移し替えが生じたときに面倒な事になりそう。
最近でいうと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
試してみる

121デフォルトの名無しさん2014/03/08(土) 16:02:27.74
ageちまったスマソorz

122デフォルトの名無しさん2014/03/09(日) 02:41:21.23
>>119
だったら開発がしやすいどんな機能があるのかないのか、に絞って話さないとな
性能はさておき、まずはできるかどうかでしょ

お前がそれについて書いてるかどうかは知らんけど

123デフォルトの名無しさん2014/03/09(日) 13:33:51.72
現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

プログラム板 強制ID制導入に関する投票スレ
http://kohada.2ch.net/test/read.cgi/vote/1394290844/

124デフォルトの名無しさん2014/03/09(日) 15:58:10.80
>>122
ブランチの作成や切り替えが一瞬(長くても数秒レベル)で終わる。
特定のコミットだけを取ってこれる。
歴史を書き直せる。
bisect

最低限この機能は必要。
あと性能も重要。開発の快適さに直結するから。

125デフォルトの名無しさん2014/03/09(日) 16:18:40.18
>>124
これまた見事な git 脳

126デフォルトの名無しさん2014/03/09(日) 16:24:44.21
>>125
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

130デフォルトの名無しさん2014/03/09(日) 23:17:13.95
bisect始めて知った
いつも手動で二分探索してたわ…

131デフォルトの名無しさん2014/03/09(日) 23:28:28.71
>>129
例えばセキュリティ、ファイルロック、部分チェックアウトとか git が弱いところ書いてないだろ

132デフォルトの名無しさん2014/03/09(日) 23:33:39.91
gitとは関係なしに
バージョン管理システムにおけるセキュリティの問題って何?

133デフォルトの名無しさん2014/03/09(日) 23:49:30.33
>>132
フォルダ毎にアクセス制限かけたりとかかな
外注さんとやってると、ここは見せたくないとかあるから

134デフォルトの名無しさん2014/03/10(月) 00:07:57.53
>>133
そういう需要があるのは理解できるけど
フォルダ毎のアクセス制限を管理するのと
最初からリポジトリとかフォルダより上位のモジュールで分けて管理するのと
どっちが合理的かというと微妙な気が……

セキュアだけどまともに運用できるかという点で
SELinuxのそれと似た印象を受ける

135デフォルトの名無しさん2014/03/10(月) 03:18:40.78
>>131
> 例えばセキュリティ、ファイルロック、部分チェックアウトとか git が弱いところ書いてないだろ

それらの機能を具体的に。
どういう時に使うの?

136デフォルトの名無しさん2014/03/10(月) 03:20:06.95
特定のディレクトリでプロジェクトが閉じてるのに、なんでその親ディレクトリがリポジトリになってんの。
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はルート直下にしか置けない。
メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、
そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。

1411402014/03/10(月) 06:36:10.29
なかなかいいサンプルが見つからないが、submoduleを使うとこういう感じになる。
https://github.com/bocon13/datacenter_mptcp (この人は俺とは無関係)

util @ 75d064d ってなってる所がサブモジュールで
クリックするとわかるように「外部のリポジトリ@コミット番号」に
紐付いている。

このutilディレクトリの中身は、この人から見れば
リンク先のファイルがそのまま有るように見える。

この人達が知り合いかどうかは知らないが、
ソースコード上はこうやって無関係のリポジトリを
取り込むことができている。

これと同じ仕組みを使えばいいだけだよ。

142デフォルトの名無しさん2014/03/10(月) 07:51:24.77
>>140
> もしそうだとしたら、それ人為的ミスで間違ってファイルわたしてしまう可能性があるから

そのためのセキュリティなんだが...、git 脳には伝わらんか。

143デフォルトの名無しさん2014/03/10(月) 08:38:35.22
>>142
お前、セキュリティ単語いってるだけじゃん。
具体的に何をしているのかいえって。

俺のセキュリティならなんの問題もない(笑)

144デフォルトの名無しさん2014/03/10(月) 10:17:47.96
>>143
プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ?
理解できない?
派遣の外注さんに応援頼むんだけと、社外秘のソースとかとかお客さんとの契約でここは関係者以外には見せちゃダメとか、色々あるんだわ。
お前んとこでそんな状況になったこと無いから問題なしとか言うならいちいちでしゃばってくんなよ。

145デフォルトの名無しさん2014/03/10(月) 10:33:11.63
>>144
いや、だから見せないならば、渡さなければいいじゃん
リポジトリを分けてサブモジュールで管理すればいい。
更新禁止は普通にメインリポジトリへのマージを制限すればいいだけ。

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

あんたの言ってることは、みな想定の範囲内の
すでに解決済みの話だよ。

146デフォルトの名無しさん2014/03/10(月) 10:34:24.39
>>144
理解できてないんじゃなくて、
少なくともgitの世界では解決済みの話だって言ってるんだよ。
それを理解できてないのはあんたのほうでは?

147デフォルトの名無しさん2014/03/10(月) 10:55:31.51
ま、Linuxのカーネル開発する人たちにはファイルロックも部分チェックアウトも不要な機能なんだろう

148デフォルトの名無しさん2014/03/10(月) 10:56:10.55
>>145-146
○○すれば大丈夫とか言うなら、そりゃそうだとしか言えんわな...
プロジェクトの途中でリポジトリ分ければいいじゃんとか、正気かよ? とは思うが、git 脳だと当たり前なんだろうな (w

149デフォルトの名無しさん2014/03/10(月) 11:10:14.60
>>148
お前、何も反論してないって自分で気づいてる?
「俺は違うと思う」と言ってるだけ。

150デフォルトの名無しさん2014/03/10(月) 11:15:34.13
>>147
ロックの話をするならば、
楽観的ロックの悲観的ロック違いを知っているか?
これはどちらも「ロック」だ。

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

154デフォルトの名無しさん2014/03/10(月) 11:49:36.89
一体どういう管理方法をしてるんだろうな。
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の成果物を使う
のは勝手にどうぞ、としかいいようがないが、それで機能が足りないだの技術力がどうのと
文句いわれても、別にオープンソースの側は何とも思わないよねー。
だって必要ない機能なんだもん。

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よりも柔軟性に欠ける。
だが通常のディレクトリよりも機能は上だ。

163デフォルトの名無しさん2014/03/10(月) 12:43:29.46
gitってなんでもできるんだなー。

164デフォルトの名無しさん2014/03/10(月) 12:53:18.85
>>149
反論?
>>124 からの流れで別に反論なんてしてないが?
git でやりづらいこともあるでしょ? って言ってるだけ。
別に git はそんなことを想定して作ってないだろうから当たり前なんだが、バージョン管理システムの機能の話してるのに git がー、git でわー、とか俺にはそんな必要ないからとか言われてもしょうがないでしょ?
素直に、そんな機能は無いって言えばいいだけだと思うよ。

165デフォルトの名無しさん2014/03/10(月) 12:53:59.78
>>162
それやるなら、さらに--separate-git-dirを使うといいかも。
.gitディレクトリを別の所に作成できる。

つまりは、ディレクトリはほぼそのままで
(.gitディレクトリが書かれた.gitファイルができるだけ)
gitの管理下における。

166デフォルトの名無しさん2014/03/10(月) 12:54:57.53
>164
> 素直に、そんな機能は無いって言えばいいだけだと思うよ。

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

その機能をさっさといってよねw

167デフォルトの名無しさん2014/03/10(月) 12:55:32.05
今までの話でgitで出来ない機能なんて
一つも出てないなー

168デフォルトの名無しさん2014/03/10(月) 13:16:33.50
普通のディレクトリをそのままgit化できる時点で
ディレクトリ+αの機能になるしね。
ディレクトリでできることはgitでもできる。

169デフォルトの名無しさん2014/03/10(月) 13:57:10.16
そんな面倒なことするよりsvnでロックかける方が便利だよ

170デフォルトの名無しさん2014/03/10(月) 14:09:31.22
svnでロックかけるために、
リポジトリを別ディレクトリに作って
そこにチェックインしてとかやるの?
面倒くさい。

gitで管理するの必要なのはgit init。これ一つだけだよ。
そうするだけで、ただのディレクトリがgit管理ディレクトリになる。

171デフォルトの名無しさん2014/03/10(月) 15:02:36.91
制限が必要ならgitoliteだかそんなのいくつかあるだろ

172デフォルトの名無しさん2014/03/10(月) 15:12:46.90
>>150
釣りかマジかわからん...

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

で、部分チェックアウトができる SVN のロック方式はどっちと思ってるんだ?

173デフォルトの名無しさん2014/03/10(月) 15:14:06.52
>>154
>>144 みてわからないなら、諦めてくれ。

174デフォルトの名無しさん2014/03/10(月) 15:15:30.69
>>166-167
はいはい、git ってすごいなー

これでいい?(w

175デフォルトの名無しさん2014/03/10(月) 15:17:46.72
>>174
いや良くない。欲しいのは論理的な反論。
それ以外は負け犬の遠吠えにしか見えないから。

176デフォルトの名無しさん2014/03/10(月) 15:18:19.61
>>173

>>144なら普通にgitでもできるよ。
これで問題解決したよね。

177デフォルトの名無しさん2014/03/10(月) 15:21:16.58
>>172
部分チェックアウトとロックには何も関係がない。

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

でも優れいている楽観的ロックがあれば
わざわざ劣った悲観的ロックを使う必要がない。

178デフォルトの名無しさん2014/03/10(月) 15:25:06.58
>>171
> gitolite

ブランチをうまく使えばいいかと思ったけど、見せないって言うのは無理なんだな。
まあ各自がリポジトリ自体を持ってしまう git だと難しいし、そもそも OSS だと必要性は薄いからなぁ。

179デフォルトの名無しさん2014/03/10(月) 15:26:38.21
>>178
話し聞いてる?

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

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

なんどでも言うよ?

180デフォルトの名無しさん2014/03/10(月) 15:27:28.08
>>176
見せないこともできるの?
リポジトリを分けることについては、>>148 の後半見てね。

181デフォルトの名無しさん2014/03/10(月) 15:27:33.91
ブランチを使うという発想自体が
すでに間違ってるよね。

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

こういうのも「技術力」だからね。

182デフォルトの名無しさん2014/03/10(月) 15:29:55.85
>>180
リポジトリを分ければもっと柔軟に管理できる。

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

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

まあ、君の技術が追いつくまではこれ使っていればいいんじゃない?
俺からすれば不便だけどさ。あれもできないこれもできない。

183デフォルトの名無しさん2014/03/10(月) 15:32:57.11
>>177
前半は >>150 にアンカーしてくれ。

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

これは、バイナリーファイル用だよ。
ちなみにロックは他人でもはずせる。
どちらかと言うと、編集してますよと言うコミュニケーションのためのフラグみたいなもんだよ。

184デフォルトの名無しさん2014/03/10(月) 15:35:31.69
ロックを他人が勝手に外したら
意味ないだろw

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

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

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

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

185デフォルトの名無しさん2014/03/10(月) 15:36:21.04
>>183
> 前半は >>150 にアンカーしてくれ。

意味不明。

なんで自分で自分にレスしないといけないのか。
お前に言ってるんだよ。

186デフォルトの名無しさん2014/03/10(月) 15:36:51.11
Mercurialには、hglockエクステンションが有って、Subversionに近いロックが出来る。

187デフォルトの名無しさん2014/03/10(月) 15:39:45.39
>>181
なら >>144 を実現するための正しい方法を書いてくれ。
今のところ >>140-141 ぐらいしかやり方出てないようだけど?

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

だから、ディレクトリは特定ディレクトリを見せないって言う設定できるよね?
git でどうやるの?

188デフォルトの名無しさん2014/03/10(月) 15:43:36.98
>>184
> 取っていいですかーってわざわざ電話するのか?

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

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

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

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

君にはそう思えるんだろうね。

189デフォルトの名無しさん2014/03/10(月) 15:49:23.47
>>185
ん?
自分がなに書いたのかわかってる?

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

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

まさか、本人とはね (w

190デフォルトの名無しさん2014/03/10(月) 16:23:13.92
誰か、bzr-gitとかsvn-gitの乗り換えチャートでも作ってくれたりしないもんかな。

191デフォルトの名無しさん2014/03/10(月) 17:16:41.02
bzrなんか誰が使ってんの?w

192デフォルトの名無しさん2014/03/10(月) 17:20:39.54
>>191
GNU信者でしょ

193デフォルトの名無しさん2014/03/10(月) 17:21:18.71
>>187
> だから、ディレクトリは特定ディレクトリを見せないって言う設定できるよね?
> git でどうやるの?

お前根本的な所がわかってないじゃないか。
gitでもディレクトリ使ってるんだよ。
gitはディレクトリ+αと考えればいい。
だからディレクトリでできることは全てgit使っていても出来る。

194デフォルトの名無しさん2014/03/10(月) 17:23:34.52
たぶん、単なるディレクトリが
そのままgitリポジトリになるってことが
あまりにも(その人にとって)革新的なことであり
信じられないんだと思う。

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

ディレクトリでできることはすべて
gitでもできるんだよ。

195デフォルトの名無しさん2014/03/10(月) 17:26:12.69
>>193-194
ご託はいいから、具体的なやり方書いて。

196デフォルトの名無しさん2014/03/10(月) 17:44:57.14
>>195
だから普通のディレクトリと全く同じやり方だよ。
これでわからないの?

197デフォルトの名無しさん2014/03/10(月) 18:36:20.57
先ほどからやたらとgitを否定する方がいらっしゃいますが、git使えなくて
後輩にバカにされた腹いせに書き込んでるのでしょうか?
git脳なんて言ってるけどgit使えない脳の方が問題ですね。

198デフォルトの名無しさん2014/03/10(月) 18:42:40.39
bazaar脳がemacsはgitに以降しそうだから焦ってるんだろ

199デフォルトの名無しさん2014/03/10(月) 19:05:48.64
>>196
それ君が設定してから push して外注さんが clone したら、指定したフォルダは外注さんに見えなくなるの?
まさか、ローカルで見えないから OK とか恥ずかしいこと言ってないよね?

>>197
ごめんな、git 普通に使ってるんだわ。
でも、他も使ってるから粗が見えちゃうんだな。
まあ適材適所なんだが、この手の奴はあまりバラバラにあっても管理がめんどいから、可能なら統合したいんだな。

200デフォルトの名無しさん2014/03/10(月) 19:21:31.31
じゃぁ、いいとこ取りのバージョン管理システムを新たに開発すればいいじゃん。

201デフォルトの名無しさん2014/03/10(月) 23:36:11.36
なんか伸びてるとおもたら荒れてんのぉ

202デフォルトの名無しさん2014/03/11(火) 00:53:39.84
部分チェックアウトは必要だわ
Android Studio 用のプロジェクトがコミットされたリポジトリからチェックアウトして、
Eclipse の プロジェクトで使う場合とか
assets ディレクトリを部分的に別々のリポジトリからチェックアウトしておくとか
面倒だから一つのリポジトリで複数のプロジェクトを管理とか
どう考えても部分チェックアウトは必須機能

203デフォルトの名無しさん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かなんか使ってるとかいう話を見た気がする

205デフォルトの名無しさん2014/03/11(火) 02:49:32.38
いつも思うんだが、喧嘩腰じゃないと話せない人がいるのはなんなんだ・・・
議論の一部に自分に取って有意義な話があってその辺りについて詳しい話が聞きたいと思っても
喧嘩腰な人が出てくるとまったく議論にならなくなる、というか聞く気すら起きなくなる

206デフォルトの名無しさん2014/03/11(火) 05:17:40.62
>>199
なんで普通のディレクトリではできないことの話をしてるんだ?

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

お前が言ってるpushやらcloneなんてのは普通のディレクトリでは出来ないことだ。
そんなことをしたいなら、ディレクトリを使うな(gitを使え)という話になる。

207デフォルトの名無しさん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?をできる。

部分チェックアウトで頑張るよりも、はるかにスマートな方法だ。

208デフォルトの名無しさん2014/03/11(火) 07:41:35.95
>>197
git使えない人は多いと思うよ
プログラマーでもgit理解出来ない人多いんだから、営業職の人にgitを無理強い出来ないね

209デフォルトの名無しさん2014/03/11(火) 07:44:32.68
営業職の人には普通にファイルを保存してもらって
分かる人がgitで管理すればよい。

まさかgit使えないなんて言うんじゃないだろうな?
それ技術者なはずなのに、営業職レベルってことだぞw

210デフォルトの名無しさん2014/03/11(火) 07:52:01.12
>>201
別に荒れてないよ、git 脳が勝手に暴れて勝手に玉砕しただけ (w

211デフォルトの名無しさん2014/03/11(火) 07:53:32.10
なるほど、ということにしたい奴が荒らしていたわけか。

212デフォルトの名無しさん2014/03/11(火) 08:04:16.45
>>206
はあ?
>>144 をやりたいって話なのは理解してるんだよね?
ファイシステム云々は >>179 とかが言い出した話だよ?
俺は >>144 が git でできるって言うならやり方示して、って言ってるだけ。
まさか、これがそのまま来るとは思わんかったわ (w
> ローカルで見えないから OK とか恥ずかしいこと言ってないよね?

213デフォルトの名無しさん2014/03/11(火) 08:07:55.75
>>212
> プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ?
やりたいのはこれだよね?
なんども答え出てると思うけど、

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

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

submoduleを使うことで、プロジェクトの一部を
別リポジトリにすることだって可能。

214デフォルトの名無しさん2014/03/11(火) 08:08:11.18
>>211
もうみんな話変えようとしてるよ?
まだ、恥ずかしいレス続けるの? (w

215デフォルトの名無しさん2014/03/11(火) 08:10:13.16
意訳

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

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

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

お前のレスは恥ずかしいんだ。 みんなも同調してよ!

216デフォルトの名無しさん2014/03/11(火) 08:15:43.08
>>213
> なんども答え出てると思うけど、

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

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

だからそのやり方書いてよ。

217デフォルトの名無しさん2014/03/11(火) 08:16:35.24
>>215
まだやるの? (w

218デフォルトの名無しさん2014/03/11(火) 08:20:49.49
>>216

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

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

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

219デフォルトの名無しさん2014/03/11(火) 08:21:23.81
都合の悪いレスは見えないんだろ?
本気でそんな人がいるとはね。

220デフォルトの名無しさん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 サーバーはインストールされているということです。

221デフォルトの名無しさん2014/03/11(火) 08:30:42.77
gitサーバーの一つがgithubだといえば、
馬鹿にもわかるかねぇ。

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

さすがに「githubの使い方を教えてよ」は
技術者として恥ずかしくて言えないだろう。

222デフォルトの名無しさん2014/03/11(火) 08:44:47.35
なんか荒れてると思ったら炎上学習法やってる奴が居るのか…

223デフォルトの名無しさん2014/03/11(火) 08:46:12.56
うるさい。そのやり方書いてよ。

224デフォルトの名無しさん2014/03/11(火) 08:54:37.15
svnでいいな

225デフォルトの名無しさん2014/03/11(火) 08:57:34.91
svnの壁ってやつかね。その先を知らない人が
満足する。

226デフォルトの名無しさん2014/03/11(火) 09:02:25.87
gitはどちらかと言えば、開発者のための道具だからね。
管理者のための道具じゃない。

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

svnで満足しているのは、ただの管理者でしょ?
ソース貰って、その日付だけわかればいいような、そんな人。
だから日付バックアップでも成り立つ。
開発者とは違って貰ったものを修正なんかしないからね。

227デフォルトの名無しさん2014/03/11(火) 10:01:47.42
程度によるよ
多人数で開発して細かくdiffを取ってpatchを当てる続けるようなソースコードの管理する場合にはgitやmercurialの方が向いてる
そうじゃない場合はsubversionの方が有利な事もある
既出の部分チェックアウトやファイルロック

228デフォルトの名無しさん2014/03/11(火) 10:04:45.01
>>209
gitを理解出来ないプログラマーはたくさんいるよ
linuxのカーネル開発してるような優秀な人揃いのプロジェクトならいいけど、
そうじゃない低レベルなプロジェクトもたくさんあるのが現実

229デフォルトの名無しさん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ではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

230デフォルトの名無しさん2014/03/11(火) 10:42:06.63
>>229
訂正。
> chgrp -R /proj/src/lib

chgrp -R /proj/src/lib lib-dev-group

231デフォルトの名無しさん2014/03/11(火) 11:01:28.32
>>228
gitすら理解できないってよほどアホか覚える気が全くないかだろう
そんな奴をプログラマーと呼べるのか?最低限持っているべき知識だろ

もう世界中で使われているから
分からない事があってもググれば大抵の事は解決するし

232デフォルトの名無しさん2014/03/11(火) 11:24:53.82
>>229-230
まあそう言うこと。
たぶんわかってるけど git が劣ってるなんて許せねーって言う奴とよくわからんけど煽ってやれ、っー奴が半々ぐらいかな (w

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

まあ当面 svn + git (svn) で行くわ。

233デフォルトの名無しさん2014/03/11(火) 12:18:30.59
>>229
>サーバーの OS 上でファイルシステムのパーミッションを設定するとよいでしょう。
なんだから
そこまでやったらgitでは何もやることないんじゃないの

234デフォルトの名無しさん2014/03/11(火) 12:34:05.41
>>233
ネタなのかマジで言ってるのかよくわからん (w
ひょっとしてベアリポジトリの存在を知らないのか?

235デフォルトの名無しさん2014/03/11(火) 12:37:56.06
freebsdの開発チームはがsubversionを採用したんだよな
理由はsubversionの方が合ってるからって

236デフォルトの名無しさん2014/03/11(火) 12:39:49.82
>>233
だから具体的にどうやるか書け

237デフォルトの名無しさん2014/03/11(火) 12:47:54.53
いやおれhg使いだし
サブモジュールのディレクトリにパーミッション設定して終わりじゃないのか

238デフォルトの名無しさん2014/03/11(火) 12:58:42.60
>>237
何いってんの?

239デフォルトの名無しさん2014/03/11(火) 13:03:47.19
煽るだけのは邪魔だからどっか行けよ

240デフォルトの名無しさん2014/03/11(火) 13:32:01.32
>>235
Linux の世話になんかならんぞ、っーのもあるんじゃね?

まあ便利ならなんでも取り込む Linux/git に対して、ポリシーに沿わないものは取り込まない FreeBSD/Subversion って感じかな。

241デフォルトの名無しさん2014/03/11(火) 13:36:20.76
いやおまえこそ

242デフォルトの名無しさん2014/03/11(火) 13:42:31.53
GPLを排除したいFreeBSDにしてみれば
メジャーなDVCSのGit、Hg、Bzrが軒並みGPLな現状じゃ
Apacheライセンスな非DVCSのSubversionを選ぶざるを得ないってとこか

243デフォルトの名無しさん2014/03/11(火) 13:46:51.73
>>239
良く分かってないのに適当な回答かまして場をかき乱す奴よりはまし。

244デフォルトの名無しさん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

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

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

利点
ファイルベースのリポジトリの利点は、シンプルであることと既存のファイルアクセス権や
ネットワークアクセスを流用できることです。チーム全員がアクセスできる共有ファイルシステムがすでに存在するのなら、
リポジトリを用意するのは非常に簡単です。ベアリポジトリのコピーをみんながアクセスできるどこかの場所に置き、
読み書き可能な権限を与えるという、ごく普通の共有ディレクトリ上での作業です。

245デフォルトの名無しさん2014/03/11(火) 14:07:09.69
linuxっていつまで経ってもaclベースのアクセス制御普及しないよな

246デフォルトの名無しさん2014/03/11(火) 14:08:14.88
>>244
> この欠点はdev-groupはgitを使えるが、それ以外はgitを使えないということと

どういうこと?co-dev1がgitを使えないんだったら意味ないじゃん

247デフォルトの名無しさん2014/03/11(火) 14:11:14.81
>>244
なんだローカルの話か。なら最初から
cd proj
git init
って言えば何を言いたかったのか全員がわかったのに。

ちなみに、お前以外は全員リモートサーバを想定してると思うよ。

248デフォルトの名無しさん2014/03/11(火) 14:16:55.82
>>244
俺gitの知識はほぼゼロなんだけど、それでco-dev1はgit clone/push/pullのどれも支障が無いのか?

249デフォルトの名無しさん2014/03/11(火) 14:17:33.84
>>246

> どういうこと?co-dev1がgitを使えないんだったら意味ないじゃん

dev-groupはgitつかえるよ?
git使いたいなら、最初からディレクトリは
ダメですねって話ですよね?

だ〜か〜ら、共有ディレクトリを使う方法(>>229)は
欠点があるって言ってるんだよ。

普通にgitを使えよ。
共有ディレクトで権限管理するのはやめなさい。
つまり、>>229のやり方をやめなさいってことだよ。

250デフォルトの名無しさん2014/03/11(火) 14:19:33.04
>248
> 俺gitの知識はほぼゼロなんだけど、それでco-dev1はgit clone/push/pullのどれも支障が無いのか?

共有ディレクトリを使った方法(>>229の方法)を使っている以上無理。

最初っから、共有ディレクトリを使った方法(>>229)は欠点だって言ってるの。

でもgitはただのディレクトリだから、ディレクトリを使った方法(>>229)でも
できるという話。git化することで何も失われていない。

251デフォルトの名無しさん2014/03/11(火) 14:20:30.61
>>247
全員がとかいってるけど、
実は「お前が」だよ。

お前一人がわからなかった。
勝手に他人もいっしょにするなよ。

252デフォルトの名無しさん2014/03/11(火) 14:32:12.88
>>250
え?>>144に対して、

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

> 共有ディレクトリを使った方法(>>229の方法)を使っている以上無理。
ってどういうこと?

> でもgitはただのディレクトリだから、ディレクトリを使った方法(>>229)でも
> できるという話。
できるって何が?

> git化することで何も失われていない。
ちなみに、>>244のディレクトリ構成を実際に作って、co-dev1でgit cloneしてみたら、/proj/src/libも取得できちゃったんだけど。
俺はgitの知識がほぼゼロなんで、なにか間違ってるかもしれないけど。

253デフォルトの名無しさん2014/03/11(火) 14:38:57.36
>>251
お前一人が勘違いしている可能性は考慮しないのか

2542522014/03/11(火) 14:43:10.33
ちなみに、俺がやったこと。
/path/to/proj以下に>>244のディレクトリ構成を作って、
cd /path/to/proj
git init
git add *
git commit -a
su - co-dev1
cd ~/src
git clone /path/to/proj
これで、proj/src/lib以下が取得できてしまったんだが、これを取得できないようにするにはどうしたらいい?

255デフォルトの名無しさん2014/03/11(火) 14:46:33.16
>>252
お前頭悪いなw

共有ディレクトリを使った方法では、
gitを使うことに制限が出る。

無理というのは、その制限の話だ。

gitを使いたくなっただろ?
ちゃんと使おうと思うなら
共有ディレクトリ(>>229)はやめだ。

だが共有ディレクトリ程度でできるレベルであれば
>>244を使えば良い。

256デフォルトの名無しさん2014/03/11(火) 14:48:04.93
>>254
お前は、パーミッションも読めないのかw

>>244のdrwxrwx--x とかその後のdev-groupとか
意味わかってるか? 本気で馬鹿なのか?

2572522014/03/11(火) 14:49:00.12
>>255
ちょっと何を言いたいのか良くわからない。

> 無理というのは、その制限の話だ。
要するに、
>>144
> プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ?
はできるの?できないの?

> gitを使いたくなっただろ?
いや、svnで満足してるし。
gitはgithubでcloneするくらいでいい。

258デフォルトの名無しさん2014/03/11(火) 14:53:48.97
>>256
> >>254
> お前は、パーミッションも読めないのかw

再現できてると思うけど。

ls -lR
.:
合計 4
drwxrwxr-x 4 user1 grp1 4096 3月 11 14:20 2014 src

./src:
合計 8
drwxrwxr-x 2 user1 grp1 4096 3月 11 14:20 2014 app
drwxrwx--- 2 user1 wheel 4096 3月 11 14:20 2014 lib

./src/app:
合計 4
-rw-rw-r-- 1 user1 grp1 6 3月 11 14:20 2014 aaa.c

./src/lib:
合計 4
-rw-rw-r-- 1 user1 wheel 8 3月 11 14:20 2014 bbb.c

uid=500(usr1) gid=500(usr1) 所属グループ=500(usr1),10(wheel),505(grp1)
uid=503(usr2) gid=507(usr2) 所属グループ=507(usr2),505(grp1)

259デフォルトの名無しさん2014/03/11(火) 14:54:41.80
>>244
ねえねえ、マジで言ってるの?
git 脳って git には詳しいのかと思ってたら、単なるアホだったのか (w

それ、自分に対する権限しか設定してないから、clone されたら丸見えだよ。
もし、反論するなら事前にベアリポジトリについてググってこい。
まあ、ググって理解したら恥ずかしくて出てこれないと思うが。

260デフォルトの名無しさん2014/03/11(火) 14:58:24.01
はぁ? なんでcloneするんだよ。
そこから間違ってるじゃないかw
cloneした時点でお前の間違いが明らかになってるんだが。

ファイルベースのリポジトリは最初に用意する人が
cloneするのみ。ファイルベースのリポジトリは
そのディレクリをみんなで共有する仕組みだよ。

最初っからディレクトリを使った方法と
全く一緒だって言ってるじゃないか。

261デフォルトの名無しさん2014/03/11(火) 15:00:06.59
>>260
複数人で作業すること前提なんですが

262デフォルトの名無しさん2014/03/11(火) 15:00:30.30
あたりまえだけど、

drwxrwx--x dev-group:dev-group /proj/.git ← gitデータディレクトリ

こうなってるので、dev-group以外の人はgit cloneできない。
なぜならファイルそのものにアクセス出来ないから。

263デフォルトの名無しさん2014/03/11(火) 15:01:37.98
>>261
ディレクトリを共有していれば、
普通に複数人で作業できますが?

gitはただのディレクトリなんだから
(gitとして制限をうけるだけで)
全く同じように共有できるって気づかない?

2642522014/03/11(火) 15:01:47.99
>>260
> はぁ? なんでcloneするんだよ。
いや俺マジでgitに詳しくないんだけど、cloneってsvnで言えばsvn coじゃないの?
ワーキングコピーを作る方法。

265デフォルトの名無しさん2014/03/11(火) 15:02:29.48
あ、もしかして>>244のgitの公式説明

「ファイルベースのリポジトリ」が
一つのディレクトリをみんなで共有する方法だって
気づいていない?

266デフォルトの名無しさん2014/03/11(火) 15:03:59.48
>>264
> いや俺マジでgitに詳しくないんだけど、cloneってsvnで言えばsvn coじゃないの?
> ワーキングコピーを作る方法。

本当にに詳しくないなwwwwwwwwwwwwwwww


gitにはsvnみたいに、ワーキングコピーとリポジトリなんて
二つにディレクトリに別れてないの。

普通のディレクトリを、場所を変えずにそのままで
gitリポジトリに変えられちゃうんだよ。

き・そ・ち・し・き

267デフォルトの名無しさん2014/03/11(火) 15:04:58.55
まさかとは思うが、複数人が同じサーバにログインして、同じディレクトリ下で開発するとか思ってないだろうな?

268デフォルトの名無しさん2014/03/11(火) 15:06:59.00
proj/src/lib以下はリポジトリ分けて
projのサブモジュールにするんでしょ?
何かおかしなこと言ってるヤツいるけど

2692522014/03/11(火) 15:07:27.36
>>266
> gitにはsvnみたいに、ワーキングコピーとリポジトリなんて
> 二つにディレクトリに別れてないの。
話が全然かみ合わないんだけど、gitだって全員の変更を一つにまとめる中央リポジトリ的なものがあるんじゃない?
俺の薄い知識だと、それとローカルを同期させたり差分を取り込んだりするのにpull/pushがあると思ったが。

> 普通のディレクトリを、場所を変えずにそのままで
> gitリポジトリに変えられちゃうんだよ。
いや、その程度は知ってるって。>>252に手順示したじゃん。

270デフォルトの名無しさん2014/03/11(火) 15:08:31.10
>>264
mkdir hogehoge ← ディレクトリ作りました。
cd hogehoge ← ディレクトリに移動しました。
touch a ← まあ適当にファイルを作ってみましょう。

-------- ここまでgitとは無関係の作業 -----------

git init ← hogehogeがgitリポジトリになりました。

-------- これだけでgit化終わり -----------

git checkout -b branch1 ← ブランチ1に切り替え
git add a ←ファイル追加
git commit ← ファイルコミット

-------- なんでもできます -----------

gitを始めるのにcloneなんて要りません。

271デフォルトの名無しさん2014/03/11(火) 15:08:40.05
>>268
> proj/src/lib以下はリポジトリ分けて
> projのサブモジュールにするんでしょ?

そんなことしなくても出来ると言って暴れてる奴がいるんだよ

272デフォルトの名無しさん2014/03/11(火) 15:09:29.01
>>270
一人の場合はそれでいいが、今は複数人で開発するときの話だ

273デフォルトの名無しさん2014/03/11(火) 15:09:57.21
>>267
> まさかとは思うが、複数人が同じサーバにログインして、同じディレクトリ下で開発するとか思ってないだろうな?

それ、共有ディレクトリ(>>229)を作ったやり方の話話をしてるんだよね?

229 名前:デフォルトの名無しさん[sage] 投稿日: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ではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

274デフォルトの名無しさん2014/03/11(火) 15:11:37.04
>>272

だから複数人で共有しろよ、gitディレクトリを。

>>229で話しているのはそういうことだよ。

275デフォルトの名無しさん2014/03/11(火) 15:13:14.93
底辺だとそんな開発してるんだな
勉強になるわ

276デフォルトの名無しさん2014/03/11(火) 15:14:29.68
複数人で開発したことないんだと思うよ

277デフォルトの名無しさん2014/03/11(火) 15:14:43.02
共有ディレクトリを使ってパーミッションでアクセス制限とかw
>>229は前時的な開発してるな。

さっさとgit化すればいいのにw

278デフォルトの名無しさん2014/03/11(火) 15:15:24.86
>>229のやり方って複数人で開発できるの?

できるならgitでも同じことやれば出来るってわかるけど。

279デフォルトの名無しさん2014/03/11(火) 15:19:13.77
>>229のやり方でもグループを適切に設定すれば複数人で開発できるよ。
(もちろんgitのディレクトリを共有するやり方でもね)

ただ、それだと共有ディレクトリを使ったレベルまで
開発が不便になるから、この場合は普通にやるなら
サブモジュールを使って管理するべきことだろう。

今話してるのは、git化しても共有ディレクトリを使ったやり方はできるから
gitなし共有ディレクトリと何も変わらないということ。

2802292014/03/11(火) 15:22:17.78
単なるファイルシステム上のアクセス制限であれば、>>229のように設定すれば実現できるが、
それをgitでできるのか?というのが>>229の趣旨。

もちろん、単一ディレクトリのアクセス制限ができても、複数人では開発できない。

281デフォルトの名無しさん2014/03/11(火) 15:24:20.43
??279
は?この人何言ってるの?

282デフォルトの名無しさん2014/03/11(火) 15:25:19.98
その辺は現場によってまちまちだろうね
メンバーごとにプロジェクトフォルダをコピーするだけで完全に動作する環境の方がいいが、そこまで開発環境を作り込めない現場も多い

283デフォルトの名無しさん2014/03/11(火) 15:27:00.67
一人だけ完全にずれてることにまだ気づかない奴

284デフォルトの名無しさん2014/03/11(火) 15:28:42.86
そもそも最初からgitだとsubmodule使うしかないねって話なのに。

285デフォルトの名無しさん2014/03/11(火) 15:50:06.26
ディレクトリ共有とか、もう何年もその発想忘れてたわ

286デフォルトの名無しさん2014/03/11(火) 16:10:13.28
平均的プログラマーの7割は、gitを理解できない。
これが現実。

OSS開発者の事じゃないぞ。サラリーマン開発者の事だ。

287デフォルトの名無しさん2014/03/11(火) 17:39:26.04
>>283
もうわざとでしょ、彼にとってはバージョン管理なんかより git でもアクセス制御ができると言えることが最重要なんだよ、例えそれに意味がなくても (w

>>284
現状ではそれが一番みたいですな。

>>285
特に SCM 使ってたら直接共有する必要ないしな。

288デフォルトの名無しさん2014/03/11(火) 17:44:33.56
>>287
やっぱり気づいてないみたいね。

はっきり言うと、わかってないのはお前。

289デフォルトの名無しさん2014/03/11(火) 17:45:30.23
>>287
> 現状ではそれが一番みたいですな。
それは最初に俺が言ったことだろw

140 名前:デフォルトの名無しさん[sage] 投稿日:2014/03/10(月) 06:24:12.14
>>139
えとさ、どういうディレクトリ構成なのさ?
それ言ってくれんとわからん。

なんか、話を聞いていると、一つのディレクトリのあちこちに、
社内に公開できる部分、出来ない部分があってごちゃごちゃ
混ざってるように思えるんだけど?

もしそうだとしたら、それ人為的ミスで間違って
ファイルわたしてしまう可能性があるから修正した方がいいよ。

簡略化するとこういう感じ
root
├メインプロジェクト(自社開発)
└外注さんに任せるライブラリ
もしくは
root
├メインプロジェクト(外注さんと共同開発)
└自社専用ライブラリ

ライブラリ部分はgitで言えばsubmoduleという機能を使えばいい。
submoduleは外部のリポジトリを自分のリポジトリに埋め込む機能。
もちろん別々のリポジトリとして扱える。

submoduleはルート直下にしか置けない。
メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、
そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。

290デフォルトの名無しさん2014/03/11(火) 17:48:26.46
最初に俺がサブモジュールというちゃんとした答えを言って
サブモジュールを使うより劣るけど、git+共有ディレクトリでもやれなくてはないよ。
(だから共有ディレクトリでやれるアクセス制限はもちろん出来る)
って話をしているのに、わかってないんだな。やっぱり馬鹿か。

291デフォルトの名無しさん2014/03/11(火) 17:54:08.80
もうだれが誰やら

292デフォルトの名無しさん2014/03/11(火) 17:57:25.88
>>288, >>290
きみ、もういいから (w

>>289
うん、そうだよ。
でも、リポジトリ構成変えないといけないからうちでは採用できないって書いてある。
一番マシだからと言って使えるかどうかは別の話でしょ?

293デフォルトの名無しさん2014/03/11(火) 18:02:02.36
>>290
> サブモジュールを使うより劣るけど、git+共有ディレクトリでもやれなくてはないよ。
いや、やれないじゃん

294デフォルトの名無しさん2014/03/11(火) 18:07:20.75
ファイル共有なんて論外。

295デフォルトの名無しさん2014/03/11(火) 18:08:11.80
そこは外注使うと決まった時点でリポジトリの構成を変えるべき
手続きが面倒とかは甘え

296デフォルトの名無しさん2014/03/11(火) 18:14:57.09
「共有ディレクトリでやれるアクセス制限」って意味わかんないんだけど。
何のこと?

297デフォルトの名無しさん2014/03/11(火) 18:16:52.29
>>296
ディレクトリのパーミッションのこと言ってるらしいよ。

だから当たり前だけどgitでもディレクトリを共有すれば同じこと出来る。

298デフォルトの名無しさん2014/03/11(火) 18:17:35.41
>>292
> でも、リポジトリ構成変えないといけないからうちでは採用できないって書いてある。

え? どこに?

299デフォルトの名無しさん2014/03/11(火) 18:18:34.93
>>295
馬鹿だからファイル共有を使ったやり方しかできないんです。
パーミッション設定で精一杯なんです。

300デフォルトの名無しさん2014/03/11(火) 18:22:13.47
>>297
> ディレクトリのパーミッションのこと言ってるらしいよ。
わかんないのはそっちじゃなくて、「共有ディレクトリ」の方。
普通、共有ディレクトリというと、ネットワーク上に存在するディレクトリ/フォルダを指すことが多いけど、そのことかな?
で、そこのアクセス制限と個々人の開発環境とはどうリンクするのかがわからない。

301デフォルトの名無しさん2014/03/11(火) 18:26:06.32
>>300
複数のユーザーで共有ディレクトリを使いたい
http://www.itmedia.co.jp/help/tips/linux/l0461.html
> Linux上で複数のユーザーが使えるようchmod 770などと
>指定するディレクトリを用意しても,それぞれのユーザーが
>書き込んだファイルやディレクトリは,他のユーザーが書き換えることができない。

302デフォルトの名無しさん2014/03/11(火) 18:28:41.51
>>301
そういう意味の「共有」だとしたら、個々人の開発環境とはどうリンクするの?

303デフォルトの名無しさん2014/03/11(火) 18:28:56.58
あぁ、個人ごとにホームディレクトリに
ローカルリポジトリを持つという発想ではなくて
サーバーにある一つのディレクトリを
みんなで共有して開発するやり方か。
グループ権限とか設定して。

でも同じ設定すればgit使いながら
共有ディレクトリ使えるんじゃねーの?
ってそういう話をしていたわけか。やっと分かった。

304デフォルトの名無しさん2014/03/11(火) 18:31:23.02
sticky bitのことを知ってるのは俺だけだと思ってそうw

305デフォルトの名無しさん2014/03/11(火) 18:32:26.65
>>303
> サーバーにある一つのディレクトリを
> みんなで共有して開発するやり方か。
そのやり方が全く想像できないんですが。

306デフォルトの名無しさん2014/03/11(火) 18:32:50.57
>>302
個々の人の開発環境っていきなり何の話。
スレを「開発環境」検索しても
無関係なものしかヒットしないんだけど。

プロジェクトファイルだけを共有するんだから
個々の人の開発環境は、個々の人でしょ?
(つまりホームディレクトリに設定ファイルがある)
好きなエディタ使えるよ。そういう話だよね?

307デフォルトの名無しさん2014/03/11(火) 18:33:48.41
>>304
そんなのだれでも知ってる。

308デフォルトの名無しさん2014/03/11(火) 18:34:32.24
>>305
> そのやり方が全く想像できないんですが。

そのやり方っていうか、そもそもグループ権限を理解してないよね?

309デフォルトの名無しさん2014/03/11(火) 18:37:15.19
gitを知らないどころか
グループ権限までしらん人がいるのか。
下には下がいるもんじゃw

310デフォルトの名無しさん2014/03/11(火) 18:42:01.17
>>295
なんでツールのためにそんな苦労するの?
SVN ならちょっと設定するだけですよ。

>>298
>>148 の後半

311デフォルトの名無しさん2014/03/11(火) 18:42:47.49
>>310
なんでSVNの話?
共有ディレクトリの話でしょ?

312デフォルトの名無しさん2014/03/11(火) 18:43:39.11
>>304
なんか昔に聞いたことあったけどすっかり忘れてたので、ググってみた
忘れたままでいい機能だった...

313デフォルトの名無しさん2014/03/11(火) 18:46:22.62
>>310 >>311
SVNで一つのディレクトリを複数の人で共有して
開発してるんでしょ? なんでそんなことをしているのかしらんけど。

その程度のやり方で満足しているなら
gitでも同じようにすればいいじゃん?
gitでも一つのディレクトリを複数の人で共有して使えるよ。
不便だけどね。(SVNでも不便なはずだが?)

314デフォルトの名無しさん2014/03/11(火) 18:47:18.73
>>311
すまん、共有ディレクトリの話なら誤レスだ、無視してくれ。

315デフォルトの名無しさん2014/03/11(火) 18:48:54.26
>>312
お前それは恥ずかしいセリフだぞ。
たとえば、sudoコマンドには sticky bitがついてる。
ついてるからこそ一般権限で実行できるわけだ。

ただ今の話はsticky bitよりもSGIDの方が重要なんだけどな。
>>304はちょっと無知っぽいw

316デフォルトの名無しさん2014/03/11(火) 18:49:39.77
>>313
> SVNで一つのディレクトリを複数の人で共有して開発してるんでしょ?

ねえねえ、どこからそんな変な解釈思い付いたの? (w

317デフォルトの名無しさん2014/03/11(火) 18:50:08.29
SVNで一つのディレクトリを複数の人で
共有して開発ってマジでやってんの?
ちょっとその発想はなかった。

318デフォルトの名無しさん2014/03/11(火) 18:51:39.62
>>315
それは setuid だよ (w

319デフォルトの名無しさん2014/03/11(火) 18:51:42.41
>>316
それは>>229だな。しっかりやり方を説明しちゃってる。

229 名前:デフォルトの名無しさん[sage] 投稿日: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ではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

320デフォルトの名無しさん2014/03/11(火) 18:54:52.43
>>319
あぁ、ほんとだ。グループで共有するって
話の発端はそいつなのね。

で、まじでこんなやり方でSVN使ってんの?

321デフォルトの名無しさん2014/03/11(火) 19:03:19.56
>>315
sudoとかで立ってるのは04000でSet-user-id bit
Sticky bitと言われるのは01000

322デフォルトの名無しさん2014/03/11(火) 19:07:36.74
>>304

> 304 名前:デフォルトの名無しさん[sage] 投稿日:2014/03/11(火) 18:31:23.02
> sticky bitのことを知ってるのは俺だけだと思ってそうw

なんでここでsticky bitがでてくるの?

323デフォルトの名無しさん2014/03/11(火) 19:13:14.84
>>319
それ SVN 関係ない
単なる説明用だろ

SVN はサーバー側で設定すれば見せたくないフォルダーとかはチェックアウトできなくなるからクライアント側で設定する必要がない

>>313 とかは玉砕した git 脳が同じ土俵に引きづりこもうとしてるだけだろ (w

324デフォルトの名無しさん2014/03/11(火) 19:14:10.07
> SVN はサーバー側で設定すれば見せたくないフォルダーとかはチェックアウトできなくなるからクライアント側で設定する必要がない

サーバー側で設定すればだろ?

同じことがgitでもできるってなんで考えられないの?

325デフォルトの名無しさん2014/03/11(火) 19:16:09.81
>>322
自分が知ってる一番難しそうな奴書いたんだろ。
まあ、>>315 みたいなアホが釣れたからちょっとは効果があったんじゃね? (w

326デフォルトの名無しさん2014/03/11(火) 19:16:27.40
ゲーム脳ってあるでしょ? あれ、ゲームやってる人の脳がおかしいって話だったけど、
よくよく聞くと、「ゲーム脳」といっている人の脳がおかしいって気づく。

自分が「ゲーム脳」とはこうである!と決めて
それが絶対正しいと思い込んじゃう。
論理的に考えれば、明らかに間違っていることを
指摘しても聞く耳持たなくなっちゃう。

git脳という単語を見た時、そう思ったよ。

327デフォルトの名無しさん2014/03/11(火) 19:18:48.85
>>324
> 同じことがgitでもできるってなんで考えられないの?

えっ、まだやるの?
仕組みが違うことぐらいは知ってるんだよね?
まあ、できると言うなら方法を具体的に書いてくれ。

328デフォルトの名無しさん2014/03/11(火) 19:19:52.02
お前らこれ以上スレを汚すのはやめろ

329デフォルトの名無しさん2014/03/11(火) 19:22:18.83
/.Jに集うLinuxヲタ達と同じ臭いがする
gitスレ行けばいいのに

330デフォルトの名無しさん2014/03/11(火) 19:29:18.86
>>326
自分が【「ゲーム脳」といっている人の脳がおかしい】と決めてそれが絶対正しいと思い込んじゃうんですね、わかります (w

論理的に考えればこの手のレスが返ってくることぐらいわかるだろうに...

331デフォルトの名無しさん2014/03/11(火) 19:37:04.02
>>327
やらなくていいよ。
サブモジュールを使えばいいって
答えが出てるんだから

332デフォルトの名無しさん2014/03/11(火) 19:40:41.99
だよな、サブモジュール使えばいいだけなのに
なんでこんなにぶつくさ言ってるんだろ?

333デフォルトの名無しさん2014/03/11(火) 19:48:49.23
>>330
俺、○○脳なんてひとことも言ってないけど?

○○脳って言っている奴ってあほだな−って
言ってるだけなんだけど。

334デフォルトの名無しさん2014/03/11(火) 20:06:23.63
>>333
誰かが君が○○脳なんて言ってるのか?

○○脳って言っている奴をあほだな−って言ってる奴ってバカだろって思われてるだけなんだけど (w

335デフォルトの名無しさん2014/03/11(火) 20:09:24.61
○○脳って言っている奴をあほだな−って言ってる奴ってバカって言ってる奴はバカだなw

336デフォルトの名無しさん2014/03/11(火) 20:22:31.76
以下リソース使い果たすまで無限ループ

これぐらいマならすぐ気づくよね (w

337デフォルトの名無しさん2014/03/11(火) 20:23:22.49
ループを始める奴はバカ。でいいだろ。

338デフォルトの名無しさん2014/03/11(火) 20:30:02.85
遅れて参加するバカ (w

339デフォルトの名無しさん2014/03/11(火) 23:33:26.18ID:AS7or27e
くそっ祭りに乗り遅れた

340デフォルトの名無しさん2014/03/12(水) 08:56:55.68ID:xZa9J+Yh
git脳とかruby脳とかは確かにいそうだな
というか、兼ねてそう

341デフォルトの名無しさん2014/03/12(水) 09:44:46.02ID:EfiLuccu
ということにしたいのですね

てゆーかrubyのリポジトリはsvnだし

342デフォルトの名無しさん2014/03/12(水) 12:41:26.93ID:F9SiziZl
>>341
> てゆーかrubyのリポジトリはsvnだし

別にそれは関係ないだろ
Linux でソフト作ってる奴がみんな git 使ってるわけないし

343デフォルトの名無しさん2014/03/23(日) 20:02:10.72ID:c9zQodrj
集中型も分散型も長所短所があるから、それぞれ使い分ければいいと思う。
いくつがある分散型のいずれを使うべきかは、もう少しふるいにかけられそうだけど

344デフォルトの名無しさん2014/03/24(月) 02:20:29.69ID:AMSnjzm1
ところで gif は「じふ」なのに、なんで git は「ぎっと」と発音するの?
おいらずっと「じっと」(GitHUBも「じっとはぶ」)かと思ってたんだが

char の「ちゃー」くらいには許される呼び方?

345デフォルトの名無しさん2014/03/24(月) 07:32:40.20ID:ioVgRUr7
>>344
giftをジフトと読むの?

346デフォルトの名無しさん2014/03/24(月) 09:30:08.86ID:XOzrhor0
作った人がぎっとと読むと規定しているからぎっと。

347デフォルトの名無しさん2014/03/24(月) 10:02:45.75ID:XUp8kLsg
gを硬音で読むか否かは単語次第じゃね?

348デフォルトの名無しさん2014/03/24(月) 11:56:40.64ID:ftyS+NcD
読まないパターンもあるよねgって
何にしても英語は1文字で色んな読み方させすぎなんだよなあ

349デフォルトの名無しさん2014/03/24(月) 12:49:27.70ID:XUp8kLsg
日本語だって外国人の耳には、ガ行の鼻濁音とか、nとngとmとか、
違って聞こえるらしい、とは聞くけど。

350デフォルトの名無しさん2014/03/24(月) 13:58:16.38ID:6jBkDFrJ
>>348
gh, oughなどは特例と見做すと、サイレントなgってないと思う。

いろんな発音と言えば、fish = Ghoti = 無音 ってネタがあるね。

351デフォルトの名無しさん2014/03/24(月) 16:54:24.35ID:a26hHntV
>>350
gnomeのgがサイレント

352デフォルトの名無しさん2014/03/24(月) 17:30:12.14ID:ftyS+NcD
paradigm
align
sign
foreign
gnome(地の精)
gnu(動物)

>>348 で本当に言いたかったのは英語のスペルと読み方とのパターンが多過ぎってほうだったりするが…済まないな分かりにくくて

353デフォルトの名無しさん2014/03/24(月) 17:31:20.91ID:wy6Yi8GY
音声会話しなければ読み方を間違っていようとどうということはない

354デフォルトの名無しさん2014/03/24(月) 18:34:50.84ID:6jBkDFrJ
あーごめん、自分でGhoti=無音って書いてたw

355デフォルトの名無しさん2014/03/24(月) 19:20:28.83ID:/srzAoX5
この板でgnuにgnomeって言ったら発音するほうだろ

356デフォルトの名無しさん2014/03/24(月) 20:25:59.17ID:M+aKCxbC
だからわざと地の精だの動物だの、単語の後ろに括弧書き入れてるんじゃないか

357デフォルトの名無しさん2014/03/25(火) 05:10:50.16ID:eBzwX2YU
>>345
んじゃお前はGIANTSをガイアンツとかギアンツって読むの?
って返しになるぜ


>>346
まぁそうだわな

358デフォルトの名無しさん2014/03/25(火) 21:09:31.60ID:KiqIKVFY
英単語の git から名付けられているんだから辞書引けよ。
発音の文句は英語に言え。

359デフォルトの名無しさん2014/03/25(火) 22:11:25.75ID:JLDIFaf/
give me dictionary

360デフォルトの名無しさん2014/03/28(金) 22:52:46.45ID:5jt9WDvZ
Word Excelでバージョン管理できないか探したら
以外とsvnが充実してた

My Docmentsの下を全部svnで管理してみる事にする

361デフォルトの名無しさん2014/03/28(金) 23:20:29.35ID:W/hCr5dM
gitで対応させてみてるけど差分が見れるだけで差分だけ保存できるわけでも
バイナリだけ変更されたファイルを更新から除外できるわけでもないからあまり意味なくないか
今のとこ文書は別のツール使わないならサブモジュールで別管理することでバージョンアップごとに
コードと違うスパンで不要な差分を捨てて圧縮できるようにするのがベストかなと思う

362デフォルトの名無しさん2014/03/29(土) 04:06:14.46ID:5pTO27a4
うちのvistaにはMy Docmentsないわ

363デフォルトの名無しさん2014/03/29(土) 16:22:17.08ID:vvSk+gJf
>>362
dir /ai

364デフォルトの名無しさん2014/03/29(土) 16:23:23.76ID:COOtOu/G
= dr / a

365デフォルトの名無しさん2014/03/29(土) 16:39:26.66ID:5pTO27a4
脱字に突っ込んでボケたんだけどわからなかったのか

366デフォルトの名無しさん2014/03/29(土) 16:43:09.78ID:vvSk+gJf
ごめんねアスペで

367デフォルトの名無しさん2014/03/29(土) 16:55:18.32ID:WP7oRJZ8
test

368デフォルトの名無しさん2014/03/29(土) 22:12:43.18ID:5lBv4fjg
progitレベルで分かりやすくsvnを説明してるサイトってない?

369デフォルトの名無しさん2014/03/30(日) 04:35:55.31ID:vSu4GC6v
githubって日本語化出来なかったっけ?

370デフォルトの名無しさん2014/03/30(日) 05:30:04.27ID:S+rtzMEf
これのこと?
GitHub in your language ・ GitHub
https://github.com/blog/679-github-in-your-language

371デフォルトの名無しさん2014/03/30(日) 07:28:31.43ID:vSu4GC6v
>>370
これって日本語化はフッターから設定出来るってこと?

372デフォルトの名無しさん2014/03/30(日) 16:29:46.25ID:aCLztA2m
日本語化なんて必要ないだろ
gitに限った話じゃないが

373デフォルトの名無しさん2014/03/30(日) 17:47:06.81ID:ER66GczB
日本語化したいって言ってるの

374デフォルトの名無しさん2014/03/30(日) 17:47:14.41ID:vSu4GC6v
>>372
そうですね。
おめでとうございます。

375デフォルトの名無しさん2014/03/30(日) 18:15:55.57ID:qidUF1O3
GitHubは多国語化をすすめようとしてたが、中止して英語オンリーに戻った
英語使えない奴はいらねえって方針です

376デフォルトの名無しさん2014/03/31(月) 06:05:41.54ID:Dx9xREGz
http://d.hatena.ne.jp/replication/20120321/1332338059
Word Execlはsvn
gitでこういうのみたことない

377デフォルトの名無しさん2014/03/31(月) 09:43:28.17ID:wgezm0yV
必要ないからな

378デフォルトの名無しさん2014/03/31(月) 11:06:34.75ID:la3eTEK/
ファイルのバージョン管理と
ソフト機能のバージョン管理の
違いを認識しろよ。

379デフォルトの名無しさん2014/03/31(月) 12:43:54.59ID:QAfH9xRd
>>376
これ Word は大丈夫だと思うけど Excel って開いてるだけでファイル変更しちゃう (閉じた時に戻すけど) のにはどう対応してるのか気になる
あと、更新ボタンがあるってことはいよいよマージができるようになったのか?
暇ができたらちょっと試してみるかな。

380デフォルトの名無しさん2014/03/31(月) 22:56:37.85ID:1jlgN23C
WordはWord自体がバージョン管理機能あるからな
ある程度システム化が進んだ会社だとシェアポイント導入してるし

381デフォルトの名無しさん2014/04/01(火) 07:58:31.08ID:CCDQkOuB
>>380
> WordはWord自体がバージョン管理機能あるから

このスレでまともにマージもできないバージョン管理機能持ってくる奴がいるとは...

382デフォルトの名無しさん2014/04/01(火) 08:06:15.82ID:6WDKRgCz
Word文章を複数人で同時に書き換えなきゃいけないシーンが思いつかない
ソースコードと違って普通は自分が担当するページは決まっているから全員が並行して作業を進めても問題ないし

383デフォルトの名無しさん2014/04/01(火) 08:21:28.31ID:CCDQkOuB
>>382
> Word文章を複数人で同時に書き換えなきゃいけないシーンが思いつかない

そりゃ残念だったな
てか、マージで並行開発しか思い付かない時点で終っとる
ブランチとか使ったことないのかよ

384デフォルトの名無しさん2014/04/01(火) 08:22:09.21ID:ixEOnzT4
Word文書は編集するものではなくて生成するもの

385デフォルトの名無しさん2014/04/01(火) 13:25:24.53ID:edNip6Qk
WordやExcelをブランチ切って使ってるというのは聞いたことがない

386デフォルトの名無しさん2014/04/01(火) 19:17:20.59ID:WgoYILFU
そりゃ現状マージできないので、ブランチ切っても旨味がないからな
もしかして、想像力がないのか?

387デフォルトの名無しさん2014/04/01(火) 21:50:59.62ID:R0WZswKH
このスレでいくらWordが、Excelがと騒いだ所で世の中何もかわらないぜ。
マイクロソフト、オプソ開発者のどちらにもメリットがないからな。
もしそういう機能が欲しければ、自分の手を動かそうぜ。

388デフォルトの名無しさん2014/04/14(月) 19:59:37.41ID:gzyVbCaC
Rdemineで
作業Aチケット(例:桶を組み立てる)
作業Bチケット(例:桶に水を入れる)
みたいにあAの後にBがこないと行けない場合って
チケットA、Bの関係は親子関係にすればいいの?

389デフォルトの名無しさん2014/04/14(月) 20:38:04.57ID:nhKvOR/D
>>388
水の入った桶を用意する、の子チケットは以下の2つ
+桶を組み立てる
+桶に水を入れる
って手もある。
自分は子チケットの粒度が大きいときは、こうやってる。

390デフォルトの名無しさん2014/04/16(水) 00:54:33.86ID:0pmbHa2s
redmine のチケットって block みたいなの扱えなかったっけ?
親子以外にも色々関係が定義されてたはず

391デフォルトの名無しさん2014/04/18(金) 01:46:56.50ID:+b/l1KI+
ブロックしている/されている関係は指定できるよ

392デフォルトの名無しさん2014/04/18(金) 20:50:26.72ID:pSxMtBxF
tfs2010使ってる
開発はvs2010

393デフォルトの名無しさん2014/04/19(土) 06:18:42.46ID:wA6wuBBt
Redmineで30人ぐらいのユーザーを一括登録するとき
シェルスクリプト書いて一括登録みたいな事できないんだね
全部GUIというのも不便だ

394デフォルトの名無しさん2014/04/19(土) 07:00:31.30ID:AIzduf/G
>>393
REST API使ったらいけそうな気が
http://www.redmine.org/projects/redmine/wiki/Rest_Users

395デフォルトの名無しさん2014/04/20(日) 10:17:42.48ID:mxI5dGFa
rails なんだから rails console からでも

396デフォルトの名無しさん2014/05/24(土) 11:48:07.42ID:NSCx1NVk
結局ベストなバージョン管理システムはなんなのですか?

397デフォルトの名無しさん2014/05/24(土) 15:14:28.34ID:STwDwgyi
rcs

398デフォルトの名無しさん2014/06/12(木) 22:36:55.03ID:wqY3uKkF
いやいや日付つきフォルダだろ

399デフォルトの名無しさん2014/06/13(金) 03:49:54.71ID:MGSeaEi1
>>398
最強ダナ

400デフォルトの名無しさん2014/06/13(金) 16:56:05.96ID:qsuuOUsU
>>398
おまえリーナスだな。

401デフォルトの名無しさん2014/06/14(土) 02:26:28.37ID:1YLzYE79
でも、日々バッアップするって意味じゃバージョン管理とは別のベクトルで必要だよね

402デフォルトの名無しさん2014/06/14(土) 07:49:31.24ID:xqg+kEWK
他の物理ドライブに最新のクローンを残しておけばいいだけじゃないの?

403デフォルトの名無しさん2014/06/14(土) 15:47:14.69ID:KoIUq31G
火事や倒壊からリストアする必要がないならそれでいい
まぁそんなことまで考える必要があるプロジェクトはそんな多くないだろうが

404デフォルトの名無しさん2014/06/14(土) 22:29:53.74ID:KTI4eUID
>>402
日本だと、違う地域にという必須条件が加わる

405デフォルトの名無しさん2014/08/21(木) 01:16:46.67ID:QG11x9Rz
Git 対 Subversion:長引く争い
http://readwrite.jp/archives/4492

406デフォルトの名無しさん2014/08/21(木) 07:51:47.65ID:/ojqgnKy
プログラマ→git
ドカタ→svn

407デフォルトの名無しさん2014/08/21(木) 11:22:18.42ID:EsX2V+d7
mercurialは負けなん?
まぁ、Unicodeファイル名を取り入れるのにのんびりしすぎだから俺もあきらめ気味だけどさ

408デフォルトの名無しさん2014/08/21(木) 14:56:05.13ID:FADUJgTU
Git だってリーナスのアホが勝手に作ってるだけで Unicode なんか眼中ないんじゃないの?

409デフォルトの名無しさん2014/08/21(木) 15:20:55.56ID:7E+AlxIU
tortoiseの都合でmercurial使ってる

410デフォルトの名無しさん2014/08/21(木) 17:30:44.51ID:yvxtVK3I
TortoiseHgはワークベンチが使い易かったからVistaまでだと現役だったが
Win7以降はSourceTreeもあるからなぁ

411デフォルトの名無しさん2014/08/21(木) 18:33:20.96ID:TZsAWBaG
リーナスはもうGitには関わってないんじゃなかった?

412デフォルトの名無しさん2014/08/22(金) 04:43:33.80ID:I7aAUkM3
Source TreeよりTortoiseHGの方が使いやすいと思うけどなぁ。

413デフォルトの名無しさん2014/08/22(金) 04:44:25.28ID:h4d7Hbqi
個人の好みの問題に帰着します

414デフォルトの名無しさん2014/08/22(金) 04:58:01.85ID:CUb+O1mD
>>412
でも、俺が窓が絡むときにMercurial使うことにしてたのは
コマンドプロンプトがイマイチで常用に耐えんのに
gitフロントエンドもイマイチだったことだもん
俺の場合比べるのは、TortoiseHgでなくTortoiseGitのほうよ

415デフォルトの名無しさん2014/08/22(金) 05:03:28.50ID:CUb+O1mD
最初にgitのが良いなぁがあって、窓が絡むからcmdやフロントエンドの絡みでhgにしてたのが
フロントエンドの話が取り敢えず何とかなるからgitになったってことね

416デフォルトの名無しさん2014/08/22(金) 13:03:16.08ID:4a+J5efW
git-guiでいいやん

417デフォルトの名無しさん2014/08/22(金) 17:37:22.95ID:Qa2U+f+G
必要なライブラリを入れとけば素のままでビルドできるのでcygwinでgitを使っている

418デフォルトの名無しさん2014/08/25(月) 01:59:23.50ID:1pelcRHG
sourcetreeはMacのguiをそのままWindowsに持ち込んでるから使いにくい

419デフォルトの名無しさん2014/08/25(月) 02:08:43.06ID:ksmxv1nf
個人的にはOSX版と違う部分であるブックマークが使いにくいと思うがな
なんでOSXと同じ別窓にせんかったのだろうか…別タブとかでも良かったが

420デフォルトの名無しさん2014/08/31(日) 00:05:19.15ID:47nYGZE4
あげ

421デフォルトの名無しさん2014/09/10(水) 07:08:56.97ID:2N2PVK/b
guiとか邪魔なだけだろ

422デフォルトの名無しさん2014/09/13(土) 10:34:17.04ID:zttb1Mfl
そろそろgitの次の世代のバージョン管理ツールが出てきて欲しい

423デフォルトの名無しさん2014/09/13(土) 12:10:59.94ID:xoDLE1jO
どんなのを望んでるの?

424デフォルトの名無しさん2014/09/13(土) 12:32:37.02ID:4lGfw+8/
何が必要か自分でわかってないのでは?

425デフォルトの名無しさん2014/09/13(土) 14:16:45.08ID:Ukl8c2m8
っbzr

426デフォルトの名無しさん2014/09/13(土) 16:34:02.36ID:TS0TEJI2
巨大プロジェクトへの対応が単一巨大リポジトリかsubmoduleの塊になってもうちょっと使い勝手良くならないものかといつも思うが解決案はわからない

427デフォルトの名無しさん2014/09/13(土) 16:35:14.02ID:bcVwiVx3
そこが工夫された新しいバージョン管理システムが出来るとイイネ!

428デフォルトの名無しさん2014/09/13(土) 19:35:16.12ID:nl7GGicj
svn, git, mercurial 以外に選択肢があっても良いと思うんだけどな
何か黒船的なインパクトのあるやつを望む

429デフォルトの名無しさん2014/09/13(土) 23:13:53.48ID:R6Om/JI9
gitはrebase対象がひとつのブランチだけでマージの再現も弱かったけど
リポジトリ全体の履歴を気軽に書き換えられるようなの頼む
で、履歴への変更それ自体もバージョン管理されるような2次元的なのを

430デフォルトの名無しさん2014/09/14(日) 00:48:29.00ID:pOqGUkHF
> リポジトリ全体の履歴を気軽に書き換えられるようなの頼む
プラグインで実現できる範囲
> で、履歴への変更それ自体もバージョン管理されるような2次元的なのを
純粋な履歴が汚いから書き換えられるようになってるのを劣化させるだけ

431デフォルトの名無しさん2014/10/01(水) 15:06:33.24ID:jQoW/hmd
良スレ緊急保守age

432デフォルトの名無しさん2014/10/02(木) 17:16:43.50ID:0K/3xWHH
ageてないし
そもそも糞スレだし

433デフォルトの名無しさん2014/11/11(火) 00:13:27.86ID:2dKIQrD1
まぁそう言うなよ
10スレまで来たんだから

434デフォルトの名無しさん2014/11/12(水) 11:41:22.08ID:HLWKtkki
GNU Emacs Finally Switching Over To Git From Bazaar
http://www.phoronix.com/scan.php?page=news_item&px=MTgzNjI

435デフォルトの名無しさん2014/11/13(木) 18:14:06.42ID:trYfrMZJ
msのtfs使ってるわ。

436デフォルトの名無しさん2014/11/14(金) 23:07:19.11ID:eiUQB9Ml
>>435
使い心地どうなん?
Subversion から移行する価値ある?

437デフォルトの名無しさん2014/11/14(金) 23:26:42.62ID:0NrzSjGG
なんか知らんが、自分とこのワーキングコピーをupdate。
他人の変更とコンフリ。
人間判断入れたマージ。
なんかコミットできねぇ。
何となく再度アップデート。
エラー。
はひょ?

てな現象にちょくちょく見舞われた。

svnでもgitでもbazaarでも、そんなのなったことないんだが。

438デフォルトの名無しさん2014/11/16(日) 22:01:53.28ID:F43WZJpv
要するにゴミか

439デフォルトの名無しさん2015/02/20(金) 21:14:35.95ID:V8aHRrOt
バージョン管理システムでも、関連ツールでもいいんですが、ソースの行毎に最終的に編集したのが誰かを見られるものってなにかありますか?

ユーザ:行:ソース
user1:1:...
user1:2:...
user1:3:...
user1:4:...
user2:5:...
user2:6:...
...

みたいなイメージなんですが。

440デフォルトの名無しさん2015/02/20(金) 21:25:22.84ID:Rd42V53C
gitにもsvnにもblameやannotateがある

441デフォルトの名無しさん2015/02/21(土) 00:53:12.49ID:PEGyJAcR
サーバへソフトのインストールしないで
windowsの共有フォルダで管理しようと思ったら
何が便利?

442デフォルトの名無しさん2015/02/21(土) 00:55:09.25ID:xSRhDEOz
共有フォルダで管理できるVCS作ったら売れるかな

443デフォルトの名無しさん2015/02/21(土) 01:09:20.24ID:PEGyJAcR
売れなかったのでは?
VSS

444デフォルトの名無しさん2015/02/21(土) 12:47:14.18ID:1iCgmTpE
>>441
git

445デフォルトの名無しさん2015/02/21(土) 13:15:42.83ID:s/E/7Ewr
>>441
分散バージョン管理だったら、なんでもよくね?
レポジトリが共有さえされてればいいわけだから。

446デフォルトの名無しさん2015/02/21(土) 13:20:57.04ID:s/E/7Ewr
>>441
ああ、ローカルレポジトリを持ち、適当なタイミングでpushするのではなく、共有先から直接チェックアウトして、直接コミットか。

Bazaarだとできる。
個人的には気に入ってて、愛用してるけど、もはやバージョンアップされてないのでオススメはしない。

447デフォルトの名無しさん2015/02/21(土) 19:05:58.89ID:VFEr1UXm
いや、だからgitなら当たり前にできることだって。

448デフォルトの名無しさん2015/02/21(土) 22:53:49.09ID:tP61bM4D
>>441
Subversionでもできる。

449デフォルトの名無しさん2015/02/22(日) 17:42:11.95ID:/3o/v0h5
いまだにbazaar使ってるの、わたしだけ(´・ω・`)?

450デフォルトの名無しさん2015/02/22(日) 18:45:23.38ID:Jx0nX4SN
>>449
大丈夫だ。俺もいる。
ただ世界中で2人だけかもしれんけど

451デフォルトの名無しさん2015/02/22(日) 19:51:26.66ID:HBeGusFk
あと10年使い続けたら、NHKがドキュメンタリーの取材に来るよ。

452デフォルトの名無しさん2015/02/22(日) 21:28:55.54ID:XKkbsrmM
>>441
取っ付き易さだけ言えば、TortoiseSVN をクライアントにインストールするのが簡単だと思う。
リポジトリの作成を含めて GUI でできるし。

453デフォルトの名無しさん2015/02/23(月) 20:57:38.33ID:YX8pSHyr
>>450
(´・ω・`)人(´・ω・`)ナカーマ

bzr使いやすいんだよね・・・ぼくには

454デフォルトの名無しさん2015/02/24(火) 19:53:19.54ID:ibhwBdhv
gitなんて使ったこともないはずの上司が「プルリク送っといたからよろしく」と言い出すから何かと思ったら、プルリクなんて何も来ていない。
目の前でもう一度操作させたら、addしてなかった。
当然commitできていないし、どうしてこれでプルリク作った気になれたのか不思議。
「addするんですよ」と言ったら「めんどくさい!もうやらん!」だとさ。orz

455デフォルトの名無しさん2015/02/24(火) 19:56:55.45ID:hxiOplHk
人に何かを教えるのはコツがいるんすよ

456デフォルトの名無しさん2015/02/24(火) 19:59:07.49ID:hoWfolAu
よろしくといったときの上司のドヤ顔が目に浮かぶ

457デフォルトの名無しさん2015/02/24(火) 23:05:04.11ID:6S/sU0E/
プルリクって言いたいだけちゃうんかと(´・ω・`)(´・ω・`)(´・ω・`)

458デフォルトの名無しさん2015/02/25(水) 00:57:15.79ID:PD19Kjkh
まずローカルリポジトリだけで便利ってのを知っとくとadd/commitが面倒なんて言わないと思うんだよな
いきなりリモート前提でやると面倒に見える手順だけども

459デフォルトの名無しさん2015/02/25(水) 00:58:50.46ID:vLMr5bhE
作業を細かく区切ってやらんと意味ないわ

460デフォルトの名無しさん2015/02/25(水) 12:43:36.40ID:jNJiSOpZ
>>459
それは違う。

作業を計画的にやらないからそうなる。
行き当たりばったりでコード書いてるでしょ?

461デフォルトの名無しさん2015/02/25(水) 15:49:16.30ID:8ejgf7d6
>>450
私も使っとるぞよ。
ファイル名に日本語があるドキュメントの管理が主な用途だが。
まあでも3人てことはないぞ。KiCad では Bazaar が使われてるっぽい。

ソースコードなんかは、なぜか名前が出てこない Mercurial を使ってる。

462デフォルトの名無しさん2015/02/27(金) 04:32:41.95ID:SYx5FGl1
> なぜか名前が出てこない Mercurial

知名度ではGitに劣るからVCS全体での話に使いづらいし
専用スレがある程度には有名だから、悲観ネタにするほどでもない上に
このスレじゃないと話せないってものでもないんだよなあ

463デフォルトの名無しさん2015/02/27(金) 10:42:59.06ID:bYWLiJZd

464デフォルトの名無しさん2015/07/19(日) 10:26:58.56ID:oCEbBSyu
Windowsのコードもunixのコードも一緒に管理できるやつはないですかねぇ

465デフォルトの名無しさん2015/07/19(日) 10:36:39.93ID:eXANfUZ5
>>3 のやつ大抵WindowsでもUnixでも動くと思うけど

466デフォルトの名無しさん2015/07/19(日) 17:07:39.30ID:3kuejrUB
>>3
のやつって資材は各環境に格納できて、Windowsクライアントとかから一元操作できるんですかね?

467デフォルトの名無しさん2015/08/09(日) 11:29:39.37ID:iG6DS0Hh
安心して日本語ファイル名が使えるものはないですかねぇ…

468デフォルトの名無しさん2015/08/09(日) 12:43:00.98ID:7jlEc6rs
subversion

469デフォルトの名無しさん2016/02/08(月) 07:26:37.99ID:5ry4fZpQ
CVSがわかり易い

470デフォルトの名無しさん2016/02/20(土) 12:52:35.28ID:e43erU4G
>>467
bzr

471デフォルトの名無しさん2016/03/28(月) 12:28:50.09ID:jI9F+kOe
どうでもイイけどdevは、デバイスと混乱されるから使わないで欲しいw

472デフォルトの名無しさん2016/04/09(土) 22:21:17.56ID:y/nV1xKV
>>470 bzr から移行したいので…

473デフォルトの名無しさん2016/04/10(日) 19:29:13.62ID:AbYPTdqD
Windows が UTF-8 になればねえ。

474デフォルトの名無しさん2016/04/11(月) 12:14:30.87ID:KLWDT4Re
mintty

475デフォルトの名無しさん2016/05/01(日) 15:27:33.79ID:tKi6j9CT
匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか?

Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw


The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません

476デフォルトの名無しさん2016/05/16(月) 02:38:23.39ID:48cZCqzj
「BitKeeper 7.2」、Apache License 2.0でソースコードを公開
https://osdn.jp/magazine/16/05/12/153000
OSSコミュニティとの対立から11年、BitKeeperがオープンソース化される
http://opensource.srad.jp/story/16/05/15/0457249/

感慨深い話ではあるが、今更過ぎるけど使えるの?

477デフォルトの名無しさん2016/05/16(月) 06:53:06.30ID:qbgkd5A8
GPLじゃないなら組み込むアプリケーションでてくるのかな
gitを版管理として使いたいという需要以前からあるよね

478デフォルトの名無しさん2016/05/16(月) 09:24:44.48ID:HysSRgR+
gitコマンドを一緒に置いておいて外部プロセスとして使う分にはGPL関係ないし、libgit2ならリンク時例外あるしでそっち方面には影響なさそう
しかし15年前なら…

479デフォルトの名無しさん2016/05/16(月) 09:55:57.36ID:IBGTyv6p
名前を変えてイメチェンすべき

ZuttoKeeper

480デフォルトの名無しさん2016/11/02(水) 21:24:58.81ID:a7tHL4Q3
Git 対 Subversion:長引く争い | ReadWrite[日本版]
http://readwrite.jp/startup/4492/

なかなかGitに移行しないなんて言われてた時代があったんだな

> 2010年にはSubversionが、ソフトウェアの共同開発には
> 欠かせないツールであるバージョン管理システムの60%以上を占めていた。
> Forresterによれば、この時期Gitのシェアはわずか2.7%であった。
> Redmonkのアナリストであるステファン・オグレディが集めたデータによると、
> 今日(注2014年)ではGitのシェアは28%まで増加し、Subversionの地位を脅かしている。

481デフォルトの名無しさん2016/11/02(水) 22:43:28.29ID:MYQ7Ohex
争ったことが一度でもあっただろうか

482デフォルトの名無しさん2016/11/03(木) 15:56:06.07ID:h1F6iaqt
HGのことも思い出して下さい

483デフォルトの名無しさん2016/11/04(金) 19:21:01.27ID:e+KIl4Jn
Bazaar「・・・」

484デフォルトの名無しさん2016/11/04(金) 22:49:28.02ID:T+uxQgkl
hg も bzr も使ってるぜ。

485デフォルトの名無しさん2016/11/07(月) 18:51:53.72ID:1ToE65c9
darcs「僕を忘れてるよね?」

486デフォルトの名無しさん2016/11/07(月) 23:00:17.96ID:5lIwdUhD
VSS「私が伝説だ」

487デフォルトの名無しさん2016/11/08(火) 02:23:31.15ID:jrmD4pag
今の時代にSubversion使います言われたら絶望するわ

488デフォルトの名無しさん2016/11/08(火) 07:12:01.73ID:2Nx7aZb/
svk「だよな」

489デフォルトの名無しさん2016/11/08(火) 11:55:06.41ID:ZBAGJV1u
csv「呼びましたか?」

490デフォルトの名無しさん2016/11/08(火) 12:40:00.00ID:KG3cnnP5
>>489
cvs「おい!お前は……」
rcs「関係ねえ!」

491デフォルトの名無しさん2016/11/09(水) 12:57:09.53ID:vxWv5Sjd
SCCS「...」

492デフォルトの名無しさん2016/11/09(水) 14:08:17.25ID:sz1Ecny4
>>491
TeamWare「俺には、お前しか居ねえよ」

493デフォルトの名無しさん2016/11/10(木) 09:27:15.68ID:tKSmyIgp
>>489
tsv「俺たちはお呼びじゃない」

494デフォルトの名無しさん2016/11/15(火) 20:29:13.95ID:HRzgVR+8
gitもここ数年意味ない機能追加ばかりだが

495デフォルトの名無しさん2016/11/16(水) 02:41:12.10ID:fzskfnoe
gitスレ人いなくなっててわろす

496デフォルトの名無しさん2016/11/16(水) 04:05:09.28ID:FTOJZ9+Y
じゃ今なにが主流なん?

497デフォルトの名無しさん2016/12/19(月) 12:46:04.24ID:z9XVuDpo
水炊きごはん

498デフォルトの名無しさん2016/12/26(月) 08:28:54.29ID:6gOvZXV/
tortoisegit
とか初心者でも使いやすいんじゃないかね。

499デフォルトの名無しさん2017/02/02(木) 00:11:38.54ID:RrrGuuGp
↓のブログによると、Subversion 「スナップショット」型で、Gitは「チェンジセット」型なんだそうだ。

SVN脳患者から見たGit
http://qiita.com/kaityo256/items/81e7951a1ca2706955a4

だけど、↓のブログによると、darcsはpatch-basedで、他のVCSはsnapshot-basedなんだそうだ。 darcs 恐るべし。

分散VCSのモデル、あるいはPijulについて
http://keens.github.io/blog/2016/02/14/dvcsnomoderu_aruihapijulnitsuite/

500デフォルトの名無しさん2017/02/02(木) 02:19:43.40ID:lRmYz8pA
不要なパッチを削除できるあたりdarcsのほうが好きだったのでうまく成長してほしい

501デフォルトの名無しさん2017/02/02(木) 08:13:39.05ID:SYC8QPRg
内部での保存方法はgitこそスナップショットでsvnは(逆方向の)patch-basedだろ?
少なくともgitがチェンジセット型ってこたーない。gitでの差分の見え方なんて後からオプション次第で変わるし

502デフォルトの名無しさん2017/02/02(木) 12:54:35.84ID:Y5kXFMjA
うむ

503デフォルトの名無しさん2017/02/07(火) 20:30:10.92ID:oyZmvWF9
SVN脳の問題点というかSVN系統の人が怖がってるのは結局
SVN 系統では commit と push が同一になっているから
merge を極端に恐れてるってだけじゃないかと。

504デフォルトの名無しさん2017/02/07(火) 20:57:37.50ID:+JGOmGWJ
svnだって、commitするときに他の人が先に変更を加えていたら
updateしてからcommitしなおす事になるし、このときローカルでちょこちょこ辻褄合わせをする作業は
git pull --rebaseと同じはずなんだけどな

505デフォルトの名無しさん2017/02/08(水) 12:17:33.93ID:6AUIUEjF
コミット時にコンフリクトする集中型の方が恐怖だけどな。
分散型は、いったんコミットした後で改めてマージするんで、
わけわからなくなっても、何度でもやり直せる。

506デフォルトの名無しさん2017/02/08(水) 23:27:00.23ID:b6dR+iVQ
いやだからその svn での恐怖心を
なんだか知らんが git を使ってても引きづってるってことなんじゃないかと。

507デフォルトの名無しさん2017/02/13(月) 15:12:37.22ID:W5+ofgFM
一番の恐怖は、コンフリクトが判明するのが後のタイミングになるってことなんだよ
Excelとかマージできないバイナリ系ファイルも一緒に管理してるから……

508デフォルトの名無しさん2017/02/13(月) 17:53:09.58ID:UyeCKZqE
混ぜるな危険

509デフォルトの名無しさん2017/02/26(日) 08:37:46.10ID:bXA9paU+

510デフォルトの名無しさん2017/03/09(木) 08:20:28.94ID:We1BNnwe
記事のコメントを見ると
WebKitのSVNリポジトリで、ハッシュ衝突したPDFがキャッシュ・ポイズニング攻撃に使えるかテストするために
ハッシュ衝突したPDFをコミットしたら
リポジトリがあぼ〜んってなったと言う訳か

てかWebKitってまだSVN使ってたの?

511デフォルトの名無しさん2017/03/09(木) 08:21:28.28ID:We1BNnwe
gitは仮に衝突しても大丈夫みたいな事言ってたけど
どんな感じなのかは知らない

512デフォルトの名無しさん2017/03/09(木) 09:01:25.72ID:Nr7urPV/
分散型は、一旦コミットした後でマージするから、
最悪マージ前の双方のバージョンは残ってるってことじゃないの?

513デフォルトの名無しさん2017/03/09(木) 13:23:54.33ID:d1iwkzW4
読んでないけどハッシュが衝突する奇跡が起きたらあぼーんしても不思議で無いね

514デフォルトの名無しさん2017/03/09(木) 14:29:50.48ID:wYyI9EhD
リーナス・トーバルズがハッシュ衝突について語ってるGoogle+の投稿
https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

別のハッシュアルゴリズムを使う計画はあるらしい

Gitを修正してmitigation(緩和?)できるってのはどういう事だろう

実際は衝突する事なんてそんな無いってのはまあ分かる

515デフォルトの名無しさん2017/03/09(木) 19:22:25.79ID:NWFSmelL
>>513
悪意を持った誰かが公開されているpdfをコミットしただけでぶっ壊せる
もしくはWebkitのように、システムの振る舞いを調べるテスト目的でコミットしても壊れる

516デフォルトの名無しさん2017/03/09(木) 19:55:22.59ID:LA1Z4pgP
>>515
そのうち SHA-256 とかにするんじゃね

517デフォルトの名無しさん2017/03/09(木) 21:07:54.65ID:V2YMs/sH
切り替えは相当大変だろうな

518デフォルトの名無しさん2017/03/09(木) 22:08:04.59ID:ZZ1gzprq
>>513
奇跡じゃないって話だろ

519デフォルトの名無しさん2017/03/09(木) 23:11:06.25ID:SohBzwwd
>>517
旧バージョンでダンプして新バージョンでロードするだけでしょ
いままででもリポジトリのバージョン変わったらそうやってたし

520デフォルトの名無しさん2017/03/20(月) 10:28:05.47ID:tUUn7aQW
まあバージョン管理程度なら大した問題にはならんだろ。
ちょっとしたスクリプトを一枚かませばいいくらいの話。

521デフォルトの名無しさん2017/03/22(水) 01:28:09.68ID:MyrW3Mfd
>>520
問題になったやん

522デフォルトの名無しさん2017/03/23(木) 00:11:04.47ID:M1uPRgNk
嫌がらせならハッシュ衝突なんて凝ったことしなくてもできる訳で
嫌がらせ以上のことが可能かといえばそういう話も無く

523デフォルトの名無しさん2017/03/26(日) 09:54:40.33ID:GxjULHy0
>>487
未だに使ってるとこあるよ。あり得ないと思った

524デフォルトの名無しさん2017/03/26(日) 10:18:41.36ID:HsMpHt+x
未だにVSS使ってる魔境もあるぞ

525デフォルトの名無しさん2017/03/26(日) 11:52:30.59ID:iTS+fWTZ
>>523
普通に使ってるけど?
git だとアクセス制限とかかけられなかったりするから会社では使えないケースもあるし

526デフォルトの名無しさん2017/03/26(日) 12:27:51.46ID:7dOJEWlC
>>525
かけられる。かける方法を知らないお前が馬鹿なだけ

527デフォルトの名無しさん2017/03/26(日) 18:51:27.67ID:iTS+fWTZ
https://git-scm.com/book/ja/v1/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-Gitolite
のことを言ってるのかな?
それなら知ってるから無駄に煽るな

528デフォルトの名無しさん2017/03/26(日) 19:12:03.88ID:K0FPpjuZ
東京電力の新会長に日立製作所の人間が就任

529デフォルトの名無しさん2017/03/26(日) 20:40:16.26ID:CAdFcq03
>>526
馬鹿を晒した気分はどうよ?

530デフォルトの名無しさん2017/03/26(日) 20:54:59.26ID:7dOJEWlC
>>529
かけられたが?

531デフォルトの名無しさん2017/03/27(月) 01:00:14.02ID:70JXvwsB
素人でスマンが、実際のところsubversionではできてgitではできないアクセス制限ってどんなのがあるの?

532デフォルトの名無しさん2017/03/27(月) 11:09:36.85ID:e29nEpzR
>>531
リポジトリの一部を読み出し不可にすること

533デフォルトの名無しさん2017/03/27(月) 11:20:28.28ID:LarKYmAi
>>532
svnだとリモートリポジトリを作るのが面倒(?)とかいう理由で
全てのプロジェクトを一つのリポジトリに入れるとかいう
アホな使い方をしている例をしていたけど、そういう話?

リポジトリの一部を読み出し不可にするのであれば
その部分だけ別リポジトリに分ければ良いと思うけど?
submoduleがあるからリポジトリの特定のディレクトリだけ
別リポジトリにするなんてことも簡単にできる

534デフォルトの名無しさん2017/03/27(月) 11:21:50.59ID:LarKYmAi
それからsvnでリポジトリの一部を読み出し不可にするって
apacheの設定の話をしてる?

それapacheの機能だよね?

535デフォルトの名無しさん2017/03/27(月) 12:23:49.25ID:X8AlYPVD
横だがsubmoduleはアンチパターン的な扱いになってきてなかったっけ

536デフォルトの名無しさん2017/03/27(月) 12:25:01.61ID:e29nEpzR
>>533-534
プロジェクトとかシステムの一部のソースは外注さんには公開しないと言うのは別に珍しい話ではない
アクセス制御のために別リポジトリにするのは本末転倒
あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか?

537デフォルトの名無しさん2017/03/27(月) 14:24:08.92ID:LarKYmAi
> あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか?

いいや? Apacheの機能を使ってもいいというのであれば
gitでも同じことはできる。

538デフォルトの名無しさん2017/03/27(月) 14:27:12.05ID:LarKYmAi
> プロジェクトとかシステムの一部のソースは外注さんには公開しないと言うのは別に珍しい話ではない
公開するものだけを渡せばいいだけの話
公開しないものと公開するものを同じリポジトリに入れる必要がない。

> アクセス制御のために別リポジトリにするのは本末転倒
それこそ別リポジトリにするべきことだろう。

別リポジトリににすればいいだけなのに、
公開しないものを同じリポジトリに入れて
アクセス制御するほうが本末転倒だろう。

539デフォルトの名無しさん2017/03/27(月) 15:01:35.22ID:X8AlYPVD
プロジェクトで要求するような詳細な権限管理はGitHubみたいなアプリケーション側ですることでSCMの責務ではない
以上

540デフォルトの名無しさん2017/03/27(月) 15:19:58.53ID:BGS+rNUA
>>538
> > アクセス制御のために別リポジトリにするのは本末転倒
> それこそ別リポジトリにするべきことだろう。
時系列を考えないと。

最初は全て同一リポジトリで社内ユーザなら誰でも見られるようにする。
その後、一般公開したり、一部を外部に開発依頼することになったりするときに、全部を公開するのがまずいとなる。
そういうときに、権限管理があったら便利だよねってこと。

最初から、将来起こりえるだろう事象を見越して、リポジトリを分割管理する方が本末転倒だと思うけどね。

541デフォルトの名無しさん2017/03/27(月) 16:41:44.76ID:LarKYmAi
最初は全て同一リポジトリで社内ユーザなら誰でも見られるようにする。
その後、一般公開したり、一部を外部に開発依頼することになったりするときに、
公開するものだけをまとめたほうがいいだろう?

アクセス禁止がデフォルト設定
公開したいところだけ、別リポジトリにまとめる


リポジトリをアクセス許可にして制限するというやり方では
ミスしやすい

542デフォルトの名無しさん2017/03/27(月) 16:48:12.04ID:BGS+rNUA
>>541
どちらがベターかはケースバイケースでしょう。
あなたがべき論でもって、権限管理方式を全否定しているからレスしただけ。

543デフォルトの名無しさん2017/03/27(月) 16:48:57.03ID:LarKYmAi
もともと「社内だけで使えるリポジトリ」と思っていたわけで、
どこに何をおいても社内だけだから安全だと思ってしまう。

「社内だけで使えるリポジトリ」の一部を社外にも公開しますよと
通知した所で、忘れる可能性がある。
その一部に間違えて、公開してはいけない情報を入れてしまったら?

そうなるから「社内だけで使えるリポジトリ」を
あとから変更するというのはやってはいけない。

「社内だけで使えるリポジトリ」は将来に渡っても
社内だけにしておかないといけない。

そうすると当然、社外とも共有するリポジトリを作るという話になる。
もちろん最初に作るわけじゃない。
必要になった時点で作ればいいだけ。

必要になった時点で必要な権限で新しいリポジトリを作る。
最初から公開するものとして作っているのだから間違えることもない。
別リポジトリにすることは、安全に公開範囲を決める方法となる

いちいち、このディレクトリって、誰が見れるんだっけ?
などと気にする必要もなくなる。

544デフォルトの名無しさん2017/03/27(月) 16:49:44.27ID:LarKYmAi
>>542
いずれのケースでもリポジトリを分けるほうがベター
subversionを使っていたとしてもリポジトリを分けたほうが良い

545デフォルトの名無しさん2017/03/27(月) 16:55:09.24ID:BGS+rNUA
>>543
そういうこと言い始めたら、ファイルシステム全体で権限管理しているLinuxなんて信用ならんってことになりませんかね。

546デフォルトの名無しさん2017/03/27(月) 17:03:34.11ID:DbmaBtXa
>>545
ならねーよ

547デフォルトの名無しさん2017/03/27(月) 17:04:29.56ID:LarKYmAi
ならないな。

ユーザーごとにディレクトリ別れているわけだし

548デフォルトの名無しさん2017/03/27(月) 17:09:35.26ID:BGS+rNUA
そう、なりませんよね。

だったら、もしgitにも権限管理機能があったら、やはり同じように信頼できるやり方ができるんじゃないですかね。

549デフォルトの名無しさん2017/03/27(月) 17:31:02.44ID:LarKYmAi
ソースコードの場合は、原則として
リポジトリの全てがないとビルドできないのだから
ディレクトリの一部が見れないという方式は取れない。

もし別々にビルドできるのであれば、
それは別のリポジトリにする方が良い
モジュールの独立性を高くできる。

モジュールの時点で独立しているので、
ソースコードの一部を隠すという発想よりも
安全に運用できる。

550デフォルトの名無しさん2017/03/27(月) 18:24:55.49ID:e29nEpzR
>>537
使っていいからやり方教えて

>>538
アクセス権限の変更が必要になる度にリポジトリの構成を変えるの?
なかなか小学生らしい斬新な発想ですね w

>>539
github ならできるの?

551デフォルトの名無しさん2017/03/27(月) 18:52:07.74ID:DbmaBtXa
>>548
論理飛躍しすぎ。

552デフォルトの名無しさん2017/03/27(月) 19:35:47.70ID:e29nEpzR
非公開の情報を間違ったディレクトリに突っ込む >>543 みたいな間抜けな奴は同じ情報を間違ったリポジトリにも突っ込むと思った方がいい
そもそもそう言う間抜けに書き込み権限を与えるなよ w

553デフォルトの名無しさん2017/03/27(月) 21:23:26.89ID:9ObHSaYA
alt gitまだー?

554デフォルトの名無しさん2017/03/28(火) 11:09:32.22ID:uzRike2T
>>549
> ソースコードの場合は、原則として
> リポジトリの全てがないとビルドできないのだから
そんなことない。
メインアプリ+プラグイン/ライブラリ複数を一度のビルドでコンパイルするケースは結構ある。
出力されるのが、LM + .so複数みたいな。

555デフォルトの名無しさん2017/03/28(火) 21:26:42.96ID:8XEqMjkn
>>554
一部だけビルドできるってことは、別のリポジトリにできるということ。
ならば、そうすればいいだけの話

556デフォルトの名無しさん2017/03/29(水) 10:34:46.63ID:Y3wjV6v+
>>555
> 一部だけビルドできるってことは、別のリポジトリにできるということ。
なるほど、ここに誤解があるのか。

「一部だけビルドできる」というのと「別のリポジトリにできる」というのはイコールじゃない場合が多い。
両者に依存関係がある場合ね。

簡単に分割できるのは、ビルドが不要な言語に多いんじゃないか?

557デフォルトの名無しさん2017/03/29(水) 10:55:14.48ID:BMMgvCDG
それは一部だけビルドできると言っていいのか…?
あとそれってsvnでアクセス権設定しても同じように困るんじゃないの?

558デフォルトの名無しさん2017/03/29(水) 13:17:13.75ID:Y3wjV6v+
>>557
> それは一部だけビルドできると言っていいのか…?
まあ、こんな感じですかね。
foreach dir in subdirs
 cd dir; exec build_script
end

> あとそれってsvnでアクセス権設定しても同じように困るんじゃないの?
subdirのいくつかが欠けていても、それは単にビルドされないだけですね。
あと、svnでできるかどうかは知りません。

559デフォルトの名無しさん2017/03/29(水) 13:25:46.88ID:Y3wjV6v+
とういか、別にそんな細かい話したいわけじゃなくて、リポジトリの一部をomitして提供、
あるいは一部のみ提供する必要があったとき、リポジトリを分割するだけが解じゃなくて、
権限設定機能があるならそれで済み場合もあるってこと。

なぜだか、それに強行に反対する人(たち?)がいるようで。

560デフォルトの名無しさん2017/03/29(水) 16:15:13.03ID:dkT05tkI
>なぜだか、それに強行に反対する人(たち?)がいるようで。
逆じゃないの

gitじゃアクセス権出来ないから使えない状況がある(>>525)って所が発端で、リポジトリ分ければ良いじゃんって人とリポジトリ分けられないじゃんって人が言い合ってたのが今の流れでしょ

561デフォルトの名無しさん2017/03/29(水) 16:35:56.60ID:Y3wjV6v+
>>560
> 逆じゃないの
そこも認識が違ってますね。
他の人はともかく、俺はSCM一般の話をしてたつもり。

> リポジトリ分けられないじゃん
いや、そんな人いないと思うけど・・・。

git固有の話をするなら、モジュールを分割してsubmoduleで扱う方式だと、そのリポジトリの
利用者全員に影響を与えてしまうというデメリットがあるね。

562デフォルトの名無しさん2017/03/29(水) 17:51:38.84ID:nMwlQpLq
リポジトリ分けたい人は分ければいい
俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒って思ってるからそんなことをしないだけ

563デフォルトの名無しさん2017/03/29(水) 18:25:33.13ID:Y3wjV6v+
>>562
ですねぇ。

この話題ももう終わりだろうから、一つだけコメントしておこう。
>>533
> 全てのプロジェクトを一つのリポジトリに入れるとかいう
> アホな使い方
googleはそうしてますね。

564デフォルトの名無しさん2017/03/29(水) 21:33:57.72ID:G25OA3ZV
>>562
> 俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒

いや、どこが "本末" が "転倒" してるんだ?って話なんだが。

重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう?
リポジトリを分ければ、きちんと役割が分かれるのだから
本末は転倒してないだろ?

やり方が複数あるってだけだよ。

リポジトリごとに分ければ、誰がそこにアクセスできるのか明確になるし、
githubなんかの情報共有でもリポジトリが別れているから、
issueなどに書かれた見せてはいけない情報だって見れなくできる。

メリットのほうが大きいと思うが?

逆に聞きたいんだが、ファイルのアクセス権に対応したチケット管理ツールとかあるの?
このディレクトリに関するチケットは見せないみたいな

565デフォルトの名無しさん2017/03/29(水) 21:50:59.15ID:zrYSsU9g
>>559
たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。

566デフォルトの名無しさん2017/03/29(水) 21:56:32.41ID:rnkAS5XR
>>565の話にも関係してるけど)

それからsvnにあるのはアクセス権の機能じゃないからな。
svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能だけ
ユーザー登録をsvnに設定するわけじゃない。apacheなどの設定
バージョン管理ソフト自体にアクセス権の機能をつけたら無駄に複雑になる。

本末転倒というならば、むしろこっちの方だろう。
アクセス権を実現するためだけに、apacheなどと連携しなければいけない。
リポジトリそのものを分ければ、git単体でアクセス権を実現できるのに
アクセス権を実現するためだけに、ユーザー管理用のサーバーが必要になってしまう。

567デフォルトの名無しさん2017/03/29(水) 21:57:43.60ID:rnkAS5XR
ちなみに、
> svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能
があるために、svnではいちいちブランチ切るのに長いディレクトリ名を指定したりして
面倒になってしまっている。

568デフォルトの名無しさん2017/03/29(水) 22:32:33.69ID:4ECDiWLN
は?

569デフォルトの名無しさん2017/03/29(水) 22:34:05.79ID:s7sfWWM2
authzはsvnサーバーの設定じゃないというのか?

570デフォルトの名無しさん2017/03/30(木) 08:15:34.48ID:tcaHNIPG
>>564
> 重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう?
意味不明
役割とアクセス権は関連がある時もあるが基本的には別々の話

571デフォルトの名無しさん2017/03/30(木) 08:19:51.08ID:tcaHNIPG
>>566-567
何で話をループさせたがるんだろう?

> あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか?

せめて

> >>537
> 使っていいからやり方教えて
> >>539
> github ならできるの?

に回答してからにしなよ

572デフォルトの名無しさん2017/03/30(木) 10:39:36.78ID:+VntR3if
まだ終わらないんですかね。

>>564
> やり方が複数あるってだけだよ。
「分けるべし」というべき論じゃないのなら、それで終了ですね。

> リポジトリを分ければ、きちんと役割が分かれるのだから
例えば、アクセス権がが違うユーザを登録する必要があるから、redmineを別サーバに建てて既存コンテンツを分割したりしますかと聞きたくなりますね。
本質的には、それと同じ事。

> たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。
まぁ、gitをベースに考えるとそうかもしれませんね。
Perforceから入ったりすると、権限設定という概念の方が普通だと思うかも。

573デフォルトの名無しさん2017/03/30(木) 10:44:30.88ID:+VntR3if
ちなみに、Perforceはこんな感じです。

> 「メタデータのみ参照可」「ファイルの内容まで参照可」「ファイルの更新可」 「ディポの更新可」
> 「システム管理用コマンドの実行可」等のアクセス制御を、ユーザ単位かつ ファイル単位に行う
> ことができます。
> ユーザの指定は、PERFORCEが独自に管理するグループの指定で行うことも可能ですし、
> ファイルに指定には "*" や "..." 等のワイルドカードも指定可能ですので、 細かい設定も簡単に
> 実現できます。
http://www.toyo.co.jp/ss/faq/detail/id=7208

デフォルトが全アクセス可で、駄目な奴だけ禁止するブラックリスト方式も、
デフォルトが全アクセス不可で、いい奴だけ登録するホワイトリスト方式もとれます。

574デフォルトの名無しさん2017/03/30(木) 21:39:34.19ID:+FVPoQLm
>>573
svnだとどんな感じ?

575デフォルトの名無しさん2017/03/31(金) 00:44:40.10ID:ryHYQIXS
そんな設定するくらいならリポジトリ分けた方がよっぽど簡単じゃん。

576デフォルトの名無しさん2017/03/31(金) 07:28:27.46ID:LVEfh2/Z
無限ループ命令が発行されました

577デフォルトの名無しさん2017/03/31(金) 13:38:36.99ID:St8TnNI7
なんにでも終わりはあるよ

578デフォルトの名無しさん2017/03/31(金) 23:50:54.07ID:gJiWNexQ
という事にしたい模様

579デフォルトの名無しさん2017/04/01(土) 01:39:47.54ID:iJwskPQ3
for(;;)
{}

580デフォルトの名無しさん2017/05/02(火) 18:53:02.76ID:XeePHwp1
外出先でもすぐに使用できる
1CDバージョン管理システム的なものないかな
USBブートができないマシンでもCDブートならできそうだから
リポジトリはUSBで

581デフォルトの名無しさん2017/05/02(火) 19:10:30.69ID:vsrARK6+
git

582デフォルトの名無しさん2017/05/02(火) 21:27:53.12ID:5C1gGMjC
たとえば--prefix=/mnt/mygitでビルドしておいて、使うときはそこへmountすればいいんでない

新着レスの表示
レスを投稿する