2011-02-17 12 views
1

私たちは通常、別のsvnブランチに新しい機能を開発しました。 機能の終了後、別の人がブランチの変更をレビューします。svnブランチの変更を確認する

私はpsvnでemacsを使用しています。 svn-statusは非常に便利です。 ローカル(コミットされていない)変更の間でマークが変更されました。 ediffには簡単ですが、これとの相違点はすべてsvn-statusモードバッファを参照してください。

一般的に、私は他の同僚の私のレビューを緩和するためにこれらのステップは、働いています:

svn co [svn-branch-url]   # get his branch locally 
cd [check-out-branch] 
svn log -vvv -stop-on-copy  # this gives me all revision involved 
svn diff -r[old]:[latest] >diff.patch # note latest is not HEAD 
svn switch [svn-url]@[old]  # go to the creating of the branch 
patch -p0 diff.patch     # apply his feature 

は今、Emacsは、すべての変更を確認するためのsvn-状況で私を可能にします。 私はソース内のいくつかのレビューコメントを追加し、これらの手順を実行します。私は今、競合を取得

svn switch [svn-url]@[latest] 

。 (もう一度、emacsでediffでこれらを確認するのは簡単です)。 しかし、それは私のレビューのコメントです。

svn resolved [files-in-conflict] 
svn commit -m "review comments" 

今、私の同僚はコメントを読むことができます。

これを行うもっと実用的な方法はありますか? これはどうやってですか?

+0

[svn-branch-url]にコメントをコミットするのではなく、なぜブランチを2回目に切り替えるのか分かりません。 – phils

+0

はい、そのステップは不要かもしれません。私はsvnスイッチで100%快適ではない。私は最後のバージョンに戻る必要があると思った。重要なことは、変更の所有者がレビューのコメントタグを簡単に見つけることができることです。 – franchan

答えて

0

Redmine(コードレビュープラグイン付き)またはReviewboardをインストールすると、すべてのコミットメッセージの大きなリストが表示され、2つのリビジョン間のブランチの変更のレビューを行うことができます。発見した問題に注釈を付けて、開発者が修正するためのチケットとして自動的に作成されるようにすることもできます。

+0

可能であれば、私は(emacs)IDEの中にいたいと思います。また、プロジェクトのコードベースは大きく、レビュー元のソースが使用している完全なソースツリーのシンボルにタグを使用して調べる必要があります。通常、私たちのプロセスでは、レビューのコメントをブランチソースツリーの特別なコメントタグとしてコミットします。 RB(Redmineはまだチェックしていませんでした)は、私たちのプロセス(または仕事の習慣)を変更する必要があります。同僚に仕事の仕方を変えさせるのは難しいかもしれません。 – franchan

+0

webappもbugtrackerと 'projectポータル 'なので、もしあなたがすでにそれらのものを持っていれば... RMは良い代替品になるかもしれません。とにかくRMはいいことです。 – gbjbaanb

0

あなたのアプローチにはいくつかの制限があります。
*電子メールでパッチファイルを渡す必要があります。
*コメントの痕跡を残したり、ディスカッションを行ったりすることはありません。
*レビューの手順が長いため、できるだけ避けようとします。

私はこの制限はありません2つのメソッドを使用することができました:
*その中の差分でウェブサイトを作成して、レビューアがそこにコメントを与えることを許可使用malevichまたはReviewBoard。
*開発者が "cr branch-name developer-name"と入力してemacsで変更を開くだけで済むように、プロセスを自動化するために小さなスクリプト(pysvnを使ってPythonコード)を書く。