バージョン管理システムについて語るスレ10
●関連サイト
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/ おつ
少なくともどれかがないとコード書けない体になったわ セーブがわりにくだらんコミットすんじゃないと俺だけローカルリポジトリになったし 今の職場は、コミット時にはコミットレビューなるものを行わないとコミットできない。
さすがにやり過ぎではないかと。 commitは好きにやればいいだろ
そのままpush済んなって話であって VCSごとにコミットやブランチの意味が異なるとかヤメテー コミットやブランチはそんなに混乱してないだろ
コミットの場合は何処にコミットするかって話なだけだし
問題はチェックアウトだ コミットは集中型と分散型で意味が違うだけで、それぞれの中では一緒だよね
ブランチはそれなりに違うと思う svnとgitとhgに限れば、コミットは同じような概念だな
ブランチはsvnの場合、異質
チェックアウトはsvnは部分チェックアウト出来るのがメリット大きい 今でもファイル名に日本語使ってるような文書ファイルなんかは一応 bzr で管理してる。
hg が unicode サポートすれば不要なんだが。 スクリプト言語とかだとろくにテストもしないでコミットしとる場合が多い ビルドできない状態のを大量にコミットしてました
すんません 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みたいな感じかな >>50はなんなのって
プロジェント管理には（WordやExcelではなく）
プロジェクト管理ソフトを使えって話だろ テキストエディタを使って絵をかけないように、
（正確に言えばSVGとかでかけるがものすごく効率が悪い）
WordやExcelやメールではプロジェクト管理ができないってことが
出発点なんだよね。
できないからなにを使うのがいいかという話。 >>64
49の日本語を理解しろよ
プロジェクト管理をやるとは書いてない
成果物としてのWordやExcelの管理をどうするか
という話題にしか読めないが
どう読んだらプロジェクト管理をExcelでやるなんて読めるんだ？ プロジェクトの指すものが違う奴居るよな
ossプロジェクトみたいなのとvsとかvcでのプロジェクトと
>>55
MLとそのアーカイブ使えばいいだけだな
個人宛にるのは内緒話とかあるからなんともいえん なんで、WordやExcelが成果物になるんだ？
プログラマーの成果物がWordやExcelだなんていう話は
聞いたことがないぞ。事務員が紛れこんでるのか？ バイナリのリソースがソースコードと密接に絡んでるようなものを作ってる立場だと、
「ソースコードのバージョン管理システムにバイナリを入れる奴が悪い。入れるな」って意見は正しいけど原理主義的だと思うんだよな。
そういうものを管理するのにGitをだましだまし使ってるところが問題なんだろうけど、これといった決定打がないんだよなあ。 >>69
名前も覚えてないのに定番みたいに紹介する男の人って 横から初心者(というか、アマチュアな…でしょうか)質問で、すみません
プロジェクト管理ソフトって定番とかあるんでしょうか >>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
れっきとしたプロジェクト管理である。
何か勘違いしてらっしゃるようで。 >>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とかに変換 
