web-dev-qa-db-ja.com

SVN命名規則：リポジトリ、ブランチ、タグ

次の命名規則が何であるかを知りたいだけです。

リポジトリ名ブランチタグ

現在、SVNで次の標準を採用していますが、改善したいと考えています。

  1. 各プロジェクトには独自のリポジトリがあります
  2. 各リポジトリには、タグ、ブランチ、トランクなどのディレクトリのセットがあります
  3. タグはツリーの不変のコピーです（リリース、ベータ、rcなど）
  4. ブランチは通常、機能ブランチです
  5. トランクは進行中の開発です（迅速な追加、バグ修正など）

そうは言っても、リポジトリの名前だけでなく、タグやブランチも誰もがどのように処理しているのか興味があります。たとえば、プロジェクト名にキャメルケース構造を採用していますか？

では、プロジェクトがBackyard Baseball for Younginsのようなものである場合、それをどのように処理しますか？

  • backyardBaseballForYoungins
  • backyard_baseball_for_youngins
  • BackyardBaseballForYoungins
  • backyardbaseballforyoungins

それはささいなことのように思えますが、それは問題です。

機能ブランチパラダイムを使用する場合、機能ブランチにどのように名前を付けますか？平易な英語での機能自体の後？ある種のバージョン管理スキーム？つまりユーザーが独自の統計を追加できる機能をBackyardBaseballアプリに追加するとします。あなたはあなたのブランチを何と呼びますか？

  • {repoName}/branchs/user-add-statistics
  • {repoName}/branchs/userAddStatistics
  • {repoName}/branchs/user_add_statistics

等.

または：

  • {repoName} /branchs/1.1.0.1

バージョンルートを使用する場合、バージョン番号をどのように関連付けますか？ 1人の開発者が「ユーザー統計の追加」機能に取り組んでいて、別の開発者が「管理者統計の追加」機能に取り組んでいる可能性があるため、機能ブランチはバージョン管理スキーマの恩恵をあまり受けないようです。これらはブランチバージョンにどのように名前が付けられていますか？彼らはいるほうがいいですか：

  • {repoName} /branches/1.1.0.1-ユーザーが統計を追加
  • {repoName} /branchs/1.1.0.2-admin add statistics

そして、それらがトランクにマージされると、トランクは適切にインクリメントする可能性がありますか？

タグは、バージョン番号から最も恩恵を受けるようです。

そうは言っても、プロジェクトのバージョン（トランク、ブランチ、タグなど）をSVNとどのように関連付けていますか？つまり開発者として、1.1.1に管理者が統計を追加し、ユーザーが統計を追加する機能があることをどのように知っていますか？これらはどのように記述的でリンクされていますか？タグは不変であるため、各タグにリリースノートを含めることは理にかなっています。

しかし、ええ、今後のSVNポリシーは何ですか？

svnrepository
21
StephenPAdams

トランク、タグ、ブランチモデルを使用します。

Trunk：は常に安定した形式である必要があります。 （必ずしもリリース可能である必要はありませんが、コンパイラエラーがないため安定しています）私は通常、小さな変更や、小さくて1日以内に完了することができる新機能を作成します。数日かかるものを開発していて、チェックインによってトランクが不安定な状態になる場合は、ブランチを作成します。

branches：は、トランクを不安定な状態のままにする可能性のある機能開発用です。また、新しい機能やアイデアを「テスト」するためにも使用されます。トランク内の最新の開発をブランチと同期させるために、トランクからブランチへの更新のマージを必ず実行します。

tags：は、すぐに戻りたいコードのリリースまたは安定したバージョン用です。通常、これらはモジュールまたはアプリケーションの特定のバージョン（1.00）に使用します。タグにチェックインしないようにしています。バグがある場合、それらの変更はトランクで行われ、次のリリースのためにそこにあります。私が作る唯一の例外は緊急バグのためです。これは、タグが適切にQAされ、非常に安定していることを意味します。

7
Jonathan S.

キャメルケース？いいえ、スペースが推奨されない傾向があることを除いて、名前に制限はありません。重要なのは内容であり、プレゼンテーションではありません。名前が何をするのか明確に定義されている限り、私たちは幸せです。

あなたができる最大の変更は、すべてのプロジェクトをトップレベルの単一のリポジトリに配置することだと思います。

何百ものプロジェクトがあり、それぞれがバージョン管理されたグループに分割されているため、ブランチやタグディレクトリは使用しません（つまり、バージョン管理されたベースプラットフォームがあり、各ベースバージョン番号の下に多数のプラグインがあります）

例えば：

base v1
  +--- moduleA
  +----moduleB
base v2
  +--- moduleA
  +----moduleB

各モジュールディレクトリの下にタグブランチを配置することを検討しましたが、ほとんどの場合、ヘッドバージョンを扱っているため、問題にはなりません。古いベースバージョンのモジュールから新しいモジュールへの変更を定期的にマージします。たとえば、ベースv1のmoduleAに変更を加えると、変更はベースv2のmoduleAにマージされます。必要な場合を除いて、後戻りはしません。

すべてのモジュールには、バージョン番号と変更点を説明するリリースノートがあります。ログコメントには、説明とバージョン番号の一部が含まれています。これにより、一意の名前が付けられたタグブランチを多数用意しなくても、以前のバージョンを簡単に入手できます。タグブランチの使用を開始した場合（提案されています）、フルパスコピーを/ tagsディレクトリに作成します）、単一のタグブランチにマージし、リリース番号をマークするログコメントを配置します。モジュールが多すぎて、ブランチごとに1つのタグフォルダとして管理できません。いいえ、過去のリビジョンに変更を加えることはありません。お客様が新しい機能を必要とする場合は、最新バージョンにアップグレードする必要があります（ベースプラットフォームのバージョンを変更するまで問題はありません）。

各モジュールのヘッドバージョンで作業する傾向があるため、ブランチも使用しません。主要な変更セットにブランチが必要な場合は、ベースレベルでブランチするため、「ベース」を作成します。 v2-パフォーマンス "ブランチとすべてをブランチします。これにより、多くの変更をグループ化するのが簡単になります。これは、私たちにとって最適な方法であるためです。個々のモジュールを分岐すると、リポジトリが煩雑になりすぎます。数百あるため、モジュールごとに分岐があると、モジュールを見失う可能性があります。

はい、トランクに変更を加えますが、これはワークフローで問題ありません。準備が整うまで、物事はコミットされません。古いベースバージョンに加えられたすべての変更はバグ修正のみであり、完全な開発-テスト-リリースサイクルでそれらを管理するにはモジュールが多すぎます。修正します。それが悪い修正であることが判明した場合は、再度修正します。大規模な開発のためにこのアプローチを変更し、branchsフォルダー（ルート外）にブランチを作成することがあります。ブランチパスは、元のモジュールへのパスを再作成します（したがって、それがどれであるかを簡単に識別でき、パスの先頭で/ branchsを/ trunkに変更するのと同じくらい簡単にマージできます）。

このシステムで遭遇した唯一の問題は、モジュールをWebアプリのプロジェクト（redmine）に配置するときです。モジュールのすべてのバージョンに対して単一のredmineプロジェクトが必要でしたが、レイアウトが悪かったため、リポジトリにルートを指定するのが少し難しくなりました。リポジトリパスをredmineの各バージョンに関連付けることができれば、この制限はなくなります。

必ずしもすべての人に最適であるとは限りません。ブランチをもっと使用することをお勧めしますが、これは私たちにとってはうまくいきます（以前のソース管理システムで「安全」であり、ブランチ/マージをサポートしていなかったためです。 ）。

1
gbjbaanb

リポジトリルートの下にtrunk、branches、tags、およびworkspacesがあります。

  • トランク-混乱を避けるために使用されていません
  • ブランチ-リリースブランチ。1つのリリース寿命は約1年で、製品名の頭字語と現在の年で名前が付けられています（LDN_FSHCHPS_REL_2010）
  • tags-不変のリリース/パッチラベル（svn copyで実行）、タイムスタンプ（LBL_20100526180134 = 2010-05-26 18:01:34）から自動的に生成され、バージョンをリリースしますv10.05.26.180134のように同じタイムスタンプから生成されるため、ラベルをバージョンに簡単にマッピングできます。
  • workspaces-機能/個々の開発者のブランチ、新しい開発の場合はbranchs/LDN_FSHCHPS_REL_2010から、パッチの場合はtags/LBL_20100526180134から成長し、分岐はsvn copy、backmerge --with-で行われますsvn merge、再統合はsvn merge --reintegrateで行われます。ワークスペースは、スクリプトによって自動的に生成されるWS_と同じように名前が付けられます（自動インクリメントのような）

すべてが1時間ごと/毎日などの単一のリポジトリにあります。バックアップ。分岐、ラベル付け、マージ、構築などのすべてのステップは、利便性と安定性のためにスクリプト化されています（スクリプトはリポジトリの一貫性をチェックします）。

分岐/マージは第2レベルのディレクトリでのみ許可され、完全なマージのみが許可され、個々のファイル/ディレクトリ（たとえば、branchs/LDN_FSHCHPS_REL_2010-> Workspaces/WS_345）は自動マージを有効にし、サブツリーのマージ情報の問題を回避します（また、簡単にするため）マージの問題が発生した場合の根本原因）

1
bobah