changesetを書き換える者すらいた。 commitログで嘘はつける - monjudoh’s diary
subversionのcommitごとにdiffを見ればどういう思考をしたかはだいたいわかる。むしろ、自然言語で進捗を報告すると、30%しかできていないのに80%できたと見栄をきったり、１日でできる仕事なのに「これは１週間はかかるッスね」と言って楽をするといった不正が簡単にできてしまうが（正直僕もやったことは過去にあります）、commitログはうそをつかない。これはたいへんに大きい。 http://okajima.air-nifty.com/b/2010/02/post-9347.html 分散SCMで俺々バージョン管理をし、適切な粒度でchangesetを作っておく。 そして、表向きの進捗の分だけ中央リポジトリに反映していく。 それだけで進捗をごまかす事は容易に出来る。 まー、当然逆は無理なわけだが。
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - monjudoh’s diary
職場でMercurialを使っていい感じに俺々バージョン管理を やれるようになってきた感があるので、 ノウハウをまとめる。 概略 中央リポジトリと同期をとるbranchを用意する 同期branchはsync_cvsとかそんな名前 defaultをそのまま使っても良い このbranchで開発作業は絶対にしない 全ソースをhgで管理しない 中央リポジトリで管理しているソースの数が多い場合の話 hgで管理するファイル数が多いとhg update等が遅くなり、開発のスピード感が落ちる ticket毎に開発作業用branchを作成する 同期branchから作成する 同期branchから随時rebaseする 必ず、同期branchの最新版からrebaseした状態でテストを行う。 テストが通ったらticket別branchから同期branchにmergeする。その後、同期branchの内容で中央リポジト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
