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

バージョン管理システムについて語りましょう

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

●関連スレ
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/

●関連サイト
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/

●チュートリアル
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

以上テンプレ
消滅してるとことか削除させてもらった

インターネットアーカイブに残ってたので一応
●関連サイト
CVS
ttp://web.archive.org/web/20101130125020/http://ximbiot.com/cvs/wiki/
●チュートリアル
Subversionによるバージョン管理(日本語訳)
ttp://web.archive.org/web/20090205132701/http://subversion.bluegate.org/

おつ
少なくともどれかがないとコード書けない体になったわ

>>1乙

乙

セーブがわりにくだらんコミットすんじゃないと俺だけローカルリポジトリになったし

今の職場は、コミット時にはコミットレビューなるものを行わないとコミットできない。
さすがにやり過ぎではないかと。

commitは好きにやればいいだろ
そのままpush済んなって話であって

git脳

VCSごとにコミットやブランチの意味が異なるとかヤメテー

コミットやブランチはそんなに混乱してないだろ
コミットの場合は何処にコミットするかって話なだけだし

問題はチェックアウトだ

コミットは集中型と分散型で意味が違うだけで、それぞれの中では一緒だよね
ブランチはそれなりに違うと思う

svnとgitとhgに限れば、コミットは同じような概念だな
ブランチはsvnの場合、異質
チェックアウトはsvnは部分チェックアウト出来るのがメリット大きい

今でもファイル名に日本語使ってるような文書ファイルなんかは一応 bzr で管理してる。
hg が unicode サポートすれば不要なんだが。

コミットってビルド出来るならしていいんだろ？

スクリプト言語とかだとろくにテストもしないでコミットしとる場合が多い

ビルドできない状態のを大量にコミットしてました
すんません

Mercurial でのプルリクエストをサポートしました
http://sourceforge.jp/projects/sourceforge/news/24580


キター！！

gitにはサブモジュールっていう別のgitリポジトリを参照することできるけど
バイナリ管理にはSVNがいいっていうんなら
gitのサブモジュールみたいな機能で、テキストはgitのような分散で、バイナリはSVNという複合なリポジトリとか作れたりしないん？

バイナリ管理にSVNがいいなんて誰も言ってないよ。
テキストデータでないものはバージョン管理は無理

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

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

そんな俺定義のバージョン管理語られても

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

そういや今は過去スレ見放題なんだっけ？

バイナリなんてファイル管理しておけば
バージョン管理する必要なんてないでしょ。

じゃあテキストは何でバージョン管理するの？

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

officeファイルのバージョン管理なら、大きな企業だとシェアポイント使ってる

適当な差分をとれさえすればいいんだろ。
例えば.xlsxならzip圧縮されたxmlなんだからテキストとして差分をとることも可能だろうし、
画像にしても画素単位で差分をとれるだろうし。
問題は、そこまでする手間に見合うかじゃないの?

それは見当違い

それとはどこよ

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

画像はマージしないからな。

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

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

>>34
画像の場合
複数ユーザの同時変更によるコンフリクトの修正は
現実的でないかもしれんが
複数のバージョンのパーツを融合させるというのは
ありふれた工程だと思う

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

>>36
画像は成果物をソースコードに混ぜ込んでるだけだよ。

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

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

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

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

画像に関して言えば
バージョン管理するのは、「どの画像を使うか」という
情報であって、画像そのもののバージョン管理じゃないんだわ。

何勝手にウェブ用とかソースコードと一緒に管理する話に限定してるの？
対象を限定して議論を深めるならともかく
そんなわかり切った話されても

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

>>39
じゃあ違う場合の話しろよ。

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

バイナリっていうのは人間が
直接編集できるものじゃないんだから
何かのツールの生成物になるんだよ。
バージョン管理に生成物を含めないのは言うまでもないよね。

数年後にビルド環境を整えられる自信がない時は、生成物入れちゃってもいいと思うわ。

IDE使ってたら色んなもの勝手に生成してくれちゃうと思うんだけど
そういうのはバージョン管理しちゃいけないの？

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

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

> 人間が直接編集する

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

「直接」ってのは感覚的な違いでしかないと思うけどね
だから本質じゃないでしょってのが>>43の後半の話だけど

>>43
> IDE使ってたら色んなもの勝手に生成してくれちゃうと思うんだけど
> そういうのはバージョン管理しちゃいけないの？

はい、いけません。

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

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

svn だとディレクトリごとにチェックアウトしたり、アクセス制限かけたりできるけど、git だと無理そうだね
毎回リポジトリ内を全て落としていそう

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

>>42
> 生成物入れちゃってもいいと思うわ。

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

特定のバージョンのライブラリが必要な場合は入れることある。

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

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

>>49
そういうのはプロジェクト管理
ソフトを使うんだよ。

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

>>46
含めたらプロジェクト構造が保てない自動生成ファイルもあるんだけどなあ…
結局、IDEの生成物に関しては
「分からないものをどうするか」なんて考え自体が変で
各自動生成ファイルがどういう役割か、程度の理解は要るよ。

Javaで、mavenやivyリポジトリから自動ダウンロードさせたjarファイルって、
どうしてる？

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

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

>>50
どんなプロジェクト管理ソフトがおすすめ？
wordやexcelの管理するソフトを探してた
出来れば外出先で編集して、帰ってきてから簡単にマージしたい

>>54
訳あってなに使っているかは言えないけど、
条件としては、メールに頼らない、
WordやExcelを使わない。
そういうのがオススメだね。

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

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

>>52
数年後に手に入れられることが確実なら、リポジトリに入れないわけでしょ？
なら答え出てる。リポジトリにいれないが正解。

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

？？

>>55
wordやexcelはバージョン仮管理ソフトではなく、プロジェクト管理ソフトを利用するべき。
と、>>50 で主張されていたので
どんなソフト使ってるか？聞いたんだけど・・・・・
wordやexcelを使わないって・・・・・
全く話がかみ合わない
俺の理解が悪いのか？

>>58
> wordやexcelの管理するソフトを探してた
って書いてあるからだろ。

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

そもそもプロジェクトの進捗管理と
プロジェクトの成果物は別のものなんだよね。
これらを一緒に管理しようとすると
めちゃくちゃになる。

プロジェクト管理ってVisual Studioみたいな感じかな

違う

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

>>59
なら50はなんなの？

>>50はなんなのって
プロジェント管理には（WordやExcelではなく）
プロジェクト管理ソフトを使えって話だろ

テキストエディタを使って絵をかけないように、
（正確に言えばSVGとかでかけるがものすごく効率が悪い）
WordやExcelやメールではプロジェクト管理ができないってことが
出発点なんだよね。

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

>>64
49の日本語を理解しろよ
プロジェクト管理をやるとは書いてない
成果物としてのWordやExcelの管理をどうするか
という話題にしか読めないが
どう読んだらプロジェクト管理をExcelでやるなんて読めるんだ？

プロジェクト管理≠バージョン管理

プロジェクトの指すものが違う奴居るよな
ossプロジェクトみたいなのとvsとかvcでのプロジェクトと

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

プロジェクト管理といえば、redmain

なんで、WordやExcelが成果物になるんだ？
プログラマーの成果物がWordやExcelだなんていう話は
聞いたことがないぞ。事務員が紛れこんでるのか？

バイナリのリソースがソースコードと密接に絡んでるようなものを作ってる立場だと、
「ソースコードのバージョン管理システムにバイナリを入れる奴が悪い。入れるな」って意見は正しいけど原理主義的だと思うんだよな。
そういうものを管理するのにGitをだましだまし使ってるところが問題なんだろうけど、これといった決定打がないんだよなあ。

>>69
名前も覚えてないのに定番みたいに紹介する男の人って

おいおい
設計書も作らない素人が紛れてるのか

横から初心者(というか、アマチュアな…でしょうか)質問で、すみません
プロジェクト管理ソフトって定番とかあるんでしょうか

Microsoft Project。

>>75
それガントチャートアプリだろ
プロジェクト管理じゃない

Comparison of project management software - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_project_management_software

定番ってどれだろうねえ

プロジェクトマネジメントだろ

Project management software - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Project_management_software
> Basecamp, Podio, Project.net, Asana, Sharepoint, Framebench, Brightpod etc

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

>>76
れっきとしたプロジェクト管理である。
何か勘違いしてらっしゃるようで。

>>74
Excel

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

>>76
ガントチャートしか書いたこと無いのかよ (w

>>70
>事務員が紛れこんでるのか？

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

ありがとうございました
プロの方は色々やってるんだなあ…

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

>>53
>本来はソースコード、画像、ドキュメントはそれぞれ別のアプローチでバージョン管理すべきだが、どうしても一つのリポジトリに全部入れがちになる

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

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

画像を例えばsvnで管理するなら先にsvnに画像コミットしておいて
本体側ではsvnのrevだけ管理したらいい

>>88
そんな事するぐらいなら
Mercurialのlargefile使う

画像入れない派の人は、1KBにも満たないようなアイコンファイルとかも入れないわけ？

svnはロック出来るのも利点だな
バイナリはマージ出来ない以上、コンフリクトは確実に回避する必要がある

帳票のテンプレートならわかるけど
設計書にExcelってワロタ

>>92
> 設計書にExcelってワロタ

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

出たよバカ自慢

あるかないかは問題にしてないだろ

プロジェクト管理ソフトに続いて、今度は設計書作成ソフトの話題ですか。
で、実際何を使ってるよ？
うちはエクセル。

>>96
他のなにを検討した結果エクセルになった？
それともエクセルにしたのは使えるのがそれだけだから？

プロジェクト管理に使ってるエクセルのファイルをバージョン管理してるって話？

周りでは、Excelで設計書もスケジュール管理もやる人が多い
これは会社が変わっても一緒
おそらく、だれでもそれなりに使えるから。
じゃないかな
効率は・・・・あまり良いとは言えないが、他に良いソフトもない

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

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

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

設計書Markup Language を作って、それで書いたものをバージョン管理に追加
実際に見るときは、TeX とかPDFとかに変換

javadoc形式でコメント書くのもだが
wordでのhtml編集みたいにマークアップの記述なしで装飾でけたらいいのに

>>99
gitでもhgでも良いと思うぞ
因みにうちは共有物は全てSVNに突っ込んでる
俺個人のファイルは全てhgに突っ込んでる

>>99
sparkle share でドキュメント投げてもらう。
んでそれをリモートブランチとして取り込む。

日本語ファイル名が化ける時点で話にならない

一昨年にfixされてる

実際、化けるよね
Macも混在してるとさらに

最近職場でPerforce使いはじめたけど
ローカルでファイル消したらrevertできなくて嵌った
gitが気楽でええわ
バイナリデータ扱うとカスみたいに遅いsvnは放置で

gitってバイナリデータ扱うのに一番向いてないだろう

>>108
容量は食うけど、とにかくsvnより早いから使ってたんだが
バイナリ向けにいいのあったら教えてほしい

>>107
svn がバイナリデータで他より遅い？
svn がアホみたいに遅くなるのはファイル数が増えたときだろう。

>>107
大きなバイナリ扱うのが上手いのはそれこそPerforceだとおもうけど
ギガバイト超えてくるとかなり差があると思う

そういうサイズのバイナリを管理する必要があるプロジェクトってどんなものなんだ

バージョン管理システムにバイナリファイルを管理させるのは役割ﾁｶﾞｲﾅﾉ叶う。正式版リリース時点の成果物一式（ソース、実行ファイル、ドキュメント、テスト仕様書）を完成図書として管理したいなと思って。
構成管理の仕組みの範疇かも。

>>107
Mercurial

ゲーム作ってる所はsubversionが多いらしいね

Gitって別のものへの移し替えが生じたときに面倒な事になりそう。
最近でいうとCVSからSVNへの移し替えとか。
まあGitがその地位を失うことが無ければそんな面倒な自体も無いだろうけどｗ

え？

svnとcvsしかつこうとらんけど、何使ってもバージョン管理ができりゃええのよ
前との差分、逆櫓、これな

バージョン管理が出来るのは最低条件だろ。
今はどれだけ開発がし易いかが重要になってる。

おまいらレスありがとうな
>>110
すまん語弊がありました
バイナリデータたくさんな環境なの(´・ω・｀)

>>111
やっぱりPerforceなのかな…
ライセンス料の問題で気軽に導入できないのが辛いとこなんだよね
去年のCEDECでPixarが使ってると聞いて入れてみたら便利ではあった
でもオープンソースでなんとかしたい、Tortoise的環境がほしいってのがあるんだ

>>112
>>115がお察しの通りコンシューマのゲーム開発なんだ
アセット100GB越えがザラだから分割してgitリポジトリ作ってる
急ぎの仕事で悩んでるので助言はありがたい
gitがベストだとも思ってないよ

>>114
試してみる

ageちまったスマソorz

>>119
だったら開発がしやすいどんな機能があるのかないのか、に絞って話さないとな
性能はさておき、まずはできるかどうかでしょ

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

現在プログラム板のID制導入の投票を実施中です
よろしくお願いします

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

>>122
ブランチの作成や切り替えが一瞬（長くても数秒レベル）で終わる。
特定のコミットだけを取ってこれる。
歴史を書き直せる。
bisect

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

>>124
これまた見事な git 脳

>>125
git関係ないよ。

まずブランチの切り替え、速いほうがいいだろ？当たり前すぎる話。
特定のコミットを取ってこれるというのは、
そりゃ複数の機能を一人・多人数で開発していれば
その必要あるでしょ。作った順に必ずしもリリースするわけじゃ無いんだから。
歴史を書き直すのも、コミットした後でミスを見つけたとか普通にあるので
必須の機能。bisectはバグを見つけるのに便利。

gitの機能を言ってるんじゃないんだよ。
開発に必要な機能の話をしている。

井の中の蛙乙

だからブランチという用語は慎重に使えと……

>>127
じゃあ、何か言えよｗ

bisect始めて知った
いつも手動で二分探索してたわ…

>>129
例えばセキュリティ、ファイルロック、部分チェックアウトとか git が弱いところ書いてないだろ

gitとは関係なしに
バージョン管理システムにおけるセキュリティの問題って何？

>>132
フォルダ毎にアクセス制限かけたりとかかな
外注さんとやってると、ここは見せたくないとかあるから

>>133
そういう需要があるのは理解できるけど
フォルダ毎のアクセス制限を管理するのと
最初からリポジトリとかフォルダより上位のモジュールで分けて管理するのと
どっちが合理的かというと微妙な気が……

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

>>131
> 例えばセキュリティ、ファイルロック、部分チェックアウトとか git が弱いところ書いてないだろ

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

特定のディレクトリでプロジェクトが閉じてるのに、なんでその親ディレクトリがリポジトリになってんの。
VCSの機能不足より、むしろ管理者の機能不全を疑ってしまう。

>>133
見せたくないのなら、渡さなければいいんじゃないの？

たとえば、ライブラリはソースコードではなく
コンパイルしてオブジェクトファイルとして渡せばいいでしょう？

コンパイルできない言語であれば、それはその言語の問題だけど。
それならそれでリポジトリには含めないでおいて、
動かす必要があるのなら、クライアントからアクセス出来ない
サーバー領域に置いておけばいい。もちろんそっちは別管理。

ようはソース非公開ライブラリと同じやり方だよ。

クライアントに見せてはいけないものは
設定ファイルのパスワードレベルであれば、
それは元からリポジトリに含めてはいけない情報だしなぁ。

>>134
> どっちが合理的かというと微妙な気が……

状況次第でしょ？
リポジトリ分ければいいじゃんとか言ってる奴いるけど、プロジェクトの一部が社外には出せないと言う状況で、全部を社内で開発してる時と外注さんに任せる時でリポジトリの構成変えるの？

>>139
えとさ、どういうディレクトリ構成なのさ？
それ言ってくれんとわからん。

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

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

簡略化するとこういう感じ
root
├メインプロジェクト（自社開発）
└外注さんに任せるライブラリ

もしくは

root
├メインプロジェクト（外注さんと共同開発）
└自社専用ライブラリ

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

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

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

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

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

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

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

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

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

>>142
お前、セキュリティ単語いってるだけじゃん。
具体的に何をしているのかいえって。

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

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

>>144
いや、だから見せないならば、渡さなければいいじゃん
リポジトリを分けてサブモジュールで管理すればいい。
更新禁止は普通にメインリポジトリへのマージを制限すればいいだけ。

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

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

>>144
理解できてないんじゃなくて、
少なくともgitの世界では解決済みの話だって言ってるんだよ。
それを理解できてないのはあんたのほうでは？

ま、Linuxのカーネル開発する人たちにはファイルロックも部分チェックアウトも不要な機能なんだろう

>>145-146
○○すれば大丈夫とか言うなら、そりゃそうだとしか言えんわな...
プロジェクトの途中でリポジトリ分ければいいじゃんとか、正気かよ？ とは思うが、git 脳だと当たり前なんだろうな (w

>>148
お前、何も反論してないって自分で気づいてる？
「俺は違うと思う」と言ってるだけ。

>>147
ロックの話をするならば、
楽観的ロックの悲観的ロック違いを知っているか？
これはどちらも「ロック」だ。

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

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

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

特定のリポジトリの権限管理についてはgitサーバーで使うとさっきも書いた。

技術力の差によってある種の壁ができてるんだと思う。
技術力が低い場合、もっと便利なものがあるのにそれを使えないで、
分かりやすく言えば、メールでファイルをやりとりするみたいなことしか出来ない。
普通に権限管理すればいいのに、許可されたファイルを渡して修正してもらうみたいな
無駄なワークフローをしている。

技術力が低いから、くだらない作業をしている。
そしてそれが最高の方法だと勘違いして、
もっといい方法を提示しても話を聞こうともしない。

結局、「日付のフォルダでいいじゃん」って事か

まさか、gitに日付のフォルダで対抗してたの？
さすがに日付のフォルダじゃ使えなさすぎでしょｗ

一体どういう管理方法をしてるんだろうな。
gitの批判をする前に、具体的にどういった
やりとりをしているのか書いてほしいね。

まずは、ディレクトリ構造と
それをどうやってアクセス制限をかけているのかを

こんなんだろ？ｗ

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

○○さん、○○日納品分
○○さん、○○日納品分

たとえばCVSの日時指定チェックアウトでもbisectとか不可能じゃない。

だけど不可能じゃないからといって、なんでもかんでも人力でやるのは人力の無駄だわな。
省力化できることは省力化しなきゃ。

しかし、オープンソースの世界では、リポジトリにロックかける必要なんてないよな、普通。
必要ない機能は実装しないのが当然だとは思わないの？ossの外の人達がossの成果物を使う
のは勝手にどうぞ、としかいいようがないが、それで機能が足りないだの技術力がどうのと
文句いわれても、別にオープンソースの側は何とも思わないよねー。
だって必要ない機能なんだもん。

エクセルとかのバイナリファイルを編集する場合、ロックがないと致命的に扱いづらい

オープンソース界隈の人たちは、エクセルとか使わない、で終了なんだが。

営業やディレクターはgitなんか使わないでok

RCSの経験で「俺たちにはいらねーわ」って結論が出てるわけだもんな。

そんなにロック書けたいなら、共有ディレクトリをそのままgit管理したら？
gitだと普通のディレクトリを1コマンドでgitリポジトリできちゃう
別に他の場所を用意する必要もない。
今まで使っていたディレクトリがそのままバージョン管理できる。

もちろんこの使い方は通常のgitよりも柔軟性に欠ける。
だが通常のディレクトリよりも機能は上だ。

gitってなんでもできるんだなー。

>>149
反論？
>>124 からの流れで別に反論なんてしてないが？
git でやりづらいこともあるでしょ？ って言ってるだけ。
別に git はそんなことを想定して作ってないだろうから当たり前なんだが、バージョン管理システムの機能の話してるのに git がー、git でわー、とか俺にはそんな必要ないからとか言われてもしょうがないでしょ？
素直に、そんな機能は無いって言えばいいだけだと思うよ。

>>162
それやるなら、さらに--separate-git-dirを使うといいかも。
.gitディレクトリを別の所に作成できる。

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

>164
> 素直に、そんな機能は無いって言えばいいだけだと思うよ。

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

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

今までの話でgitで出来ない機能なんて
一つも出てないなー

普通のディレクトリをそのままgit化できる時点で
ディレクトリ＋αの機能になるしね。
ディレクトリでできることはgitでもできる。

そんな面倒なことするよりsvnでロックかける方が便利だよ

svnでロックかけるために、
リポジトリを別ディレクトリに作って
そこにチェックインしてとかやるの？
面倒くさい。

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

制限が必要ならgitoliteだかそんなのいくつかあるだろ

>>150
釣りかマジかわからん...

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

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

>>154
>>144 みてわからないなら、諦めてくれ。

>>166-167
はいはい、git ってすごいなー

これでいい？(w

>>174
いや良くない。欲しいのは論理的な反論。
それ以外は負け犬の遠吠えにしか見えないから。

>>173

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

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

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

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

>>171
> gitolite

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

>>178
話し聞いてる？

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

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

なんどでも言うよ？

>>176
見せないこともできるの？
リポジトリを分けることについては、>>148 の後半見てね。

ブランチを使うという発想自体が
すでに間違ってるよね。

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

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

>>180
リポジトリを分ければもっと柔軟に管理できる。

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

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

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

>>177
前半は >>150 にアンカーしてくれ。

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

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

ロックを他人が勝手に外したら
意味ないだろｗ

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

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

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

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

>>183
> 前半は >>150 にアンカーしてくれ。

意味不明。

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

Mercurialには、hglockエクステンションが有って、Subversionに近いロックが出来る。

>>181
なら >>144 を実現するための正しい方法を書いてくれ。
今のところ >>140-141 ぐらいしかやり方出てないようだけど？

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

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

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

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

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

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

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

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

>>185
ん？
自分がなに書いたのかわかってる？

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

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

まさか、本人とはね (w

誰か、bzr-gitとかsvn-gitの乗り換えチャートでも作ってくれたりしないもんかな。

bzrなんか誰が使ってんの？w

>>191
GNU信者でしょ

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

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

たぶん、単なるディレクトリが
そのままgitリポジトリになるってことが
あまりにも（その人にとって）革新的なことであり
信じられないんだと思う。

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

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

>>193-194
ご託はいいから、具体的なやり方書いて。

>>195
だから普通のディレクトリと全く同じやり方だよ。
これでわからないの？

先ほどからやたらとgitを否定する方がいらっしゃいますが、git使えなくて
後輩にバカにされた腹いせに書き込んでるのでしょうか？
git脳なんて言ってるけどgit使えない脳の方が問題ですね。

bazaar脳がemacsはgitに以降しそうだから焦ってるんだろ

>>196
それ君が設定してから push して外注さんが clone したら、指定したフォルダは外注さんに見えなくなるの？
まさか、ローカルで見えないから OK とか恥ずかしいこと言ってないよね？

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

じゃぁ、いいとこ取りのバージョン管理システムを新たに開発すればいいじゃん。

なんか伸びてるとおもたら荒れてんのぉ

部分チェックアウトは必要だわ
Android Studio 用のプロジェクトがコミットされたリポジトリからチェックアウトして、
Eclipse の プロジェクトで使う場合とか
assets ディレクトリを部分的に別々のリポジトリからチェックアウトしておくとか
面倒だから一つのリポジトリで複数のプロジェクトを管理とか
どう考えても部分チェックアウトは必須機能

>>202
Android Studio側のbuild.gradleとかにある設定は手動でEclipseに反映させてんのか？
おとなしくAndroid Studio使えよ

gnomeかなんかでmakeかなんか使ってるとかいう話を見た気がする

いつも思うんだが、喧嘩腰じゃないと話せない人がいるのはなんなんだ・・・
議論の一部に自分に取って有意義な話があってその辺りについて詳しい話が聞きたいと思っても
喧嘩腰な人が出てくるとまったく議論にならなくなる、というか聞く気すら起きなくなる

>>199
なんで普通のディレクトリではできないことの話をしてるんだ？

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

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

>>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?をできる。

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

>>197
git使えない人は多いと思うよ
プログラマーでもgit理解出来ない人多いんだから、営業職の人にgitを無理強い出来ないね

営業職の人には普通にファイルを保存してもらって
分かる人がgitで管理すればよい。

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

>>201
別に荒れてないよ、git 脳が勝手に暴れて勝手に玉砕しただけ (w

なるほど、ということにしたい奴が荒らしていたわけか。

>>206
はあ？
>>144 をやりたいって話なのは理解してるんだよね？
ファイシステム云々は >>179 とかが言い出した話だよ？
俺は >>144 が git でできるって言うならやり方示して、って言ってるだけ。
まさか、これがそのまま来るとは思わんかったわ (w
> ローカルで見えないから OK とか恥ずかしいこと言ってないよね？

>>212
> プロジェクト無いの一部のフォルダを特定の人/グループに見せないとか、更新禁止にするだけだよ？
やりたいのはこれだよね？
なんども答え出てると思うけど、

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

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

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

>>211
もうみんな話変えようとしてるよ？
まだ、恥ずかしいレス続けるの？ (w

意訳

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

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

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

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

>>213
> なんども答え出てると思うけど、

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

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

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

>>215
まだやるの？ (w

>>216

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

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

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

都合の悪いレスは見えないんだろ？
本気でそんな人がいるとはね。

>>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 サーバーはインストールされているということです。

gitサーバーの一つがgithubだといえば、
馬鹿にもわかるかねぇ。

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

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

なんか荒れてると思ったら炎上学習法やってる奴が居るのか…

うるさい。そのやり方書いてよ。

svnでいいな

svnの壁ってやつかね。その先を知らない人が
満足する。

gitはどちらかと言えば、開発者のための道具だからね。
管理者のための道具じゃない。

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

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

程度によるよ
多人数で開発して細かくdiffを取ってpatchを当てる続けるようなソースコードの管理する場合にはgitやmercurialの方が向いてる
そうじゃない場合はsubversionの方が有利な事もある
既出の部分チェックアウトやファイルロック

>>209
gitを理解出来ないプログラマーはたくさんいるよ
linuxのカーネル開発してるような優秀な人揃いのプロジェクトならいいけど、
そうじゃない低レベルなプロジェクトもたくさんあるのが現実

>>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ではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

>>229
訂正。
> chgrp -R /proj/src/lib
↓
chgrp -R /proj/src/lib lib-dev-group

>>228
gitすら理解できないってよほどアホか覚える気が全くないかだろう
そんな奴をプログラマーと呼べるのか？最低限持っているべき知識だろ

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

>>229-230
まあそう言うこと。
たぶんわかってるけど git が劣ってるなんて許せねーって言う奴とよくわからんけど煽ってやれ、っー奴が半々ぐらいかな (w

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

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

>>229
>サーバーの OS 上でファイルシステムのパーミッションを設定するとよいでしょう。
なんだから
そこまでやったらgitでは何もやることないんじゃないの

>>233
ネタなのかマジで言ってるのかよくわからん (w
ひょっとしてベアリポジトリの存在を知らないのか？

freebsdの開発チームはがsubversionを採用したんだよな
理由はsubversionの方が合ってるからって

>>233
だから具体的にどうやるか書け

いやおれhg使いだし
サブモジュールのディレクトリにパーミッション設定して終わりじゃないのか

>>237
何いってんの？

煽るだけのは邪魔だからどっか行けよ

>>235
Linux の世話になんかならんぞ、っーのもあるんじゃね？

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

いやおまえこそ

GPLを排除したいFreeBSDにしてみれば
メジャーなDVCSのGit、Hg、Bzrが軒並みGPLな現状じゃ
Apacheライセンスな非DVCSのSubversionを選ぶざるを得ないってとこか

>>239
良く分かってないのに適当な回答かまして場をかき乱す奴よりはまし。

>>229
gitでの話。

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

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

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

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

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

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

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

linuxっていつまで経ってもaclベースのアクセス制御普及しないよな

>>244
> この欠点はdev-groupはgitを使えるが、それ以外はgitを使えないということと

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

>>244
なんだローカルの話か。なら最初から
cd proj
git init
って言えば何を言いたかったのか全員がわかったのに。

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

>>244
俺gitの知識はほぼゼロなんだけど、それでco-dev1はgit clone/push/pullのどれも支障が無いのか？

>>246

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

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

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

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

>248
> 俺gitの知識はほぼゼロなんだけど、それでco-dev1はgit clone/push/pullのどれも支障が無いのか？

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

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

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

>>247
全員がとかいってるけど、
実は「お前が」だよ。

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

>>250
え？>>144に対して、

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

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

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

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

>>251
お前一人が勘違いしている可能性は考慮しないのか

ちなみに、俺がやったこと。
/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以下が取得できてしまったんだが、これを取得できないようにするにはどうしたらいい？

>>252
お前頭悪いなｗ

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

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

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

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

>>254
お前は、パーミッションも読めないのかｗ

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

>>255
ちょっと何を言いたいのか良くわからない。

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

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

>>256
> >>254
> お前は、パーミッションも読めないのかｗ

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

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)

>>244
ねえねえ、マジで言ってるの？
git 脳って git には詳しいのかと思ってたら、単なるアホだったのか (w

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

はぁ？ なんでcloneするんだよ。
そこから間違ってるじゃないかｗ
cloneした時点でお前の間違いが明らかになってるんだが。

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

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

>>260
複数人で作業すること前提なんですが

あたりまえだけど、

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

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

>>261
ディレクトリを共有していれば、
普通に複数人で作業できますが？

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

>>260
> はぁ？ なんでcloneするんだよ。
いや俺マジでgitに詳しくないんだけど、cloneってsvnで言えばsvn coじゃないの？
ワーキングコピーを作る方法。

あ、もしかして>>244のgitの公式説明

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

>>264
> いや俺マジでgitに詳しくないんだけど、cloneってsvnで言えばsvn coじゃないの？
> ワーキングコピーを作る方法。

本当にに詳しくないなｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ


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

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

き・そ・ち・し・き

まさかとは思うが、複数人が同じサーバにログインして、同じディレクトリ下で開発するとか思ってないだろうな？

proj/src/lib以下はリポジトリ分けて
projのサブモジュールにするんでしょ？
何かおかしなこと言ってるヤツいるけど

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

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

>>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なんて要りません。

>>268
> proj/src/lib以下はリポジトリ分けて
> projのサブモジュールにするんでしょ？

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

>>270
一人の場合はそれでいいが、今は複数人で開発するときの話だ

>>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ではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

>>272

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

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

底辺だとそんな開発してるんだな
勉強になるわ

複数人で開発したことないんだと思うよ

共有ディレクトリを使ってパーミッションでアクセス制限とかｗ
>>229は前時的な開発してるな。

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

>>229のやり方って複数人で開発できるの？

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

>>229のやり方でもグループを適切に設定すれば複数人で開発できるよ。
（もちろんgitのディレクトリを共有するやり方でもね）

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

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

単なるファイルシステム上のアクセス制限であれば、>>229のように設定すれば実現できるが、
それをgitでできるのか？というのが>>229の趣旨。

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

??279
は？この人何言ってるの？

その辺は現場によってまちまちだろうね
メンバーごとにプロジェクトフォルダをコピーするだけで完全に動作する環境の方がいいが、そこまで開発環境を作り込めない現場も多い

一人だけ完全にずれてることにまだ気づかない奴

そもそも最初からgitだとsubmodule使うしかないねって話なのに。

ディレクトリ共有とか、もう何年もその発想忘れてたわ

平均的プログラマーの7割は、gitを理解できない。
これが現実。

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

>>283
もうわざとでしょ、彼にとってはバージョン管理なんかより git でもアクセス制御ができると言えることが最重要なんだよ、例えそれに意味がなくても (w

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

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

>>287
やっぱり気づいてないみたいね。

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

>>287
> 現状ではそれが一番みたいですな。
それは最初に俺が言ったことだろｗ

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

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

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

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

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

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

最初に俺がサブモジュールというちゃんとした答えを言って
サブモジュールを使うより劣るけど、git＋共有ディレクトリでもやれなくてはないよ。
（だから共有ディレクトリでやれるアクセス制限はもちろん出来る）
って話をしているのに、わかってないんだな。やっぱり馬鹿か。

もうだれが誰やら

>>288, >>290
きみ、もういいから (w

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

>>290
> サブモジュールを使うより劣るけど、git＋共有ディレクトリでもやれなくてはないよ。
いや、やれないじゃん

ファイル共有なんて論外。

そこは外注使うと決まった時点でリポジトリの構成を変えるべき
手続きが面倒とかは甘え

「共有ディレクトリでやれるアクセス制限」って意味わかんないんだけど。
何のこと？

>>296
ディレクトリのパーミッションのこと言ってるらしいよ。

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

>>292
> でも、リポジトリ構成変えないといけないからうちでは採用できないって書いてある。

え？ どこに？

>>295
馬鹿だからファイル共有を使ったやり方しかできないんです。
パーミッション設定で精一杯なんです。

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

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

>>301
そういう意味の「共有」だとしたら、個々人の開発環境とはどうリンクするの？

あぁ、個人ごとにホームディレクトリに
ローカルリポジトリを持つという発想ではなくて
サーバーにある一つのディレクトリを
みんなで共有して開発するやり方か。
グループ権限とか設定して。

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

sticky bitのことを知ってるのは俺だけだと思ってそうw

>>303
> サーバーにある一つのディレクトリを
> みんなで共有して開発するやり方か。
そのやり方が全く想像できないんですが。

>>302
個々の人の開発環境っていきなり何の話。
スレを「開発環境」検索しても
無関係なものしかヒットしないんだけど。

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

>>304
そんなのだれでも知ってる。

>>305
> そのやり方が全く想像できないんですが。

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

gitを知らないどころか
グループ権限までしらん人がいるのか。
下には下がいるもんじゃｗ

>>295
なんでツールのためにそんな苦労するの？
SVN ならちょっと設定するだけですよ。

>>298
>>148 の後半

>>310
なんでSVNの話？
共有ディレクトリの話でしょ？

>>304
なんか昔に聞いたことあったけどすっかり忘れてたので、ググってみた
忘れたままでいい機能だった...

>>310 >>311
SVNで一つのディレクトリを複数の人で共有して
開発してるんでしょ？ なんでそんなことをしているのかしらんけど。

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

>>311
すまん、共有ディレクトリの話なら誤レスだ、無視してくれ。

>>312
お前それは恥ずかしいセリフだぞ。
たとえば、sudoコマンドには sticky bitがついてる。
ついてるからこそ一般権限で実行できるわけだ。

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

>>313
> SVNで一つのディレクトリを複数の人で共有して開発してるんでしょ？

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

SVNで一つのディレクトリを複数の人で
共有して開発ってマジでやってんの？
ちょっとその発想はなかった。

>>315
それは setuid だよ (w

>>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ではどうやるかという話だと思うが。
もちろん、複数人で開発するのだから、サーバでの話。

>>319
あぁ、ほんとだ。グループで共有するって
話の発端はそいつなのね。

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

>>315
sudoとかで立ってるのは04000でSet-user-id bit
Sticky bitと言われるのは01000

>>304

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

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

>>319
それ SVN 関係ない
単なる説明用だろ

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

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

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

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

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

>>322
自分が知ってる一番難しそうな奴書いたんだろ。
まあ、>>315 みたいなアホが釣れたからちょっとは効果があったんじゃね？ (w

ゲーム脳ってあるでしょ？ あれ、ゲームやってる人の脳がおかしいって話だったけど、
よくよく聞くと、「ゲーム脳」といっている人の脳がおかしいって気づく。

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

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

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

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

お前らこれ以上スレを汚すのはやめろ

/.Jに集うLinuxｦﾀ達と同じ臭いがする
gitｽﾚ行けばいいのに

>>326
自分が【「ゲーム脳」といっている人の脳がおかしい】と決めてそれが絶対正しいと思い込んじゃうんですね、わかります (w

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

>>327
やらなくていいよ。
サブモジュールを使えばいいって
答えが出てるんだから

だよな、サブモジュール使えばいいだけなのに
なんでこんなにぶつくさ言ってるんだろ？

>>330
俺、○○脳なんてひとことも言ってないけど？

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

>>333
誰かが君が○○脳なんて言ってるのか？

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

○○脳って言っている奴をあほだな−って言ってる奴ってバカって言ってる奴はバカだなｗ

以下リソース使い果たすまで無限ループ

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

ループを始める奴はバカ。でいいだろ。

遅れて参加するバカ (w

くそっ祭りに乗り遅れた

git脳とかruby脳とかは確かにいそうだな
というか、兼ねてそう

ということにしたいのですね

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

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

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

集中型も分散型も長所短所があるから、それぞれ使い分ければいいと思う。
いくつがある分散型のいずれを使うべきかは、もう少しふるいにかけられそうだけど

ところで gif は「じふ」なのに、なんで git は「ぎっと」と発音するの？
おいらずっと「じっと」（GitHUBも「じっとはぶ」）かと思ってたんだが

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

>>344
giftをジフトと読むの？

作った人がぎっとと読むと規定しているからぎっと。

gを硬音で読むか否かは単語次第じゃね？

読まないパターンもあるよねgって
何にしても英語は1文字で色んな読み方させすぎなんだよなあ

日本語だって外国人の耳には、ガ行の鼻濁音とか、nとngとmとか、
違って聞こえるらしい、とは聞くけど。

>>348
gh, oughなどは特例と見做すと、サイレントなgってないと思う。

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

>>350
gnomeのgがサイレント

paradigm
align
sign
foreign
gnome(地の精)
gnu(動物)

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

音声会話しなければ読み方を間違っていようとどうということはない

あーごめん、自分でGhoti=無音って書いてたw

この板でgnuにgnomeって言ったら発音するほうだろ

だからわざと地の精だの動物だの、単語の後ろに括弧書き入れてるんじゃないか

>>345
んじゃお前はGIANTSをガイアンツとかギアンツって読むの？
って返しになるぜ


>>346
まぁそうだわな

英単語の git から名付けられているんだから辞書引けよ。
発音の文句は英語に言え。

give me dictionary

Word Excelでバージョン管理できないか探したら
以外とsvnが充実してた

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

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

うちのvistaにはMy Docmentsないわ

>>362
dir /ai

= dr / a

脱字に突っ込んでボケたんだけどわからなかったのか

ごめんねアスペで

test

progitレベルで分かりやすくsvnを説明してるサイトってない？

githubって日本語化出来なかったっけ？

これのこと？
GitHub in your language ・ GitHub
https://github.com/blog/679-github-in-your-language

>>370
これって日本語化はフッターから設定出来るってこと？

日本語化なんて必要ないだろ
gitに限った話じゃないが

日本語化したいって言ってるの

>>372
そうですね。
おめでとうございます。

GitHubは多国語化をすすめようとしてたが、中止して英語オンリーに戻った
英語使えない奴はいらねえって方針です

http://d.hatena.ne.jp/replication/20120321/1332338059
Word Execlはsvn
gitでこういうのみたことない

必要ないからな

ファイルのバージョン管理と
ソフト機能のバージョン管理の
違いを認識しろよ。

>>376
これ Word は大丈夫だと思うけど Excel って開いてるだけでファイル変更しちゃう (閉じた時に戻すけど) のにはどう対応してるのか気になる
あと、更新ボタンがあるってことはいよいよマージができるようになったのか？
暇ができたらちょっと試してみるかな。

WordはWord自体がバージョン管理機能あるからな
ある程度システム化が進んだ会社だとシェアポイント導入してるし

>>380
> WordはWord自体がバージョン管理機能あるから

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

Word文章を複数人で同時に書き換えなきゃいけないシーンが思いつかない
ソースコードと違って普通は自分が担当するページは決まっているから全員が並行して作業を進めても問題ないし

>>382
> Word文章を複数人で同時に書き換えなきゃいけないシーンが思いつかない

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

Word文書は編集するものではなくて生成するもの

WordやExcelをブランチ切って使ってるというのは聞いたことがない

そりゃ現状マージできないので、ブランチ切っても旨味がないからな
もしかして、想像力がないのか？

このスレでいくらWordが、Excelがと騒いだ所で世の中何もかわらないぜ。
マイクロソフト、オプソ開発者のどちらにもメリットがないからな。
もしそういう機能が欲しければ、自分の手を動かそうぜ。

Rdemineで
作業Aチケット（例：桶を組み立てる）
作業Bチケット（例：桶に水を入れる）
みたいにあAの後にBがこないと行けない場合って
チケットA、Bの関係は親子関係にすればいいの？

>>388
水の入った桶を用意する、の子チケットは以下の2つ
+桶を組み立てる
+桶に水を入れる
って手もある。
自分は子チケットの粒度が大きいときは、こうやってる。

redmine のチケットって block みたいなの扱えなかったっけ？
親子以外にも色々関係が定義されてたはず

ブロックしている/されている関係は指定できるよ

tfs2010使ってる
開発はvs2010

Redmineで３０人ぐらいのユーザーを一括登録するとき
シェルスクリプト書いて一括登録みたいな事できないんだね
全部GUIというのも不便だ

>>393
REST API使ったらいけそうな気が
http://www.redmine.org/projects/redmine/wiki/Rest_Users

rails なんだから rails console からでも

結局ベストなバージョン管理システムはなんなのですか？

rcs

いやいや日付つきフォルダだろ

>>398
最強ダナ

>>398
おまえリーナスだな。

でも、日々バッアップするって意味じゃバージョン管理とは別のベクトルで必要だよね

他の物理ドライブに最新のクローンを残しておけばいいだけじゃないの？

火事や倒壊からリストアする必要がないならそれでいい
まぁそんなことまで考える必要があるプロジェクトはそんな多くないだろうが

>>402
日本だと、違う地域にという必須条件が加わる

Git 対 Subversion：長引く争い
http://readwrite.jp/archives/4492

プログラマ→git
ドカタ→svn

mercurialは負けなん？
まぁ、Unicodeファイル名を取り入れるのにのんびりしすぎだから俺もあきらめ気味だけどさ

Git だってリーナスのアホが勝手に作ってるだけで Unicode なんか眼中ないんじゃないの？

tortoiseの都合でmercurial使ってる

TortoiseHgはワークベンチが使い易かったからVistaまでだと現役だったが
Win7以降はSourceTreeもあるからなぁ

リーナスはもうGitには関わってないんじゃなかった？

Source TreeよりTortoiseHGの方が使いやすいと思うけどなぁ。

個人の好みの問題に帰着します

>>412
でも、俺が窓が絡むときにMercurial使うことにしてたのは
コマンドプロンプトがイマイチで常用に耐えんのに
gitフロントエンドもイマイチだったことだもん
俺の場合比べるのは、TortoiseHgでなくTortoiseGitのほうよ

最初にgitのが良いなぁがあって、窓が絡むからcmdやフロントエンドの絡みでhgにしてたのが
フロントエンドの話が取り敢えず何とかなるからgitになったってことね

git-guiでいいやん

必要なライブラリを入れとけば素のままでビルドできるのでcygwinでgitを使っている

sourcetreeはMacのguiをそのままWindowsに持ち込んでるから使いにくい

個人的にはOSX版と違う部分であるブックマークが使いにくいと思うがな
なんでOSXと同じ別窓にせんかったのだろうか…別タブとかでも良かったが

あげ

guiとか邪魔なだけだろ

そろそろgitの次の世代のバージョン管理ツールが出てきて欲しい

どんなのを望んでるの?

何が必要か自分でわかってないのでは？

っbzr

巨大プロジェクトへの対応が単一巨大リポジトリかsubmoduleの塊になってもうちょっと使い勝手良くならないものかといつも思うが解決案はわからない

そこが工夫された新しいバージョン管理システムが出来るとイイネ！

svn, git, mercurial 以外に選択肢があっても良いと思うんだけどな
何か黒船的なインパクトのあるやつを望む

gitはrebase対象がひとつのブランチだけでマージの再現も弱かったけど
リポジトリ全体の履歴を気軽に書き換えられるようなの頼む
で、履歴への変更それ自体もバージョン管理されるような2次元的なのを

> リポジトリ全体の履歴を気軽に書き換えられるようなの頼む
プラグインで実現できる範囲
> で、履歴への変更それ自体もバージョン管理されるような2次元的なのを
純粋な履歴が汚いから書き換えられるようになってるのを劣化させるだけ

良スレ緊急保守age

ageてないし
そもそも糞スレだし

まぁそう言うなよ
10スレまで来たんだから

GNU Emacs Finally Switching Over To Git From Bazaar
http://www.phoronix.com/scan.php?page=news_item&px=MTgzNjI

msのtfs使ってるわ。

>>435
使い心地どうなん？
Subversion から移行する価値ある？

なんか知らんが、自分とこのワーキングコピーをupdate。
他人の変更とコンフリ。
人間判断入れたマージ。
なんかコミットできねぇ。
何となく再度アップデート。
エラー。
はひょ?

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

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

要するにゴミか

バージョン管理システムでも、関連ツールでもいいんですが、ソースの行毎に最終的に編集したのが誰かを見られるものってなにかありますか？

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

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

gitにもsvnにもblameやannotateがある

サーバへソフトのインストールしないで
windowsの共有フォルダで管理しようと思ったら
何が便利？

共有フォルダで管理できるVCS作ったら売れるかな

売れなかったのでは？
VSS

>>441
git

>>441
分散バージョン管理だったら、なんでもよくね？
レポジトリが共有さえされてればいいわけだから。

>>441
ああ、ローカルレポジトリを持ち、適当なタイミングでpushするのではなく、共有先から直接チェックアウトして、直接コミットか。

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

いや、だからgitなら当たり前にできることだって。

>>441
Subversionでもできる。

いまだにbazaar使ってるの、わたしだけ（´・ω・｀）？

>>449
大丈夫だ。俺もいる。
ただ世界中で2人だけかもしれんけど

あと10年使い続けたら、NHKがドキュメンタリーの取材に来るよ。

>>441
取っ付き易さだけ言えば、TortoiseSVN をクライアントにインストールするのが簡単だと思う。
リポジトリの作成を含めて GUI でできるし。

>>450
（´・ω・｀）人（´・ω・｀）ナカーマ

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

gitなんて使ったこともないはずの上司が「プルリク送っといたからよろしく」と言い出すから何かと思ったら、プルリクなんて何も来ていない。
目の前でもう一度操作させたら、addしてなかった。
当然commitできていないし、どうしてこれでプルリク作った気になれたのか不思議。
「addするんですよ」と言ったら「めんどくさい！もうやらん！」だとさ。orz

人に何かを教えるのはコツがいるんすよ

よろしくといったときの上司のドヤ顔が目に浮かぶ

プルリクって言いたいだけちゃうんかと（´・ω・｀）（´・ω・｀）（´・ω・｀）

まずローカルリポジトリだけで便利ってのを知っとくとadd/commitが面倒なんて言わないと思うんだよな
いきなりリモート前提でやると面倒に見える手順だけども

作業を細かく区切ってやらんと意味ないわ

>>459
それは違う。

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

>>450
私も使っとるぞよ。
ファイル名に日本語があるドキュメントの管理が主な用途だが。
まあでも3人てことはないぞ。KiCad では Bazaar が使われてるっぽい。

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

> なぜか名前が出てこない Mercurial

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

mercurialの話は
https://groups.google.com/forum/#!forum/mercurial-ja