CVSを使用して、次のように私の会社でのビルドプロセスが機能：転覆：CVSでタグを強制するのと同等
しかし、これは時間のようになります。私はここで説明するように手動でタグフォルダに分岐フォルダから変更されたファイルをコピーすることなく、これを行うための同等の方法を見ることができないのSubversionで
複数のファイルが変更された場合は、エラーが発生しやすくなります。
Subversionでタグを強制的に使用するより良い方法がありますか、それとも私たちのアプローチを完全に変更するだけですか？
おかげ
あなたがしなければならないことは、そのブランチをタグに再コピーすることだけです。 Subversionはすべてretagですが、CVSと異なり、名前の変更履歴を保存します。
しかし、私は
は、あなたのブランチやタグの名前を簡略化...いくつかのことをお勧めします。 CVSでは、ブランチとタグが同じ名前空間を共有していました。 Subversionでは、それらはしません。 RとBのプレフィックスは必要ありません。
アンダースコアを取り除く。 Subversionではドットを使用できます。たとえば、リリースはRelease_1_0ではなくRelease-1.0になります。ヘック、私はReleaseの部分でも気にしませんでした。タグ1.0と支店1.0を呼び出してください。
今、主なもの：タグを再利用しないでください！ダメダメダメ。これはCMコミュニティーでと呼ばれています。逆パターンです。 アンチパターンは、悪いCMプラクティスです。
CVSがCVSとは異なり、CVSのタグと変更の履歴を保持しているので、CVSのSubversionと同じように、Subversionのタグを動かすほど悪くありません。ただし、タグは特定の時点のスナップショットである必要があります。つまり、リリース1.0について言えば、と言っている必要はありません。「先週にリリースしたバージョン1.0、またはその前の週は、ですか？
私はあなたのしていることを理解していますが、より良い方法があります。まず第一に、Subversionのタグ付けは非常に簡単です。 svn cp...を実行すると完了です。 CVSでは、40〜50分かかる可能性があります（これはおそらくあなたがタグ再利用事業を開始した理由です）。
タグの末尾に何かを追加することをお勧めします。例えば、1.0-2012-2-29のようなものを置くことができるので、2012年2月29日にリリース1.0について話していることを知っているでしょう。まだ1.0で始まっているのでリリース1.0ですが、あなたはを知っていますリリース1.0あなたが話している。
なぜこれらのリリースにラベルを貼っていますか？ Subversionでは、多くの人が単純にSubversionリビジョンIDをクイックタグとして使用します。あなたのソフトウェアのリビジョン20321について話すことができます。実際のリリースを実際に行ったときにタグを付けます。
私たちはビルドシステムとしてJenkinsを使用しているので、コミットごとに別々のビルドがあります。 QAはテストのためにジェンキンスのビルドをすぐに利用します。私たちの開発者は、リリース1.0のBuild＃29（リリース1.0はブランチへの参考にすぎません）と言っています。後でQAがリリース用の特定のビルドを認定したと言い、Jenkinsに戻ってその特定のビルドをRelease-1.0などのものとしてタグ付けします。
最後に、各ビルドにRelease-1.0-B-xxxというタグを付けました。ここで、「xxx」はJenkinsのビルド番号です。これらのビルドタグは、Subversionリポジトリに/project/tags/BUILDS/の下に置いてありますので、リリースの内容を確認するためにsvn ls /project/tagsを実行するときに表示されません。実際にリリースされた時点で、ビルドタグを実際のリリースタグにコピーします。
$ svn cp http://build/src/foo/tags/BUILDS/1.0-B-233 http://build/src/foo/tags/1.0
この情報が役立ちます。 Subversionは、CVSにあった多くの問題を処理します。タグ付けは瞬時に行われ、リポジトリ内のすべての変更にはリポジトリ全体のリビジョン番号があり、単にビルドタグとして使用することができます。さらに、タグを移動しても、変更が行われたとき、変更が行われたとき、そして誰がそれを行ったのかを追跡します。あなたは新しいタグと古いタグとの間の差分を尋ねることさえできます。
ただし、タグは変更できません。私はタグを作成することができますが、一度設定されると変更することはできません。
変更あなたのアプローチは：あなたは、バイナリのセットをリリースした後、同じものであることをふりをバイナリの異なるセットをリリースしています。これは良いことではありません。
SVNでリリースブランチを作成することは簡単です。変更すると、別のディレクトリにコピーされてしまいます。コピーは安いので、何度もやってください。唯一の問題は、分岐ディレクトリがたくさんあることですが、古いものは削除することができます。
リリースブランチに修正を加えたら（変更はOKですが）、変更をトランクにマージする必要があります。これは簡単で、タグブランチからトランクにディレクトリ全体をマージする。変更されたファイルのみがマージの一部になります。これは、SVNがパッチ適用メカニズムを使用してマージを実行するため、行われた変更がトランクに適用されます。
また、修正をトランクにしてリリースブランチにマージすることもできますが、修正を含む個々のリビジョンに対してのみ行うことはできますが、トランクコードが大幅に変更される危険性がありますマージは難しい。
3番目のオプションは、リリースブランチを新しいリリースブランチにブランチし、そこで修正を加えることです。 SVNには原子リビジョン番号があるので、リリースブランチに直接修正を適用し、リビジョン番号の2つのセットを書き留めることができます - R_Release_1_0 v 1はオリジナルです、R_Release_1_0 v2は固定されていますが、これを行うベストプラクティスではありません（これは私たちがやることです。それは私たちのために働くので、私はそれを批判するつもりはありません。あなたは何をしているのか、理由を正確に理解する必要があります）。