4

現在、次の状況に直面しています。

一部の開発者がコードを追加し続けるトランクを備えたSVNリポジトリがあります（想定どおり）

次に、さまざまなブランチ (図を参照) p1_test (テスト システム) と p1_live (実稼働システム) があります。

必要な手順は、X 日ごとにトランク (プロセス v¹) から p1_test ブランチを更新することです。次に、p1_test からの作業コピー内の「実際のファイル」が更新されます (v²)。

システム p1_test はテスト済みであり、すべてのバグ修正は p1_test ブランチにコミット (またはコミットする必要があります) され、p1_test システムが更新されます (再び v²)。一方、p1-cycle に関与していない他の開発者は引き続きトランクに追加します。これらの変更は、(まだ) p1_test ブランチに統合されるべきではありません。

最後に (p1_test) が安定していると見なされたら、ブランチ p1_live を p1_test ブランチから更新し、p1_test に加えられたすべての変更をトランク (v³) に再統合する必要があります。

特定の時点で v⁴ が実行されます。つまり、p1_live の作業コピーが p1_live ブランチから更新されます。

すべてが正常にテストされている必要がありますが、p1_live で重大な問題が発生した場合は、「ホットフィックス」するオプションが必要です。この場合、変更は p1_live ブランチに直接行われ、システムはこのブランチ (v⁵) から更新されます。

このプロセスは、未知の数の pX_test および pX_live システムと同時に動作する必要があります。

Svn 分岐スキーマ

これはsvnを使用しても可能ですか? 現在、さまざまなリビジョン番号、競合などの問題に直面しています。

指定された手順に従うことを可能にするバージョン管理システムはありますか?

敬具、タイムトリック

4

2 に答える 2

5

私たちはあなたと同じような使用パターンを持つ大規模なアクティブなコードベースにSubversionを使用します。標準のトランク/ブランチ/タグの基本階層があります。ブランチには、、、、がunstableありtestingますstable。また、branchsフォルダーにユーザー名ごとのフォルダーを持つ「user」ブランチがあります。タグはまさにその通りです。触れられないスナップショット。

trunk

branches/unstable
branches/testing
branches/stable
branches/userA/branch1
branches/userA/branch2
...

tags/stable/rNNNN
tags/stable/vN.N.N.N
...
  • Subversionを使用したすべての経験から、コードが一方向にのみ流れる場合は、Subversionの方がはるかにうまく機能することがわかりました。例外は、トランクからブランチを作成することです。もちろん、ブランチが完了したら、変更をトランクにマージして戻すことができます（一般にブランチの「再統合」と呼ばれます）。
  • コードが一方向に流れることができない場合は、少なくとも1つのパスにとどまる必要があります。つまり、ブランチのブランチは、たとえばトランクに直接再統合されるべきではありません。
  • 私たちの使用パターンは、バグ修正を含むすべてのアクティブな開発が常に最初にトランクに入り、次にトランクが不安定、テスト、および安定したブランチの更新プロバイダーになるというものです。（マージパスをたどってもかまいtrunk -> unstable -> testing -> stableませんが、テスト/リリースプロセスに固有の理由によるものではありません。）
  • 特定のブランチの修正がある場合は、そこに修正して、トランクにマージする予定はありません。私の経験では、これは、無実のブランチ更新ブレークコードを誤って取得したり、ブランチにまだ提供されていないコードをトランクから削除したりするための優れた方法であることがわかりました。

私の意見から、Subversionには、実際にそれを効果的に使用するためのプロセスが必要であり（そして私たちもそうします）、「今何？」あなたが説明し、理解しようとしていることはすべて、Subversionに関して私にはあまりにも馴染み深いように聞こえます。

GitやMercurialのようなDVCSツールに関する誇大宣伝が（まったく??）これらの問題を抱えていないことは、リポジトリ（数百）を移行するのにかかる時間の価値があるかどうかをよく考えました。私が試してみるのを妨げる唯一のことは時間の制約ですが、あなたはそれらのツールの1つを試してみるのに良い立場にあるかもしれません。

于 2012-09-19T15:18:19.283 に答える
2

さて、GITに乗り換えました。

この素晴らしいブログ投稿のおかげで、私はそれを立ち上げて実行することができました。（それは私が必要とするすべてを行い、さらに...）

于 2012-09-28T06:27:19.050 に答える