4

標準の Subversion トランク/ブランチ/タグ レイアウトがあります。中長期プロジェクト向けのブランチはいくつかありますが、リリース向けのブランチは今のところありません。これは急速に近づいています。

我々がすべき：

  1. リリース ブランチとプロジェクト ブランチを混在させますか?
  2. リリース フォルダを作成しますか? もしそうなら、リリースよりも良い名前はありますか?
  3. プロジェクト フォルダーを作成し、現在のブランチをそこに移動しますか? もしそうなら、プロジェクトよりも良い名前はありますか? 他のリポジトリで「サンドボックス」と「スパイク」を見てきました。
  4. まったく別の何か？
4

7 に答える 7

10

次の 2 つの理由から、次のレイアウトをお勧めします。 - 特定のプロジェクトに関連するすべてのものは、ツリーの同じ部分内にあります。人々が把握しやすくなります-この方法で権限の処理が簡単になる場合があります

ところで、多くのリポジトリではなく、少数のリポジトリを使用することをお勧めします。変更履歴は通常、その方が適切に保存されるためです (特別でやや複雑なアクションを実行しない限り、変更履歴はリポジトリ間でファイルを移動すると失われます)。ほとんどのセットアップでは、メイン リポジトリと、Subversion を試している人のためのサンドボックス リポジトリの 2 つのリポジトリのみが必要です。

project1
   trunk
   branches
     1.0
     1.1
     joes-experimental-feature-branch
   tags
     1.0.0
     1.0.1
     1.0.2
project2
   trunk
   branches
     1.0
     1.1
   tags
     1.0.0
     1.0.1
     1.0.2
于 2008-09-08T09:51:48.700 に答える
1

他の人が言ったことから離れて、私たちはアルファからベータ、製品への進行のかなり厳格な構造を持っています. アルファ コードは幹の頭が何であれ、ほとんどの部分で安定に保たれますが、常に安定しているわけではありません。リリースの準備ができたら、そのコードを効果的に凍結する「リリース ブランチ」を作成し、バグ修正のみを適用します。(これらはトランクに移植されます)。また、タグはリリース候補として定期的に作成されており、これらはベータ版です。コードが本番環境に移行すると、サポート、セキュリティ、およびバグ修正のためにリリース ブランチが開かれ、マイナー バージョンがタグ付けされ、これからリリースされます。

特定のバージョンがサポートされなくなったら、ブランチを閉じます。これにより、どのリリースでどのバグが修正されたかを明確に区別でき、トランクに移動されます。

長期間にわたってシステムを壊す大きな、長期的、または大規模な変更にも独自のブランチが与えられますが、これらは存続期間がはるかに短く、「リリース」という言葉が含まれていません。

于 2008-10-15T04:13:04.070 に答える
0

たとえば、バージョン 3.1 のリリースの準備をしたいときは、branches/3.1-Release ブランチを作成し、適切と思われるトランクから個々のコミットをマージします (リリース ブランチは通常、メインから最も重要な修正のみを受け取ります。開発ブランチ）。

通常、このリリース ブランチはアルファ版とベータ版のテスト段階を経て存続し、次のリリースがしきい値に達したときにクローズされます。

DVD をプレスするか、ダウンロード パッケージをアップロードしたら、リリース ブランチをリリース済みとしてタグ付けすることもできます。これにより、後で必要になった場合に、まったく同じリビジョンから簡単に再構築できます。

カール

于 2008-09-08T09:32:29.977 に答える
0

あなたが概説した多くの小さなプロジェクトではなく、1つの大きなプロジェクトの構造を持っていますが、私たちはすでにタグを使用しています.

この場合、1.0.0 などのタグを付ける必要がありますが、1.0 などのブランチも必要です。私の懸念は、プロジェクトブランチとリリースブランチを一緒に混在させることです。

branches
    this-project
    that-project
    the-other-project
    1.0
    1.1
    1.2
tags
    1.0.0
    1.0.1
    1.1.0
    1.2.0
    1.2.1
于 2008-09-08T09:35:12.390 に答える
0

もう 1 つの重要な考慮事項は、いつブランチを作成し、いつブランチを閉じるかです。これは、リリース スケジュールだけでなく、テストとリリースにかかる時間にも依存します。私の経験では、これには、チームの全員が計画が何であるか、いつ何を使用するかを確実に把握するという点で多くの管理が必要ですが、リリース wiki ですべてを文書化することですべてが助けられました。

あなたが探している答えとはかなり異なりますが、構造を整理したら、すでに多くの良い提案が得られていると思います。次の課題は、チームに情報を提供し、軌道に乗せることです。

于 2009-05-15T16:31:50.910 に答える
0

私が働いている場所には、「ブランチ」だけでなく、「temp-branches」と「release-branches」ディレクトリがあります。したがって、あなたの場合、プロジェクト ブランチは一時ブランチの下に置かれ、リリース ブランチ (もちろんリリース時に作成されます) はリリース ブランチの下に置かれます。

于 2008-10-15T03:55:00.067 に答える
-1

リリースはタグと同じです... トランク内に複数のプロジェクトがありますか? その場合、タグ内の同じフォルダーをコピーします

そう

trunk
     fooapp
         stuff...
     barapp
         stuff...
tags
     fooapp
         1.0.0
         1.0.1
     barapp 
         1.0.0
于 2008-09-08T09:28:18.163 に答える