昨日のMySQLとPostgreSQLとOracleの使い分けがめちゃくちゃ受けているので、２匹目のどじょう。
今日も
◆みずほ銀行次期システム開発を見守るスレ25◆ [無断転載禁止]©2ch.net
http://hanabi.2ch.net/test/read.cgi/infosys/1467962368/
で話題になっていた、構成管理（バージョン管理）を
SVN,git,日付つきファイル
のどれでやるべきか？についての話。
結論から言ってしまうと
・SVNとgitは、同じ構成管理でも、まったく世界観が違う
・ただし、これらは一つのモデルにおける問題を解決しているに過ぎない
・上記のスレで問題になっていることは、このモデルとは違うケースであり、
それに対して、SVN,git,日付つきファイルのどれも「まったく無力」
である。だから、何を使っても、「だめだめである」という点で一緒。
以下、「一つのモデルにおける問題」を説明して、「SVNとgitの世界観の違い」
を説明後、「スレで問題になっている、全く違う問題」について説明する。
■構成管理で問題としている１モデル
構成管理は、以下の状況に対する問題を解決しようとしている
・ある大きな１つの機能修正・追加があって、
・この修正をA,B２人以上が
・共通のファイルに対して修正をする時に
・ある（共通の）ファイルに対して、
Aさんが修正
その後
Bさんが修正
したときに、Bさんが、保存したときにAさんの修正内容が
なくなってしまうという問題を解決したい
→AさんBさんの修正をマージしたい
という問題を解決しようとしている。
したがって、このモデルに該当しない、
・Aさんは、Aファイル、BさんはBファイルのように、
担当ファイルが完全に独立している場合
には、構成管理は関係ない。
SVN,git,日付つきファイルのどれでも、使いやすいものを
選べばよい
また、この問題の制約として
・「ある大きな１つの機能修正・追加」が、Aさんが修正をはじめて
Bさんが修正が終わるまで、変更しないという前提がある
→途中に変更があり、それがAさんにしか伝わらない場合、
AさんBさんのものをマージしたら、わけわからんとなる。
■上記問題の「SVNとgitの世界観の違い」
ここで、SVNとgitは、構成管理上、全く概念が違うことを考慮しないと
いけない
●SVNは集中管理→集中管理リポジトリにあるものを最新に
SVNはデータを集中管理して、リポジトリにおく。
したがって、リポジトリにあるものが、最新（コミットしていいもののなかで）
という前提になっている。
●gitは分散管理→中央のリポジトリは、あるバージョンのもの
そこからコピーして、Aさん、Bさんは独自に関心事を修正し、
ある時点でみんなの修正をまとめてマージし、次のバージョンを作る
※ここで、gitで管理する場合、中央のリポジトリは、いつでも稼動できるもの
にしておく。そうすれば、突然「デモしろ」といわれたときでも、
いつでもデモできる。また、ある機能だけを見せたいときは、中央レポジトリ
＋その機能に関する修正だけをまとめてマージすれば見せられる・・・
ということで、デモ必須のアジャイルやベンチャーさんなどには向いている
（SVNは、変なものをコミットされると、動かない。。。コンパイルできない！
なんてこともある）
→このケースではgitが優れている
※しかし、gitは、いつかはマージしないといけない。このマージする人は、
どういうふうにマージしたらいいか知っていないと、テキトーにマージして
おかしくなるかもしれない・・・それだったらSVNなら、コミットしたたびに
Jenkinsで回帰テストをかければ、おかしくなった瞬間に分かるので、まだまし
という考え方もある
●ちなみに、ファイル名に日時をつけて管理するのは、
もし、最新のものしか残さないのであれば、上記の問題が解決されないので
問題あり。
最新のみならず、すべてのファイルを残す（大福帳）なら、競合したことは
自動的には分からないが、すべての履歴がのこっているので、まあ、どうにか
なる。分かりやすいけど・・・それ以上のものではない。
■スレで問題になっている、全く違う問題
しかし、スレで問題になっているのは、全く違う状況で
・ある大きな１つの機能修正・追加があって、
・この修正をA,B２人以上が
・別々のファイルを修正するんだけど、依存性があって
・あるファイルに対して、Aさんが修正
その後、帰り際に修正があり、
その帰り際の修正を考慮してBさんが修正して帰ったら
朝までに、別の修正をしろと話があり
その朝まで修正をAさんがしたら、
→Aさんは朝まで修正、Bさんは帰り際修正なので、依存性があったら
矛盾してしまう（インターフェース合わずにコンパイルできない）
という問題を解決しないといけない。
この問題は、「別々のファイル」なので、SVN,git,日付つきファイル
どれも競合が起こらないので、問題とならない。
しかし、上記の問題が起こって、コンパイルできない。
この問題は、コミットしたらJenkinsで回帰テストを行えば「検知」できる。
しかし、「検知」できても「解決」しない。
徹夜して、朝まで修正して直したAさん、Bさんが対応していないことを「検知」して・・
コミットしなかったら、自分の努力は無駄無駄～
ということで、コミットしてしまう（Aさんのところはデモできるなら特に・・・）
で、この後、Bさんに、「朝まで修正」が伝わらなかったら、どうなるだろう・・・
Aさん、Bさんのインターフェースが取れない状態が続いてしまう。
これがいたるところで起こると、いつかはコンパイルできなくなる。
つまり、横の連携が取れていないで、更新がバンバン来てしまうと、
ソース内に、競合はしないんだけど、矛盾した部分がどんどん出来て、
いつかはコンパイルできなくなる（メソッドの引数や返り値が違って）。
コンパイルに４日かかるというのは、これが「相当」進んだ状態で、
こうなってしまうと、Jenkins入れて回帰テスト・・・する前に
また修正となってしまい、実質、回帰テストは無理なのだ。
このような状況においては、
VN,git,日付つきファイル
どれもだめで、無力である。
※一番強力な解決方法は、「あきらめる」である。
「すべて捨てる」「逃避する」なども別解にある。
今日も
◆みずほ銀行次期システム開発を見守るスレ25◆ [無断転載禁止]©2ch.net
http://hanabi.2ch.net/test/read.cgi/infosys/1467962368/
で話題になっていた、構成管理（バージョン管理）を
SVN,git,日付つきファイル
のどれでやるべきか？についての話。
結論から言ってしまうと
・SVNとgitは、同じ構成管理でも、まったく世界観が違う
・ただし、これらは一つのモデルにおける問題を解決しているに過ぎない
・上記のスレで問題になっていることは、このモデルとは違うケースであり、
それに対して、SVN,git,日付つきファイルのどれも「まったく無力」
である。だから、何を使っても、「だめだめである」という点で一緒。
以下、「一つのモデルにおける問題」を説明して、「SVNとgitの世界観の違い」
を説明後、「スレで問題になっている、全く違う問題」について説明する。
■構成管理で問題としている１モデル
構成管理は、以下の状況に対する問題を解決しようとしている
・ある大きな１つの機能修正・追加があって、
・この修正をA,B２人以上が
・共通のファイルに対して修正をする時に
・ある（共通の）ファイルに対して、
Aさんが修正
その後
Bさんが修正
したときに、Bさんが、保存したときにAさんの修正内容が
なくなってしまうという問題を解決したい
→AさんBさんの修正をマージしたい
という問題を解決しようとしている。
したがって、このモデルに該当しない、
・Aさんは、Aファイル、BさんはBファイルのように、
担当ファイルが完全に独立している場合
には、構成管理は関係ない。
SVN,git,日付つきファイルのどれでも、使いやすいものを
選べばよい
また、この問題の制約として
・「ある大きな１つの機能修正・追加」が、Aさんが修正をはじめて
Bさんが修正が終わるまで、変更しないという前提がある
→途中に変更があり、それがAさんにしか伝わらない場合、
AさんBさんのものをマージしたら、わけわからんとなる。
■上記問題の「SVNとgitの世界観の違い」
ここで、SVNとgitは、構成管理上、全く概念が違うことを考慮しないと
いけない
●SVNは集中管理→集中管理リポジトリにあるものを最新に
SVNはデータを集中管理して、リポジトリにおく。
したがって、リポジトリにあるものが、最新（コミットしていいもののなかで）
という前提になっている。
●gitは分散管理→中央のリポジトリは、あるバージョンのもの
そこからコピーして、Aさん、Bさんは独自に関心事を修正し、
ある時点でみんなの修正をまとめてマージし、次のバージョンを作る
※ここで、gitで管理する場合、中央のリポジトリは、いつでも稼動できるもの
にしておく。そうすれば、突然「デモしろ」といわれたときでも、
いつでもデモできる。また、ある機能だけを見せたいときは、中央レポジトリ
＋その機能に関する修正だけをまとめてマージすれば見せられる・・・
ということで、デモ必須のアジャイルやベンチャーさんなどには向いている
（SVNは、変なものをコミットされると、動かない。。。コンパイルできない！
なんてこともある）
→このケースではgitが優れている
※しかし、gitは、いつかはマージしないといけない。このマージする人は、
どういうふうにマージしたらいいか知っていないと、テキトーにマージして
おかしくなるかもしれない・・・それだったらSVNなら、コミットしたたびに
Jenkinsで回帰テストをかければ、おかしくなった瞬間に分かるので、まだまし
という考え方もある
●ちなみに、ファイル名に日時をつけて管理するのは、
もし、最新のものしか残さないのであれば、上記の問題が解決されないので
問題あり。
最新のみならず、すべてのファイルを残す（大福帳）なら、競合したことは
自動的には分からないが、すべての履歴がのこっているので、まあ、どうにか
なる。分かりやすいけど・・・それ以上のものではない。
■スレで問題になっている、全く違う問題
しかし、スレで問題になっているのは、全く違う状況で
・ある大きな１つの機能修正・追加があって、
・この修正をA,B２人以上が
・別々のファイルを修正するんだけど、依存性があって
・あるファイルに対して、Aさんが修正
その後、帰り際に修正があり、
その帰り際の修正を考慮してBさんが修正して帰ったら
朝までに、別の修正をしろと話があり
その朝まで修正をAさんがしたら、
→Aさんは朝まで修正、Bさんは帰り際修正なので、依存性があったら
矛盾してしまう（インターフェース合わずにコンパイルできない）
という問題を解決しないといけない。
この問題は、「別々のファイル」なので、SVN,git,日付つきファイル
どれも競合が起こらないので、問題とならない。
しかし、上記の問題が起こって、コンパイルできない。
この問題は、コミットしたらJenkinsで回帰テストを行えば「検知」できる。
しかし、「検知」できても「解決」しない。
徹夜して、朝まで修正して直したAさん、Bさんが対応していないことを「検知」して・・
コミットしなかったら、自分の努力は無駄無駄～
ということで、コミットしてしまう（Aさんのところはデモできるなら特に・・・）
で、この後、Bさんに、「朝まで修正」が伝わらなかったら、どうなるだろう・・・
Aさん、Bさんのインターフェースが取れない状態が続いてしまう。
これがいたるところで起こると、いつかはコンパイルできなくなる。
つまり、横の連携が取れていないで、更新がバンバン来てしまうと、
ソース内に、競合はしないんだけど、矛盾した部分がどんどん出来て、
いつかはコンパイルできなくなる（メソッドの引数や返り値が違って）。
コンパイルに４日かかるというのは、これが「相当」進んだ状態で、
こうなってしまうと、Jenkins入れて回帰テスト・・・する前に
また修正となってしまい、実質、回帰テストは無理なのだ。
このような状況においては、
VN,git,日付つきファイル
どれもだめで、無力である。
※一番強力な解決方法は、「あきらめる」である。
「すべて捨てる」「逃避する」なども別解にある。
アクセス
トータル
ランキング
