2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

85 :74:2014/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はルート直下にしか置けない。
メインプロジェクト以下にライブラリを置かなければいけないことはよくある話で、
そういう場合はシンボリックリンクを使ってメインプロジェクト配下に見せる。

141 :140:2014/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
お前一人が勘違いしている可能性は考慮しないのか

254 :252:2014/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とか
意味わかってるか? 本気で馬鹿なのか?

257 :252:2014/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として制限をうけるだけで)
全く同じように共有できるって気づかない?

264 :252:2014/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のサブモジュールにするんでしょ?
何かおかしなこと言ってるヤツいるけど

269 :252:2014/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なし共有ディレクトリと何も変わらないということ。

280 :229:2014/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.18 ID:AS7or27e
くそっ祭りに乗り遅れた

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


>>346
まぁそうだわな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

434 :デフォルトの名無しさん:2014/11/12(水) 11:41:22.08 ID: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.42 ID:trYfrMZJ
msのtfs使ってるわ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

463 :デフォルトの名無しさん:2015/02/27(金) 10:42:59.06 ID:bYWLiJZd
mercurialの話は
https://groups.google.com/forum/#!forum/mercurial-ja

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

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

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

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

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

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

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

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

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

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

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

475 :デフォルトの名無しさん:2016/05/01(日) 15:27:33.79 ID: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.39 ID: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.30 ID:qbgkd5A8
GPLじゃないなら組み込むアプリケーションでてくるのかな
gitを版管理として使いたいという需要以前からあるよね

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

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

ZuttoKeeper

480 :デフォルトの名無しさん:2016/11/02(水) 21:24:58.81 ID: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.29 ID:MYQ7Ohex
争ったことが一度でもあっただろうか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

499 :デフォルトの名無しさん:2017/02/02(木) 00:11:38.54 ID: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.40 ID:lRmYz8pA
不要なパッチを削除できるあたりdarcsのほうが好きだったのでうまく成長してほしい

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

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

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

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

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

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

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

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

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

https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

527 :デフォルトの名無しさん:2017/03/26(日) 18:51:27.67 ID: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.88 ID:K0FPpjuZ
東京電力の新会長に日立製作所の人間が就任

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

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

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

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

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

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

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

それapacheの機能だよね?

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>539
github ならできるの?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

564 :デフォルトの名無しさん:2017/03/29(水) 21:33:57.72 ID:G25OA3ZV
>>562
> 俺はアクセス権のためにいちいちリポジトリ分けたりするのは本末転倒

いや、どこが "本末" が "転倒" してるんだ?って話なんだが。

重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう?
リポジトリを分ければ、きちんと役割が分かれるのだから
本末は転倒してないだろ?

やり方が複数あるってだけだよ。

リポジトリごとに分ければ、誰がそこにアクセスできるのか明確になるし、
githubなんかの情報共有でもリポジトリが別れているから、
issueなどに書かれた見せてはいけない情報だって見れなくできる。

メリットのほうが大きいと思うが?

逆に聞きたいんだが、ファイルのアクセス権に対応したチケット管理ツールとかあるの?
このディレクトリに関するチケットは見せないみたいな

565 :デフォルトの名無しさん:2017/03/29(水) 21:50:59.15 ID:zrYSsU9g
>>559
たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。

566 :デフォルトの名無しさん:2017/03/29(水) 21:56:32.41 ID:rnkAS5XR
>>565の話にも関係してるけど)

それからsvnにあるのはアクセス権の機能じゃないからな。
svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能だけ
ユーザー登録をsvnに設定するわけじゃない。apacheなどの設定
バージョン管理ソフト自体にアクセス権の機能をつけたら無駄に複雑になる。

本末転倒というならば、むしろこっちの方だろう。
アクセス権を実現するためだけに、apacheなどと連携しなければいけない。
リポジトリそのものを分ければ、git単体でアクセス権を実現できるのに
アクセス権を実現するためだけに、ユーザー管理用のサーバーが必要になってしまう。

567 :デフォルトの名無しさん:2017/03/29(水) 21:57:43.60 ID:rnkAS5XR
ちなみに、
> svnにあるのはリポジトリの特定ディレクトリ以下のみをチェックアウトできる機能
があるために、svnではいちいちブランチ切るのに長いディレクトリ名を指定したりして
面倒になってしまっている。

568 :デフォルトの名無しさん:2017/03/29(水) 22:32:33.69 ID:4ECDiWLN
は?

569 :デフォルトの名無しさん:2017/03/29(水) 22:34:05.79 ID:s7sfWWM2
authzはsvnサーバーの設定じゃないというのか?

570 :デフォルトの名無しさん:2017/03/30(木) 08:15:34.48 ID:tcaHNIPG
>>564
> 重要なのはアクセス権が違うのだから、きちんと役割を分けましょうということだろう?
意味不明
役割とアクセス権は関連がある時もあるが基本的には別々の話

571 :デフォルトの名無しさん:2017/03/30(木) 08:19:51.08 ID:tcaHNIPG
>>566-567
何で話をループさせたがるんだろう?

> あと Apache の機能で Subversion の機能じゃないじゃんとか子供みたいなこと言うのは恥ずかしくないのか?

せめて

> >>537
> 使っていいからやり方教えて
> >>539
> github ならできるの?

に回答してからにしなよ

572 :デフォルトの名無しさん:2017/03/30(木) 10:39:36.78 ID:+VntR3if
まだ終わらないんですかね。

>>564
> やり方が複数あるってだけだよ。
「分けるべし」というべき論じゃないのなら、それで終了ですね。

> リポジトリを分ければ、きちんと役割が分かれるのだから
例えば、アクセス権がが違うユーザを登録する必要があるから、redmineを別サーバに建てて既存コンテンツを分割したりしますかと聞きたくなりますね。
本質的には、それと同じ事。

> たぶん、「権限設定機能」の設定が無駄に複雑な機能になる。
まぁ、gitをベースに考えるとそうかもしれませんね。
Perforceから入ったりすると、権限設定という概念の方が普通だと思うかも。

573 :デフォルトの名無しさん:2017/03/30(木) 10:44:30.88 ID:+VntR3if
ちなみに、Perforceはこんな感じです。

> 「メタデータのみ参照可」「ファイルの内容まで参照可」「ファイルの更新可」 「ディポの更新可」
> 「システム管理用コマンドの実行可」等のアクセス制御を、ユーザ単位かつ ファイル単位に行う
> ことができます。
> ユーザの指定は、PERFORCEが独自に管理するグループの指定で行うことも可能ですし、
> ファイルに指定には "*" や "..." 等のワイルドカードも指定可能ですので、 細かい設定も簡単に
> 実現できます。
http://www.toyo.co.jp/ss/faq/detail/id=7208

デフォルトが全アクセス可で、駄目な奴だけ禁止するブラックリスト方式も、
デフォルトが全アクセス不可で、いい奴だけ登録するホワイトリスト方式もとれます。

574 :デフォルトの名無しさん:2017/03/30(木) 21:39:34.19 ID:+FVPoQLm
>>573
svnだとどんな感じ?

575 :デフォルトの名無しさん:2017/03/31(金) 00:44:40.10 ID:ryHYQIXS
そんな設定するくらいならリポジトリ分けた方がよっぽど簡単じゃん。

576 :デフォルトの名無しさん:2017/03/31(金) 07:28:27.46 ID:LVEfh2/Z
無限ループ命令が発行されました

577 :デフォルトの名無しさん:2017/03/31(金) 13:38:36.99 ID:St8TnNI7
なんにでも終わりはあるよ

578 :デフォルトの名無しさん:2017/03/31(金) 23:50:54.07 ID:gJiWNexQ
という事にしたい模様

579 :デフォルトの名無しさん:2017/04/01(土) 01:39:47.54 ID:iJwskPQ3
for(;;)
{}

580 :デフォルトの名無しさん:2017/05/02(火) 18:53:02.76 ID:XeePHwp1
外出先でもすぐに使用できる
1CDバージョン管理システム的なものないかな
USBブートができないマシンでもCDブートならできそうだから
リポジトリはUSBで

581 :デフォルトの名無しさん:2017/05/02(火) 19:10:30.69 ID:vsrARK6+
git

582 :デフォルトの名無しさん:2017/05/02(火) 21:27:53.12 ID:5C1gGMjC
たとえば--prefix=/mnt/mygitでビルドしておいて、使うときはそこへmountすればいいんでない

156 KB
新着レスの表示

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50
名前: E-mail (省略可) :


read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)