ソース管理で問題が発生することはほとんどありません。この例では、Perforce で問題が発生していましたが、多くの SCM、特に分散 SCM で同じ問題が発生すると思われます。
Perforce は、変更リスト (または必要に応じて変更セット) をサポートしています。変更リストは、次の 2 つの一般的な使用方法をサポートしています。
変更リストをコミットする場合、コミットはアトミックであるため、すべてのファイルがコミットされるか、まったくコミットされません。これは、チェンジリストを参照するときにほとんどの人が話題にする主要な機能です。
Perforce は複数のチェンジリストをサポートしています。基本的に、ファイルをチェックアウトするときは、ファイルが属するチェンジリストを指定します。そのため、数か月の作業が必要で数百万ドルを稼ぐ新しい電子メール機能に取り組んでいて、テクニカル サポートの誰かが昨日修正しなければならないバグを持ってきたとしても、最初から始める必要はありません。プロジェクト全体の新しいブランチ。バグのあるファイルを新しい変更リストにチェックアウトし、問題を修正し、新しい変更リストをチェックインして、何も起こらなかったかのように、新しいメール機能の実際の作業に戻ることができます。
ほとんどの場合、すべてがうまく機能します。ただし、電子メール機能を実装するときは、特に main.h に無数の変更を加える必要があり、バグ修正に取り掛かると、小さな変更を加える必要があることに気付くことがあります。 main.h にもあります。新機能のチェンジリストにはすでに main.h がチェックアウトされているため、バグ修正用のチェンジリストに簡単に入れることはできません。
今、あなたは何をしますか？いくつかの選択肢があります:
新しい clientspec を作成します。Perforce の clientspec は、デポ内のファイル/ディレクトリのリストと、すべてがコピーされるローカルの宛先です。そのため、電子メール機能を変更することなく、プロジェクトの 2 つ目のコピーを作成できます。
ファッジをします。変更した main.h のコピーをバックアップし、このファイルを元に戻します。その後、main.h をバグ修正チェンジリストに自由にチェックアウトできます。バグを修正し、バグ修正の変更リストにチェックインしてから、main.h をメール機能の変更リストにチェックアウトします。最後に、最初に作成したバックアップからすべての変更をマージします。
main.h に加えたすべての変更に副作用や依存関係がないことを確認したので、main.h をバグ修正変更リストに移動し、変更を加えてチェックインします。その後、メール機能に再度チェックアウトします。変更リスト。明らかに、このアプローチには 2 つの問題があります。1 つ目は、考慮していなかった副作用が実際に存在する可能性があることと、2 つ目は、バージョン履歴が壊れていることです。
オプション 1 はおそらく最もクリーンですが、必ずしも実用的ではありません。私が取り組んでいたプロジェクトには、数百万行のコードと非常に複雑なビルド プロセスがありました。新しい環境をセットアップするには 1 日かかるため、5 分間のバグ修正は現実的ではありませんでした。
オプション 3 は悪いオプションですが、これが最も高速であるため、非常に魅力的です。
これで、私が通常使用するオプション 2 が残ります。
誰かがより良い解決策を持っていますか?
長い質問で申し訳ありませんが、StackOverflow で、十分に考え抜かれた質問がより良い答えを引き出すことを発見しました。