請負業者がチェックインを実行すると、多くの変更が「失われる」ことがわかりました。
一般的なプロセスは次のとおりです。
私の見解では、これは、特に前回のビルド以降に導入されたアプリケーションを壊すリグレッションを扱っている場合は、かなり受け入れられません。
これは少なくとも2回発生していますが、私が考えることができる唯一のことは、請負業者がチェックアウト時に最新のチェンジセットを持っていることを確認できていないことです。私たちのリポジトリでは複数のチェックアウトが許可されておらず、強制的にチェックアウトが最新になるため、状況が非常に奇妙になります（両方ともサーバーワークスペースで作業する必要があるため）。
この問題の他の原因はありますか？すべての拠点をカバーしていることを確認せずに、ラインマネージャーに懸念を伝えたくありません。
Get Latest item on check outはリポジトリではなくクライアントに設定されています。つまり、請負業者は間違ったバージョンをチェックアウトできる可能性があります。そうすることでマージの競合が発生するはずですが、それは編集する場所（およびそのような競合の管理方法）によって異なります。
私はTFSがこのように変更を失うのを見てきました。私は昨日クライアントサイトに行き、変更を加え、チェックインし、今日は私のオフィスに戻って変更を取得し（通常のようにローカルの変更とマージされると想定）、今すぐチェックインして確認できますクライアントサイトの変更が消去されたという差分で（明らかにローカルでのマージを無視します）。私は自分が見ているものを確認するためだけにチェックインしましたが、解決の競合は必要ありませんでした。TFSはすべてが大丈夫だと考えましたが、変更されたローカルファイルはTFSの変更されたバージョンを露骨に上書きし、クライアントサイトの変更全体を効果的に破棄しました（私は紛争を解決することを選択しました-しかし、それは私に紛争について尋ねたり、紛争があったことを示唆したりすることはなく、ただ黙ってそれを失いました）
コミットする前に変更を目で確認すると、行っている変更が思ったよりも多いことがわかります。つまり、クライアントサイトの変更は効果的に削除され、違いとして表示されます。ただし、これを行うと、これを見逃しがちです。多くの。以前は、同僚が私の変更をこのようにスキップしたときに責任を負うと思っていましたが、実際に自分でこれを行っているのを見て、ツールが不十分であることに気付きました。信じがたいことですが、ローカルで変更されたファイルを「getlatest」とマージする方法に明らかに問題があります。不安定なネットワーク接続でクラウドTFSを使用していることがありますが、これが問題の原因であると言われています。