GitまたはSubversionを使用して既存のコードリポジトリを再構築/再作成する作業を成功させました。この特殊なケースでは、リポジトリ履歴は必ずしも重要ではありません。状況を分析した後、私は良いレイアウトを決定するいくつかの問題を見つけました。私は多くのブログやスレッドを読んだことがありますが、私はまだ最良のレイアウトが何であるかについてはまだ分かりません。いくつかのライブラリとアプリケーションからなるリポジトリを構成する方法
既存のリポジトリには、インクルードファイルのセットと、部分的に依存するライブラリセットが含まれており、その多くはインクルードファイルのセットに依存します。さらに、ライブラリのセットに依存する2つのアプリケーションプロジェクトがあります。さらに、アプリケーションの1つと追加の構成情報を使用する一連のスクリプトがあります。
が+---------->include files
| ^
| |
library A -----> library B <----- library C <----- library D
^^ | ^
| | | |
| +--------------------------------+ |
| |
application 1 application 2 --------------------+
^
|
script -----> configuration information
目標は、各コンポーネントはとして独立して可能な限り開発することができ、レイアウトを持つこと、そして（外部顧客向け）のリリースを持つことであるセットが含まれています。私は状況を明確にするために、グラフを描画しました定義されたタグバージョンのすべてのコンポーネントを削除することができます。これにより、特定のリリース用のソフトウェアを適時に作成してビルドすることができます。
私は次のような構造を作ってみた：
trunk/
include/
lib/
library A/
library B/
library C/
library D/
app/
application 1/
application 2/
tags/
1.0/
include/
lib/
library A/
library B/
library C/
library D/
app/
application 1/
application 2/
1.1/
include/
lib/
library A/
library B/
library C/
library D/
app/
application 1/
application 2/
...
たびに私は、私は単に、タグに新しいサブディレクトリにリポジトリ全体をコピーする新しいリリースを作成します。
このソリューションの問題点は、ライブラリにタグディレクトリが別に存在しないこと、タグ付きコンポーネントで構成されるリリースのみを使用したいということです。このソリューションでは、どのコンポーネントにどのタグバージョンリリース。私は別のリポジトリを使うことを考えていましたが、 `svn：externals 'と特定のタグのサブディレクトリを使って必要なコンポーネントをリンクするリリースのサブディレクトリを持つマスターリポジトリを作成しましたが、コードを別のエンティティに分割する方法を理解していません。
アイデア？
===============質問は、28-1-2011 =============== [OK]を
に続きます新しいレイアウトをどのように計画するかのグラフを描きました。目標はさまざまな依存関係の タグを1つの リポジトリ内のsvn：externalsメソッドとリンクすることです。例えば、^/tags/projects/includeの trunk/projects/lib/library2/dependenciesにsvn：externalsを設定します/std/1.3。
trunk/
projects/
include/
std/
lib/
library1/
dependencies/
std/ --> tags/projects/include/std/1.2
library2/
dependencies/
std/ --> tags/projects/include/std/1.2
library1/ --> tags/projects/lib/library1/1.4.3
library3/
dependencies/
std/ --> tags/projects/include/std/1.3
library1/ --> tags/projects/lib/library1/1.4
app/
application1/
dependencies/
library3/ --> tags/projects/lib/library3/1.1
application2/
dependencies/
library1/ --> tags/projects/lib/library1/2.1
application3/
dependencies/
std/ --> tags/projects/include/std/1.2
library2/ --> tags/projects/lib/library2/1.5.2
config/
configuration1/
dependencies/
application1/ --> tags/projects/app/application1/2.3
configuration2/
dependencies/
application1/ --> tags/projects/app/application1/1.6
configuration2/
dependencies/
application2/ --> tags/projects/app/application1/1.6
tags/
projects/
include/
std/
1.2/
1.3/
lib/
library1/
1.4.3/
1.4/
2.1/
library2/
1.5.2/
library3/
1.1/
app/
application1/
1.6/
2.3/
branches/
...
残りの質問：
- は、この設計実行可能です、またはあなたはすべての主要な欠点を見ていますか？
- ライブラリをタグディレクトリにコピーするとどうなりますか？これにより、 svn：externalsプロパティもコピーされます。これは問題を引き起こすか、またはこの動作が望まれますか？
- すべての外部に対して明示的なリビジョンを指定できますが、タグは変更しないでください。ディレクトリで十分ではありませんか？
- リポジトリを開発リポジトリとsvn：externalを使用するリポジトリに分割する方がよいでしょうか？質問What's the benefits of "svn:externals"?の回答「ユースケース」を参照してください。
あなたの質問はGitとどのように関連していますか？あなたが示した構造は完全にSubversion固有のものです。 – ssmir
Google/Wikipediaに続いて、Gitは実際のタグ付けをサポートしています。質問はタグに関するものです。ですから、GitでSubversionよりも優れたソリューションを作ることができるのであれば、Gitに切り替えることもできます。 OSSだけでSubversionに依存しているわけではありません。 – hochl