monjudoh さんのバージョン管理についてのツイート (Mercurial)
-
- いいね！1
文殊堂
@monjudoh
何かの機能の開発の感覚的な進捗95%までと残り5%が分断され、しかもその5%も固まらず分散してしまうと自分で追いきれない。だってこの5%が5%で済む訳がないから。
2013-09-27 01:32:02
いわた
@wonderful_panda
この、「publishはしないけどshareしたい」っていうのをバージョン管理の外側でせざるを得ないっていうのがMercurialで唯一気に入らない点。
2013-09-27 01:28:13
いわた
@wonderful_panda
@monjudoh share専用リポジトリとのpush/pullはphaseをdraftのままで出来る、とかできるならそれでいいかもしれません。
2013-09-27 01:39:32
文殊堂
@monjudoh
そういえばしかかり中のchangesetsがかなり長くなった時とかgraftしてもついてくるlocal tagみたいのが欲しくなるわけですが、何使えばいいんだろうね?orそんなものはない?
2013-09-27 01:42:13
Nozomu Kaneko
@knzm2018
.@monjudoh さんのブランチ運用は、プロジェクトのほとんどすべてを自分だけで開発しているなら合理的だけど、開発者の人数が増えた時にうまくスケールするのかな。
2013-09-27 01:46:29
文殊堂
@monjudoh
ちなみにさっきまでの話に自分以外の開発者等が出てきてないけど、他開発者・デザイナーの成果も最終的に全部私が責任を持つということでレビュー等が済んでbundleを受け取った後、私のしかかり中一直線に突っ込んでpublish出来るまで育ててました。
2013-09-27 01:53:23
文殊堂
@monjudoh
デザインを当てたもの(2) | 機能の本実装(3) | 機能の空実装(1) こんな感じで実際にはカッコ内の数字の順に別の人が作業してましたみたいなのやってました
2013-09-27 01:55:58
Nozomu Kaneko
@knzm2018
MQ 使わないのは何でだろうと思ってたけど、 graft みたいな賢いマージが使えないのは MQ の弱点だなー (qsave とかを駆使すれば一応 3-way マージできるらしいけど)
2013-09-27 01:57:24
Nozomu Kaneko
@knzm2018
人数が多くなると負担が集中するんじゃないかと心配したけど、 Linux 開発における Linus ブランチみたいなものだと考えれば意外と大丈夫かも。
2013-09-27 02:10:27
文殊堂
@monjudoh
ここ最近の運用が上手くいってるの、私じゃない開発者の仕事が粗粒度で少数だからというのもあると思うが、細粒度で多数の場合は私がやってたのと同じ事をやってもらう事になるのかな?
2013-09-27 02:14:24
文殊堂
@monjudoh
年の初め頃は細粒度で多数のbranchがpushされ、出来たよと言われmergeしていったらconflictで死んでしまった等あった。
2013-09-27 02:16:30
Nozomu Kaneko
@knzm2018
そうか、トピックブランチの運用方法を議論する上で「誰がそれをマージするのか？」という前提は共有しておかないといけないのか。
2013-09-27 02:19:25
文殊堂
@monjudoh
出来上がっているbranchが分岐元が進む事で出来上がっていない状態になるという事を考えると、機能のリリースタイミングに合わせてmergeするのは悪手だと思ったので、極力feature flagを使ったなあ。
2013-09-27 02:24:43
文殊堂
@monjudoh
開発中のも含めて全機能が使えるようになってる設定ファイルを基本として、前回リリースバージョンと同じ動きをするような設定のpatchを用意して、とかやった。
2013-09-27 02:26:39
文殊堂
@monjudoh
リリースタイミングの都合でmergeするしないを決めていた近所のプロジェクトでmerge漏れに悩まされているのを横目に見ていたからというのもある
2013-09-27 02:31:03