svn - 複数のプロジェクトにわたるSubversionリビジョン番号

Question

複数のプロジェクトでソース管理にSubversion（svn）を使用すると、すべてのプロジェクトのディレクトリでリビジョン番号が増加することに気付きました。私のsvnレイアウトを説明するために（架空のプロジェクト名を使用して）：

    / NinjaProg / branchs
              / tags
              /トランク
    / StealthApp / branchs
               / tags
               /トランク
    / SnailApp / branchs
             / tags
             /トランク

忍者プログラムのトランクにコミットすると、リビジョン7に更新されたとしましょう。翌日、ステルスアプリケーションに小さな変更を加えて、リビジョン8として戻ってきたとします。

問題はこれです：1つのSubversionサーバーで複数のプロジェクトを維持する場合、すべてのプロジェクトで無関係のプロジェクトのリビジョン数を増やすことは一般的に受け入れられている慣習ですか？それとも私はそれを間違って行っており、プロジェクトごとに個別のリポジトリを作成する必要がありますか？それともまったく別のものですか？

編集：両方のアプローチの理由があることが明らかになったため、回答のフラグ付けを遅らせました。この質問が最初に来たとしても、最終的に同じ質問をしている他のいくつかの質問を指摘したいと思います。

すべてのプロジェクトを1つのリポジトリまたは複数に保存する必要がありますか？

1つのSVNリポジトリまたは複数？

score 9 · Accepted Answer

これについて、オンラインで無料で入手できる Subversion を使用したバージョン管理で議論されていることに誰も言及していないことに驚いています。

私はしばらく前にこの問題について読みましたが、それは本当に個人的な選択の問題のように思えます。編集:ブログがダウンしているように見えるので (アーカイブバージョンはこちら)、この件に関して Mark Phippard が言わなければならなかったことの一部を以下に示します。

これらは、単一リポジトリアプローチの利点の一部です。

シンプルな管理。デプロイする 1 セットのフック。バックアップする 1 つのリポジトリ。等

ブランチ/タグの柔軟性。コードがすべて 1 つのリポジトリにあるため、複数のプロジェクトを含むブランチまたはタグを簡単に作成できます。

コードを簡単に移動します。おそらく、あるプロジェクトからコードのセクションを取り出して別のプロジェクトで使用したり、複数のプロジェクトのライブラリに変換したりしたいと思うでしょう。同じリポジトリ内でコードを移動し、プロセス内のコードの履歴を保持するのは簡単です。

ここでは、単一リポジトリアプローチの欠点と、複数リポジトリアプローチの利点をいくつか示します。

サイズ。1 つの大きなリポジトリよりも、多数の小さなリポジトリを扱う方が簡単な場合があります。たとえば、プロジェクトを廃止する場合は、リポジトリをメディアにアーカイブしてディスクから削除し、ストレージを解放できます。新しい Subversion 機能を利用するなど、何らかの理由でリポジトリをダンプ/ロードする必要があるかもしれません。リポジトリが小さい場合、これは簡単に実行でき、影響も少なくなります。最終的にすべてのリポジトリに対して実行したい場合でも、一度にすべてを実行する必要が差し迫っていないと仮定すると、一度に 1 つずつ実行する方が影響は少なくなります。

グローバルリビジョン番号。これは問題ではありませんが、一部の人々はそれを 1 つと認識し、リポジトリでリビジョン番号が進むのを好まず、非アクティブなプロジェクトのリビジョン履歴に大きなギャップがあることを好みません。

アクセス制御。Subversion の authz メカニズムにより、必要に応じてリポジトリの一部へのアクセスを制限できますが、リポジトリレベルでこれを行う方が簡単です。選ばれた少数の個人のみがアクセスできるプロジェクトがある場合、そのプロジェクトの単一のリポジトリを使用する方が簡単です。

管理の柔軟性。複数のリポジトリがある場合は、リポジトリ/プロジェクトのニーズに基づいてさまざまなフックスクリプトを実装する方が簡単です。統一されたフックスクリプトが必要な場合は、単一のリポジトリの方がよいかもしれませんが、各プロジェクトに独自のコミットメールスタイルが必要な場合は、それらのプロジェクトを別々のリポジトリに置く方が簡単です。

よく考えてみると、複数のプロジェクトリポジトリのリビジョン番号は高くなりますが、不足することはありません。サブディレクトリの履歴を表示して、プロジェクトに関連するすべてのリビジョン番号をすばやく確認できることに注意してください。

score 6 · Accepted Answer

プロジェクトごとに個別のリポジトリを作成することを強くお勧めします。あなたが話しているシナリオを回避する以外に何もありません。

バージョン管理、特にSubversionを使用すると、リポジトリの一部を別の作業コピーに簡単にチェックアウトして、それぞれのリポジトリにコミットすることができます。これにより、柔軟性を大幅に高めながら、それらを明確に分離して区別することができます。SVNにもう少し入ると（私はあなたが新しいと思います）、フックを使い始めることができ、セットアップでそれがどこで難しくなるかがわかるかもしれません。許可が重要な場合は、単一のリポジトリが必要以上に難しいことがわかる場合があります。

また、各リポジトリのセットアップに時間がかかることが心配な場合は、Apache構成ファイルのSVNParentPath変数を調べてください。（繰り返しになりますが、Apacheを使用していると思います。）

score 4 · Accepted Answer

これは、Subversionがどのように機能するかによるものです。各リビジョンは、実際にはそのリビジョン番号で識別されるリポジトリのスナップショットです。すべてのプロジェクトがリポジトリを共有している場合、それは避けられません。ただし、通常、私の経験では、完全に無関係なプロジェクト用に個別のリポジトリを設定します。つまり、簡単な答えは、何も悪いことをしていないということです。これは、Subversionを取り巻く一般的な質問ですが、リポジトリ情報をどのように格納するかを考えると理にかなっています。

score 4 · Accepted Answer

リビジョン番号は、実際には特定のバージョンの識別子にすぎないはずです。プロジェクトに対してシーケンシャルであるかどうかは重要ではありません。そうは言っても、それは理想的とは言えないことは理解できます。

私が遭遇したほとんどのプロジェクトは単一のリポジトリにセットアップされており、リビジョンIDはこのように動作します。この動作を変更するためのSVN構成オプションはわかりません。また、IMHOは、複数のリポジトリーを維持することは不必要なオーバーヘッドのようです。

score 4 · Accepted Answer

あなたの例とほぼ同じように、すべてが入ったリポジトリが 1 つだけあります。

私はこれに何か問題があるとは思いません - リビジョン番号の唯一の要件は、それが

個性的
アトミック
前回のチェックイン時よりも大きい

私に関する限り、コミットごとに 1 増加するか 50 増加するかは問題ではありません。

@グロム:

次に、新しいプロジェクトを開始するたびに、次を実行します。

svnadmin create /var/www/svn/myproject

開発者が 1 人か 2 人しかいない場合は問題なく動作することがわかりますが、新しいプロジェクトを作成しているユーザーが SVN サーバーで /var/www の下にディレクトリを作成できるシェルアクセス権を持っていない場合はどうなりますか?

score 3 · Accepted Answer

At my workplace, we have two repositories. One with public read access, and one for everything else. I'd use just one for everything, but we need different access rights for public/private projects.

That said, I personally don't see the problem with the revision numbers incrementing on every update. The revision numbers could skip prime and even numbers and still do what its supposed to do. Make it easy to get to a specific revision.

score 3 · Accepted Answer

プロジェクトごとに個別のリポジトリを使用することをお勧めします。私の Apache conf.d ディレクトリには、以下を含む subversion.conf があります。

<Location /svn>
  DAV svn
  SVNParentPath /var/www/svn

  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /var/www/svn/password
  Require valid-user
</Location>

次に、新しいプロジェクトを開始するたびに、次を実行します。

svnadmin create /var/www/svn/myproject

score 3 · Accepted Answer

うーん、私が働いている場所では、すべてのプロジェクトが同じリポジトリにあります。それらを分離する利点は本当にわかりません。それは、新しいリポジトリの作成、人々へのアクセスの許可など、多くの余分な作業を作成するだけではありませんか? プロジェクトがまったく関係がなく、リポジトリにアクセスする必要がある外部の顧客がいる場合は、別々のリポジトリが理にかなっていると思います。

score 2 · Accepted Answer

たぶん、必ずしも「プロジェクト」ごとに1つのリポジトリを作成するのではなく、「ソリューション」ごとに1つのリポジトリを作成するのが最善です（Visual Studioの用語を使用するため）。異なるフォルダに多数の「プロジェクト」があり、それらが相互に関連している場合は、それらを同じリポジトリに配置します。

score 2 · Accepted Answer

他のプロジェクトに基づいてリビジョン番号を変更するのが面倒な場合は、プロジェクトを別のリポジトリに配置してください。これが、リビジョン番号を独立させる唯一の方法です。

私にとって、異なるリポジトリを使用する大きな理由は、ユーザーに個別のアクセス制御を提供したり、異なるフックスクリプトを使用したりすることです。

score 1 · Accepted Answer

リポジトリごとに1つのプロジェクトを保存し、このSubversionの質問に対する以前のコメントのように、共有プロジェクトを外部としてマークして、ソース管理に1回だけ入るようにします。

CIビルドサーバー（CruiseControl.NET）を追加し始めたばかりなので、すべてがどのように機能するかを確認する必要がありますが、ビルドスクリプトが正しければ、問題はないはずです。

見た目以外は、本当に好みの問題です（私の意見では）。

score 0 · Accepted Answer

以前の会社でも同じ問題がありました。以前は1つのリポジトリで50のプロジェクトが実行されていましたが、svnの更新を行うと他の人が呪うため、同じプロジェクトで作業するのは悪夢でした。

私が学んだことの1つは、常に最も効果的であるということです。Oneproject OneRepo....後悔することはありません。

score 0 · Accepted Answer

リビジョン番号には意味的な用途はありません。唯一のことは、それらが順番に並んでいるということです。プロジェクトをダンプして別のリポジトリにインポートすると、バージョンで新しいリビジョン番号を取得できます。したがって、リリース番号などをマークするためにリビジョン番号を使用しないでください。リリースのタグを作成します（関連するリビジョンのコピー）。

score 0 · Accepted Answer

@Daniel Fone: SVN ドキュメントでは、リポジトリごとに 1 つのプロジェクトを推奨しているため、作成者が意図したとおりです。1 つのサーバー (apache または svnserve) で複数のリポジトリを維持できるため、オーバーヘッドが大きすぎるという問題に遭遇したことはありません。VisualSVN Serverを使用すると、Apache サーバーのインストールと複数のリポジトリの構成が簡単になります。

score 0 · Accepted Answer

プロジェクトごとに 1 つのリポジトリ。

CC.NET に関する Steven Murawski のコメントは興味深いものです。複数のソース管理リポジトリを指定する必要がある場合、どのように機能するかを知りたいです。

score 0 · Accepted Answer

SVN ドキュメントが実際にリポジトリごとに 1 つのプロジェクトを推奨しているかどうかはわかりません。ほとんどの場合、各パスの長所と短所について話します。私はたまたま 3 つの異なるリポジトリを使用しています。1 つはすべて関連する 7 つまたは 8 つのプロジェクト用です。1 つのリビジョンからビルドするだけで (または互換性があることを確認することで)、すべてのプロジェクトの互換性のあるコピーを送信できるのは非常に便利です。それぞれのリビジョン番号で)。2 番目のリポジトリには、関連するプロジェクトとドキュメントの別のグループがあり、3 番目のリポジトリははるかに小さいものです。これにより、関連するプロジェクトは単一のリビジョン番号で管理できるが、関連のないプロジェクトはリポジトリに影響を与えないという事実を利用できます。

svn - 複数のプロジェクトにわたるSubversionリビジョン番号

17 に答える 17

Related

Reference