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 :
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 :
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 :
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 :
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 :
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 :
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 :
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
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+
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
嫌がらせならハッシュ衝突なんて凝ったことしなくてもできる訳で
嫌がらせ以上のことが可能かといえばそういう話も無く
176KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: