リポジトリの観点から境界を定義する

Question

最初にシーンを設定します...

Subversionを使用しており、現在、かなり大きなメインリポジトリがあります。ただし、後日Gitに移行する可能性があるため、これを分析したいと考えています。その理由は、a）Gitはサブフォルダーのチェックアウトを行えないため、より小さなリポジトリを優先すること、b）より多くのブランチを使用できることです（機能ごとのブランチ）。

WebアプリケーションとWeb自動化アプリケーションがあります。

これらは、コードの点で互いに直接依存していません。しかし、自動化アプリはデザインの点でWebアプリに依存しています。 Webアプリで変更が行われると、自動化アプリが破損する可能性があります。

それらを別々のレポに分割したいのですが、良い点が挙げられました。それらを同じレポの下に置くと便利です。特定のリビジョンでは、両方が一緒に機能することがわかります。

2つの別個のレポジトリと2組のリビジョン番号でそれを理解することは、明らかに非常に注意が必要です。もう1つの問題は、多数のアプリがあることです（相互に依存している自動化アプリ、APIなどだけではありません）。

ただ人々の考えを見たかった。あなたがそのような問題に対処したことがあるなら？分割すべきかどうかなどを考えますか...何らかの展開ツールを使用して、連携する各リポジトリのさまざまなリビジョンを追跡しますか...

Answer 1

まず、svnリポジトリのクローンを作成します。次に、 git filter-branch で結果のgitリポジトリを分割できます。

2つのプロジェクトを再び依存させるには、サブモジュールを使用します。このようにして、1つのリポジトリを固定リビジョンで使用できます（ライブラリ、場合によってはWebアプリに便利です）

Answer 2

ツールに関しては、 Hudson を使用してビルドすると、リポジトリのセットと各ビルドで使用されるリビジョン番号。必要に応じて、これからタグ付けできます。

この方法で機能するツールを持っている場合、追跡するリビジョン番号の数を制限することはそれほど重要ではありません。このように分割します-1つの番号を手動で追跡できます。＆gt; 1はツールのサポートが必要です。ただし、複雑なツールである必要はありません。

単一のリポジトリを好みますが、それは単なる個人的な好みです。明確なリビジョン番号に基づいており、複数のリポジトリにリポジトリと番号が必要です。リポジトリの境界はポリシーの変更に基づいています（たとえば、これはコードに使用され、これは会社のドキュメントに使用され、これは展開に使用されます）。

Gitはそのように機能しないため、単一のレポを使用するオプションはありません。それは悪いことではなく、ほとんどのシステム（Hudson、Redmineなど）はこれを喜んでサポートします。

Answer 3

それらを分割すると、独自のバージョン番号で個別にリリースできますが、ご指摘のとおり、依存関係を追跡するのは難しい場合があります。 Antベースのビルドからmavenに移行して依存関係を支援し、いくつかの歯が生えたトラブルにもかかわらず、全体としては価値がありました。 （奇妙で素晴らしい方法でお互いのAPIに依存する複数のアプリがあります。）基本的なスキーマは、 Apache Portable Runtimeのバージョン番号。これは、バージョンが標準のMAJOR.MINOR.PATCH規則を使用する3桁のシステムです。

それらを分割するプロセスに関しては、まずSubversionで分割することをお勧めします。 gitに移動した場合、またはgitに移動したときに、変換用のリポジトリの関連部分にgit svnを指定するだけです。