web-dev-qa-db-ja.com

1つのSVNリポジトリ内の多くのプロジェクトのフォルダー構造？

私は Google Code SVNリポジトリを作成しました。これは、学校のプロジェクトと宿題を保存し、学校と家の間で簡単に転送できるようにするためです。

作成するデフォルトのディレクトリは次のとおりです。

https://simucal-projects.googlecode.com/svn/trunk/
https://simucal-projects.googlecode.com/svn/tags/
https://simucal-projects.googlecode.com/svn/branches/

私は複数のプロジェクトにリポジトリを使用したことはありませんが、読んだ後は 1つのsvnリポジトリですか、それとも多くですか？ ランダムな学校プロジェクトすべてに単一のリポジトリを使用することにしました。

上記のフォルダー構造を、プロジェクトごとに複製する必要がありますか？

https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/

https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/

これはあなたがマルチプロジェクトインワンレポの人々がしていることですか？

svnrepository
31
mmcdole

これには2つのオプションがあります。あなたがすでに言及したもの、そしてそれは各プロジェクトのためのトランクを持つことです（オプション1）：

https://simucal-projects.googlecode.com/svn/projectA/trunk/
https://simucal-projects.googlecode.com/svn/projectA/tags/
https://simucal-projects.googlecode.com/svn/projectA/branches/

https://simucal-projects.googlecode.com/svn/projectB/trunk/
https://simucal-projects.googlecode.com/svn/projectB/tags/
https://simucal-projects.googlecode.com/svn/projectB/branches/

オプション2は、各プロジェクトがトランクの下のサブフォルダーである1つのトランクを持つことです。

https://simucal-projects.googlecode.com/svn/trunk/projectA/
https://simucal-projects.googlecode.com/svn/tags/projectA/
https://simucal-projects.googlecode.com/svn/branches/projectA/

https://simucal-projects.googlecode.com/svn/trunk/projectB/
https://simucal-projects.googlecode.com/svn/tags/projectB/
https://simucal-projects.googlecode.com/svn/branches/projectB/

オプション1の利点は、各プロジェクトを個別に分岐およびタグ付けできることです。これは、各プロジェクトを個別にデプロイする必要がある場合に適しています。

オプション2は、すべてのプロジェクトが一緒にデプロイされる場合に適しています。これは、デプロイ時にリポジトリに一度タグを付ける必要があるためです。

学校のプロジェクトにSubversionを使用しているので、作品にタグを付ける必要があるかどうかを自問する必要があります。また、ブランチを作成する必要があるかどうかを自問することもできます（少し実験したい場合は、おそらく作成する必要があります）。また、すべての作業を1つにまとめてブランチできるかどうか、各プロジェクトを個別にブランチできる柔軟性を好むかどうかについても自問する必要があります。

私が常に従う経験則：一緒に展開するものは何でもトランクします。

（ちなみに、同じリポジトリに多くのトランクを置くことができます-これは、各リポジトリが独自のリビジョンカウンターを保持し、リポジトリ間でマージできないことを除いて、1つのトランクを複数のリポジトリに置くのとほぼ同じです。）

44
Trumpi

それが私のホームソース管理に使用するものです。

プライマリリポジトリが1つしかない場合。

リポジトリ/ Project1/Trunk
リポジトリ/ Project1 /タグ
リポジトリ/ Project1 /ブランチ

リポジトリ/ Project2/Trunk
リポジトリ/ Project2 /タグ
リポジトリ/ Project2 /ブランチ

私はこの構造が好きです。プロジェクトを参照して整合性を維持するのは非常に簡単です。

9
Quintin Robinson

実際の例：Apacheプロジェクト リポジトリ 。

6
Milen A. Radev

この質問に対する明確な答えはありません。プロジェクトに最も適したものに依存するからです。

  1. / projectA/trunkレイアウトを使用するのは、プロジェクトごとに激しい開発が行われていて、プロジェクト間（スタンドアロンのコンポーネント/プロジェクト）にそれほど関係がないため、すべてを分離する必要がある場合です。ただし、プロジェクトごとに1つのSVNリポジトリを使用することもできます。 svn co http：//..../svn/を使用してすべてのプロジェクトをチェックアウトすることはできません。これは、トランクだけでなく、すべてのプロジェクトからすべてのタグとブランチもフェッチするためです。
  2. / trunk/projectAは、プロジェクト/コンポーネントが緊密に属していて、それらを同じリビジョンからタグ付けしてブランチする必要がある場合（メインプロジェクトに非常に近いライブラリのように）には、確かに優れています。必要に応じて、svn co http：//.../svn/trunk/を使用して、最新のトランクリビジョンのすべてのプロジェクトを取得することもできます。

保守性の観点から、私はほとんど常に2番目の方法を好みます。ただし、プロジェクトが大きくなり、長期化する可能性がある場合は、プロジェクトごとに個別のリポジトリを使用することをお勧めします。

それ以外：宿題のために本当にGoogle Codeサービスが必要かどうかを確認してください。その目的はOSSをサポートすることです。常にローカルで、またはSSHを介してSVNを使用できるため、リポジトリをUSBスティックまたはリモートでアクセスできるコンピューターに置くこともできます。本当にホスティングは必要ありません。プライバシーの問題も考えられます。

2
Energiequant

リポジトリを1つだけにすることを主張し（私は私自身でキャンプをしていません）、ブランチングを行う場合、私はあなたの提案が良いと思います。しかし、繰り返しになりますが、SVNリポジトリはプロジェクトと同じだと思います。

2
Pawel Krakowiak

フォルダのレイアウト（バージョン管理で）を追跡する主な目標の1つは、アクセス制御管理です。

開発チーム（トランクで作業するチーム）と保守チーム（ブランチで作業するチーム）を分離する必要がある場合、この構造は適切です。

/trunk
      /Project1
      /Project2
/branches
         /Project1
         /Project2
/tags
     /Project1
     /Project2

すべてのプロジェクトから特定のユーザーグループへのアクセスを許可する場合は、次のような構造が適しています。

/Project1
         /trunk
         /branches
         /tags
/Project2
         /trunk
         /branches
         /tags
2
Mohsen Kashi