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

https://stackoverflow.com/questions/15674

08-06-2019
|

質問

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

    /NinjaProg/branches
              /tags
              /trunk
    /StealthApp/branches
               /tags
               /trunk
    /SnailApp/branches
             /tags
             /trunk

Ninja プログラムのトランクへのコミットを実行すると、それがリビジョン 7 に更新されたことがわかります。翌日、ステルスアプリケーションに小さな変更を加え、リビジョン 8 として戻ってきたとします。

質問は次のとおりです。 1 つの Subversion サーバーで複数のプロジェクトを維持する場合、関連のないプロジェクトのリビジョン番号がすべてのプロジェクトで増加することは一般的に受け入れられている慣行ですか? それとも私のやり方が間違っていて、プロジェクトごとに個別のリポジトリを作成する必要があるのでしょうか？それとも全く別の何かなのでしょうか？

編集： どちらのアプローチにも理由があることが明らかになったので、回答にフラグを立てるのが遅れました。この質問が最初にあったにもかかわらず、最終的に同じ質問をしている他の質問をいくつか指摘したいと思います。

すべてのプロジェクトを 1 つのリポジトリに保存する必要がありますか、それとも複数のリポジトリに保存する必要がありますか?

SVN リポジトリは 1 つですか、それとも複数ですか?

解決

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

しばらく前にこの問題について読んだのですが、本当に個人的な選択の問題のようです。このテーマに関する優れたブログ投稿がありますここ. 。編集： ブログが止まっているようなので(アーカイブ版はこちら）、この件に関してマーク・フィパードが述べたことの一部を以下に示します。

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

管理の簡素化。デプロイするフックの 1 セット。バックアップするリポジトリは 1 つ。等

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

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

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

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

グローバルリビジョン番号。これは問題ではないはずですが、問題であると認識し、リポジトリ上でリビジョン番号が進むことや、非アクティブなプロジェクトのリビジョン履歴に大きなギャップがあることを好まない人もいます。

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

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

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

他のヒント

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

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

また、各リポジトリのセットアップに時間がかかることが懸念される場合は、Apache 構成ファイルの SVNParentPath 変数を調べてください。(繰り返しますが、Apache を使用していることを前提としています。)

これは、Subversion の仕組みによるものです。各リビジョンは実際には、そのリビジョン番号で識別されるリポジトリのスナップショットです。すべてのプロジェクトがリポジトリを共有している場合、これは避けられません。ただし、私の経験では通常、まったく関係のないプロジェクトには別のリポジトリをセットアップします。つまり、短い答えは「いいえ、何も悪いことはしていません」です。これは Subversion に関するよくある質問ですが、リポジトリ情報をどのように保存するかを考えると当然のことです。

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

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

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

これに何も問題はありません。リビジョン番号の唯一の要件は、それが次のとおりであることです。

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

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

@グロム:

その後、新しいプロジェクトを開始するたびに、次のコマンドを実行するだけです。

svnadmin create /var/www/svn/myproject

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

プロジェクトごとに別のリポジトリを使用することをお勧めします。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

うーん、私が働いている場所では、すべてのプロジェクトが同じリポジトリにあります。それらを分離するメリットがまったくわかりません。新しいリポジトリの作成やユーザーへのアクセスの許可など、余分な作業が増えるだけではないでしょうか?プロジェクトがまったく無関係で、たとえばリポジトリにアクセスする必要がある外部顧客がいる場合には、個別のリポジトリが合理的だと思います。

私の職場には 2 つのリポジトリがあります。1 つはパブリック読み取りアクセス権を持ち、もう 1 つはその他すべてのアクセス権を持ちます。すべてに 1 つだけを使用しますが、パブリック/プライベートプロジェクトには異なるアクセス権が必要です。

とはいえ、私個人としては、更新のたびにリビジョン番号が増加することに問題があるとは考えていません。リビジョン番号は素数と偶数をスキップしても、本来の動作を行うことができます。特定のリビジョンに簡単にアクセスできるようにします。

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

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

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

以前のプロジェクトと同様に、リポジトリごとに 1 つのプロジェクトを保存します。コメント者これについて転覆の質問, 共有プロジェクトを外部としてマークし、ソース管理に一度だけ含まれるようにします。

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

ただし、見た目以外は好みの問題です（私の意見では）。

あなたが本当に考えるとき、複数のプロジェクトリポジトリの改訂番号は高くなりますが、あなたは使い果たされません。サブディレクトリで履歴を表示し、プロジェクトに関連するすべての改訂番号をすばやく確認できることに注意してください。

実際、Microsoft コードを構築していて、バージョン文字列の一部として svn リビジョン番号を使用している場合は、不足する可能性があります。バージョン文字列の一部が 65535 より大きい場合、Microsoft コンパイラはエラーをスローします。私たちの場合、リビジョン 68876 の大規模なリポジトリがあり、ちょうどこの壁にぶつかりました。

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

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

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

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

リビジョン番号は意味的には使用されません。唯一のことは、それらが順番に並んでいるということです。プロジェクトをダンプして別のリポジトリにインポートすると、バージョンに新しいリビジョン番号が付けられることがあります。それで 一度もない リビジョン番号を使用して、リリースまたは同様のものをマークします。リリース (関連するリビジョンのコピー) のタグを作成します。

以前の会社でも同じ問題がありました。1 つのリポジトリで 50 個ほどのプロジェクトを実行していましたが、svn 更新を行うと他の人に罵られるため、同じプロジェクトに取り組むのは悪夢でした。(笑)

私が学んだ、常に最もうまくいくことの 1 つは、1 つのプロジェクトに 1 つのリポジトリです。決して後悔することはありません。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow