1

私の会社は svn の使用に切り替えようとしています。リポジトリ構造に関するアドバイスを探しています。

現在、約 10 のプロジェクトと、プロジェクトによって使用されるものと使用されないものがある社内共通ソフトウェアのストアがあります。共通ソフトウェアは社内で変更されるため、それ自体がプロジェクトです。そのため、プロジェクトは無関係ですが、同じ共通のソフトウェアを共有している場合があります。

共通ソフトウェアを使用するプロジェクトは、常にベースライン バージョンを参照します。つまり、共通ソフトウェアは、(共通ソフトウェア プロジェクト自体を除いて) どのプロジェクトでも変更されません。

では、svn:externals を使用して共通のソフトウェア プロジェクトの「タグ付き」バージョンをフックして、プロジェクトごとに個別のリポジトリが最適でしょうか?

アドバイスをいただければ幸いです。

4

3 に答える 3

1

http://svnbook.red-bean.com/en/1.7/svn.reposadmin.planning.htmlの最初の例に従って、すべてを 1 つのリポジトリに配置することをお勧めします。COMMON は、他のすべてのプロジェクトに沿った 1 つのプロジェクトになります。

次に、各プロジェクトが現在使用している COMMON のバージョンを反映して、COMMON のリリース タグを各プロジェクトにコピーします。

レイアウト例:

/common
  /branches
    /common_improvements1
    /common_improvements2
  /tags
    /common-1.0.0
    /common-1.0.1
  /trunk
/projA
  /branches
    /stable-1.0
      /common (=copy of /projA/trunk@oldrev =copy of /common/tags/common-1.0.0)
    /stable-2.0
      /common (=copy of /projA/trunk@somerev =copy of /common/tags/common-1.0.1)
    /projA_ongoing_fix_branch
  /tags
    /1.0.1
    /1.0.2
    /1.1.0
    /2.0.0
    /2.0.1
  /trunk
    /common (=copy of /common/tags/common-1.0.1)
/projB
  (similar structures)
/projC
  (similar structures)

利点：

  1. COMMON とプロジェクト間の簡単なアクセスとトレーサビリティ
  2. 便利な場合、ユーザーは簡単に対話、テスト、およびお互いの努力をサポートできます
  3. COMMON リリース タグのコピーは、このプロジェクトで現在どのバージョンの COMMON を使用しているかという質問に答えます。

インポート中のオプションの手順:

サーバー上のファイル構造や別のバージョン管理システムなど、現在のすべてのプロジェクトに共通のレイアウトはありますか? もしそうなら、私はあなたに次のことをお勧めします：

  1. レイアウト全体を新しいリポジトリのフォルダーにインポートします (例: /root/old_layout)
  2. プロジェクト ファイルとフォルダーを svn リポジトリ内の新しいレイアウトに移動します。

これには、リビジョン ログが次の質問に答えるという利点があります。以前の構造では、このファイルはどこにあったのか? これは、開発者に新しい構造を教える際や、一時的なリソース (コンサルタントなど) がレイアウトの変更後に戻ってきた場合に非常に役立ちます。

于 2012-05-15T15:03:08.197 に答える
0

すべての開発者がすべてのプロジェクトで作業しますか? それとも、各開発者は特定のプロジェクトのみに取り組みますか?

前者の場合、各プロジェクトをブランチとして使用することを検討します (ブランチ間の切り替えはリポジトリ間の切り替えよりも簡単であるため)。新しいプロジェクト用に新しいブランチを非常に簡単に作成することもできます。

後者の場合、個別のリポジトリの方がおそらくクリーンで管理しやすいでしょう。

于 2012-05-15T09:46:02.917 に答える