私たちの4人のチームは同じプロジェクトに取り組んでいます（どのようなプロジェクトを言うまで、後でそれについて書くことを望みます）
実稼働（ユーザーリクエストを処理する安定したブランチ）、ステージング（中間ブランチ）、トランク（開発ブランチ）の3つのSVNブランチがありました。
反復中（スクラム、 Scrumで作業中）、プログラマーは1つの開発ブランチ（トランク）にコミットします。その後、反復中に蓄積された変更とフィッティングはsvn mergeコマンドを使用してステージングブランチに転送されます。 。 さらに、本番環境で別のマージ（ステージングから安定）を行わないために、マージ後の本番環境でのパニックテストが続きます。 Webサーバーの設定を変更するだけでした。
$HTTP["host"] =~ "^.*somehost.com$" {
.................
server.document-root = "/path/to/the/stable/branch"
....................
}
$HTTP["host"] =~ "^.*somehost.com.staging$" {
.................
server.document-root = "/path/to/the/staging/branch"
....................
}
リリース後：
$HTTP["host"] =~ "^.*somehost.com$" {
.................
server.document-root = "/path/to/the/staging/branch"
....................
}
$HTTP["host"] =~ "^.*somehost.com.staging$" {
.................
server.document-root = "/path/to/the/stable/branch"
....................
}
つまり 反復の最後に、安定したステージングとステージングが入れ替わりました。 安定版はユーザーには見えなくなり、以前のステージングは本番になりました。つまり、ユーザーはそこに行きます。
だから私たちは1つの余分なマージを取り除きました...しかし、これは十分ではないように思われました:-)工学的思考よりも予測不可能なものはありません...
2番目のマージを削除することにしました。むしろ、残りのマージを削除することにしました。
そのため、問題の条件は次のとおりです。開発ブランチには常に最新の変更と2つのブランチが含まれ、それぞれが本番の役割を果たします。
開発からステージングへの最後のマージ中に、すべて異なるオペレーティングシステム（Arch linux、Mac OS、Windows Vista）、異なるIDE（Eclipse、Net Beans、Notepad ++、VIM）を使用しているという事実により、大きな問題に遭遇しました。 ）））そして、同じエディター内の異なる設定でさえ（今、私は統合エディター設定に関する仕様を書きます）。 この点で、キャリッジを変換するためにどこでも異なるシンボルシーケンスが使用され、一部のエディターはタブをスペースに置き換えています。
この点で、マージ中に競合は発生しませんでした。SVNはまだ死んでいました!!! 実際には同じコード。 そして、並べ替えを目的の形式にするには、すべてを手動で切り取る必要がありました。
しかし、ある時点で私たちの神経は我慢できませんでした！ そして、ステージングブランチを削除し（svn deleteステージング）、現在の開発ブランチ（トランク）を新しく作成したブランチ（svn copy trunk stagingコマンドを使用）にコピーしました。 あとは、新しく作成したブランチの構成を修正するだけです。これですべてです。
したがって、そのようなものとして、マージはありません。 各反復の終わりに、中間ブランチが削除されます（svn delete staging）
そして、新しいものが作成されます（svn copy trunk staging）。 そして、その構成がコミットされます。
私を悩ませた唯一のことは、リポジトリのサイズが急速に増大することでした。 しかし...私が覚えている限りでは、SVNは特にバブルアップ方法を使用してブランチを作成しているため、新しく作成されたブランチは既存のベースブランチへの単なる参照です。 そして、変更はこのベースブランチからの差分です。
したがって、リポジトリのサイズに関しては、非常に落ち着いています。
今、私はここにこの記事を書いており、QAはプロジェクトをステージングでテストしています:-)））
このアプローチについてのあなたの意見を聞くのは興味深いです。
Z.Y.
実際、Gitの統合に関する意見にさらに興味がありました
たとえば、Linus Torvaldsの言葉から：「Subversionでメインリポジトリを保持しているため、内部でgitを疑わずに使用している会社をいくつか知っていますが、多くの開発者はコードをgitにインポートします。合併。 したがって、Subversionからブランチツリーを取得してgitにインポートし、Subversionの主な頭痛の種となるgitをマージさせ、変更をコミットして実際にSubversionにエクスポートすると、他の誰もgitを使用したことがわかりません。 「少し悲しいが、まさにこのシナリオで多くの企業で働いていると聞いた.....」
Git Googleトーク