しばらくの間TFSを使用した後、Subversionに戻ってきたところですが、一般的にはかなり終了しています:)
覚えていることが1つあります。古くなった作業コピーからコミットできることを覚えていません。あるいは、私の記憶は「時代遅れ」の定義で私を失敗させるかもしれません。「古い」とは、作業コピーを最後に更新してからすべてのファイルが変更されたことを意味し、ローカルでアクセスしたファイルが変更されただけではないと思いました（競合と呼びます）。
これを問題と見なす理由は、他の人が行った変更と最初に統合せずに変更をコミットできれば、「ビルドを中断」するのが非常に簡単になるためです。
それで、この混合リビジョンのものは憤慨して追加されましたか、それとも私だけですか？
このような「混合」リビジョンにコミットする機能は、本質的に安全ではないと思います。コミットを行う前にすべてのファイルを完全に最新にする必要がある VCS を使用している場合でも、VCS は、実際にコードをコンパイルしたり、すべての単体テストを実行したりしたことを確認できません。そのようなことは、開発者の弟子と継続的インテグレーション システムでカバーする必要があります。
Subversion は、CVS の祖先と同様に、非常にファイル中心の世界観を持っています。周囲のファイルに触れることなく、特定のファイルの特定のリビジョンをチェックアウトできます。これは、個々のファイルの特定のチェックアウト リビジョンが追跡されない Git などの他のシステムとは対照的です (私は TFS の詳細に慣れていません)。代わりに、チェックアウト全体が履歴の特定の時点でのリポジトリのビューであり、そこからの逸脱は新しい変更と見なされます。もちろん、これらの新しい変更を好きなだけコミットすることは自由ですが、正しい組み合わせを選択しないとビルドが壊れる可能性があります。
簡単な回答: 一般に、開発者のデスクを新たにチェックアウトしたタグから離れるように意図されたビルドを作成することは良い習慣です。可能であれば、別のマシンで。
このルールを守れば、よく眠れます。
やや長い回答: つまり、リリースを作成する前に、作業コピーを更新し、ビルドし、すべてのテストを実行し、満足したらそこからコピー (タグ) を作成する必要があります。次に、このタグの新しいチェックアウトからビルドを作成するようにビルド マシンに指示します。テスト部門に引き渡すビルドの結果。
後で特定のバージョンを取得する必要がある場合は、いつでもそのタグをチェックアウトできます。そのバージョンに「tags/release_4.2.0」というタグが付けられていて、修正が必要な場合は、そのタグをブランチ (「branches/release_4.2.1」) にコピーして、そこで修正します。期待どおりに動作することを確認したら、ブランチを「tags/release_4.2.1」に移動します。繰り返しますが、ビルド マシンにそのタグをチェックアウトさせ、コードをビルドし、それをテストに渡します。
いいえ、svn の古いファイルをコミットすることはできません。これを読んでください: http://subversion.tigris.org/faq.html#wc-out-of-date
それを片付けてくれてありがとう。それについて考えると、私が提案したことはとにかくクライアント側で実装されると思います..そして、すべてがコンパイルされることを保証するのは開発者次第であることは完全に理解しています。実際にはこれは大きな問題ではありませんが、開発者が最初に作業コピーを更新せずに作業をコミットした結果、ヘッド リビジョンが破損したことが何度かありました。
余談ですが、Tortoise からのこの例はどうですか: http://tortoisesvn.net/node/13
「ここで、File2 を変更してコミットしようとすると、失敗します。クライアントは、File2 がローカルの変更でリビジョン 2 であることをリポジトリに伝えますが、リポジトリはすでにリビジョン 3 です。その後、更新を行うと、File2 はリビジョンになります。 3 も同様です (もちろん、ローカルの変更はそのまま残ります)。」
「古い」メッセージは実際には表示されませんが、ある時点でこれが当てはまると考えるべきでしょうか?