1

私のオフィスでは、Visual Source Safe（6.0！）からMercurialに移行しており、状況を処理するための最良の「Mercurial」方法を見つけようとしています。現在、任意のプロジェクトリポジトリで、複数のバージョンを維持しています。つまり、プロジェクトAの場合、ProjA-Dev、ProjA-Rel1、およびProjA-Rel2のVSSリポジトリ（開発リポジトリと過去2つのそれぞれに1つ）があります。リリース）。

現在のところ、（ほぼ）すべての新しい作業は開発リポジトリで実行され、Rel1またはRel2にロールバックする必要があると見なされる変更は手動で行われます（VSSから独自の作業ディレクトリにチェックアウトされたファイル、次に、適切な変更のみをコピーする差分ツールを使用します）。ある時点で、新しいリリースがリリースされると見なされるため、開発リポジトリが複製されてProj * -Rev1になり、前のProj*-Rev1がProj*-Rev2になり、Proj*-Devが続行されます。何も起こらなかったかのように。Mercurialなどのはるかに近代的なツールでこれを達成するためのより良い方法があるはずだと私には思えます。

私の現在の考えでは、各プロジェクトには独自のリポジトリが必要であり、Dev / Rel1/Rel2の区別は異なる名前のブランチによって最適に処理されます。しかし、私が理解できない/見ている/頭を包み込むことができないのは、そのような環境で現在のワークフローをどのように達成するかです。現在のワークフローに従うと、開発ブランチで作業が衰えることなく続行され、特定の変更（すべてではありません！）がRelブランチにロールバック/オーバーされます。これはMercurialの移植/移植機能を介して達成できることを私は知っていますが、TortoiseHgではまだうまくサポートされていないようです。そして、もっと重要なことに、過去の回答は、これに対する最善の解決策は、物事が1で始まるような状態にならないようにすることであることを示唆しているようです。

質問は、現在のワークフローを考えると、そのような状態を回避するための最良の方法は何ですか？Mercurialと分岐に関する多数のガイド（ここにある多くの回答を含む）を読みましたが、この質問に対する明確な答えは見ていません。

4

1 に答える 1

6

これがあなたにぴったりかどうかはわかりませんが、Mozilla が Mercurial をどのように使用しているかについて、いくつかの情報を提供できます。私たちは 6 週間ごとに Firefox をリリースし、並行して実行されるいくつかの異なるブランチを用意しています。「ナイトリー」ビルドはすべてのアクティブな開発が行われるmozilla-centralリポジトリからビルドされ、「aurora」ビルドはmozilla-auroraリポジトリからビルドされます。リリース用にコードを安定させ、「ベータ」ビルドをmozilla-betaリポジトリからビルドし、そこで最終検証を実行し、ビルドをmozilla-releaseリポジトリからリリースします。これらの各リポジトリは、個別のクローンとして維持されます。

あるブランチから別のブランチに移動する実際のブランチの仕組みはやや複雑です。ブランチはすべて共通の歴史を共有していますが、オーロラ ブランチとベータ ブランチには、リリースの準備段階で選択されたセキュリティと安定性の修正プログラムが移植されるため、異なる歴史があります。正確なプロセスは、この段落の冒頭にあるリンクに記載されていますが、要約すると、「mozilla-central リポジトリにタグを付ける。mozilla-aurora の現在のヘッドにタグを付けて閉じる。ニューヘッド」。aurora->beta についても同じプロセスが繰り返されます。

開発から aurora または beta ブランチへの修正のバックポートは、変更セットを移植するだけの問題です。必要に応じてコマンドを使用できます。ブログhg transplantでその方法を文書化しました。

そうは言っても、これはほとんどのプロジェクトにとってやり過ぎかもしれません。名前付きブランチのツールが優れていなかったため、名前付きブランチの代わりに個別のリポジトリ クローンを使用しています。ここでは、より軽量なプロセスに名前付きブランチを使用できます。準備が整ったら、デフォルト ブランチから新しい名前付きブランチを作成し、開発がデフォルトで続行されている間に、必要に応じてそこに修正をバックポートします。

于 2012-08-28T13:55:53.213 に答える