ソース管理を使用する場合の一般的なシナリオは、バージョン管理されたリリースブランチとともに開発ブランチを用意することです。開発ブランチとしてHEADを使用し、製品の現在のリリースにはrelease-6-2などの名前のブランチを使用してCVSを使用します。
新機能の開発は開発ブランチにのみ行われますが、バグ修正を開発ブランチと現在のリリースブランチの両方にチェックインする必要がある場合があります。これは時々かなり退屈になることがあるので、私はこれを達成するための実用的な方法を探しています。
コミットするファイルが2つのブランチで同期している場合、特に「これらのブランチにコミットする」ソリューションを探しています。
（私たちはソース管理システムとしてCVSを使用しているので、CVS固有の答えはどれでもいいです。しかし、他のソース管理システムがより良い方法を提供できるかどうかを確認することも興味深いです。クライアント側ではEclipseを使用しているので、Eclipseソリューションは良いですが、Eclipse以外のソリューションがある場合は、それでも問題ありません。）
必要な最も古いリリースブランチに修正を適用します。次に、最後のリリースブランチからHEADにマージするまで、変更を次のリリースブランチにマージします。
製品の最も古いバージョンが1.0であり、1.1と1.5のリリースもあるとします。次のリリースの新機能がHEADに追加されています。1.0でバグが見つかった場合は、1.0ブランチに修正を適用します。1.0から1.1ブランチにマージします。1.1から1.5ブランチにマージし、最後に1.5ブランチからHEADにマージします。
ブランチからブランチへのマージは、各ブランチに手動で修正を適用するよりも優れています。
CVSを使用する場合は、マージされるバージョンを手動で追跡する必要があります。これにより、次のマージを行うときに同じリビジョンが含まれないようになります。
Subversionを使用するように変更すると、ブランチからブランチへのマージが簡単になります。EclipseのSubversionツールは、以前にマージしたリビジョンを追跡し、2つのブランチ間で繰り返しマージを実行するタスクを大幅に簡素化します。
CVSからSubversionへの変更は簡単です。あなたはそのような動きをした最初の人ではありません。
awalsheが言ったように、ブランチ間でマージする方が良いです。マージをチェリーピックするには、CVS を使用した実用的なバージョン管理で説明されている方法が非常に優れています。
変更前のブランチ - タグ ( PRE_FOO) で、変更を行い、コミット、変更後のタグ ( POST_FOO) を行います。次に、トランクで、タグを使用してマージします。
cvs up -j PRE_FOO -j POST_FOO
ブランチ間のマージは SVN の方がはるかに簡単で安全です。CVS 履歴全体を SVN に変換するのは簡単です - cvs2svnを参照してください。SVN 1.5 を使用するか、以前の SVN バージョンではsvnmergeを使用する必要があります。