シェルフセットには、チェンジセットのような自然な順序はありません。これにより、多くのマージの競合が発生する可能性があります。
ここであなたの主張がわかりませんが、あなたにとっての「自然な秩序」とは何ですか?チームで作業を開始するとき、チェンジセットの年表は特定の順序に従いません。
開発者がレビューされるまでコードをチェックインできない場合、レビュー担当者に依存関係を置き、レビュー担当者が短期間でレビューを行わない場合、これらのシェルフセットは他のタスクに干渉する可能性があります。
繰り返しになりますが、「通常のタスク開発」でも同じ状況が発生します。これは、タスクBの前にタスクAを開始し、Bの前にタスクAをチェックインするためではありません(BがAに依存している場合を除きますが、ここでは重要ではありません)。 )。タスク開発のワークフローの最終ステップとしてレビューを検討してください。レビューアへの依存は確かに物事をもう少し複雑にしますが、それは安定したビルドを持ち、会社の標準に準拠したコードを持つためです。
チェックインコードではなくシェルフセットを渡す必要があるため、他の開発者とのコラボレーションは困難になります。これにより、将来、マージの競合が再び発生する可能性があります。
棚板よりも簡単なことを知っていますか?変更されたコードをzipファイルで電子メールで送信しますか?参照に影響を与えたくない場合、シェルフセットは開発者間でコードを共有するためのはるかに簡単な方法です。ここでも、あなたが言及しているマージの競合の問題はわかりません。
ここにいくつかのアドバイスがあります:
誰かが別の開発者の棚セットを取り戻しているとき、たとえば、Dev Aが棚セットを作成し、Dev Bがそれを確認したい場合は、DevBに棚を開けるための別のクリーンで専用のワークスペースがあることを確認します。通常の「開発」ワークスペースで棚上げを解除したくありません。コードレビュー専用のワークスペースにより、前述のマージの競合の問題が緩和されます。
理論的には、ターゲットブランチに統合する前に、すべてを確認する必要があります。そうは言っても、実際にはそうするのは難しいので、チームにそのようなプロセスの習慣がない場合は、完璧なことをすることを目指しないでください。作業中のアプリケーションをよく知っている上級開発者は、レビュー前にチェックインすることを許可できます。これはすべてトレードオフの問題です。この場合、柔軟性とスムーズな開発エクスペリエンスが得られますが、参照の品質と安定性が低下する可能性があります。ここに本当の勝者はありません、それはあなたにとって何が重要であるかに基づいてあなたの選択です。
コードレビューにブランチを使用しないでください。
シェルフセットを介したコードレビューのエクスペリエンスは、VS / TFSではやや不完全であることに同意しますが、他の方法よりもはるかに優れています。マイクロソフトは、この点でより良い結果が得られることを認識しており、VS11/TFS11で行われた改善につながります。次のバージョンでは、まだシェルフセットに基づいていますが、アクター間のより完全な通信システムを備えた、真のコードレビューエクスペリエンスがあります。この改善は「私の仕事」の経験で行われ、物事は今ではずっとスムーズになっています。tfspreview.comとVS11ベータ版を試してみるか、いくつかのブログ投稿(Brian Harry)を読んで詳細を確認してください。興味のあるリンクは次のとおりです。