3

バージョン管理システムでタグを移動するのはなぜ悪い習慣なのですか? 私はよくこの一般的な提案に出くわしますが、その背後にある説明を見たことはありません.

注: 私が使用している「移動タグ」という用語は、CVS により関連性が高いと思われます。しかし、SVN の場合、タグ フォルダーの変更をコミットするだけの場合と同様の概念です。

私の特定の状況は次のとおりです。私はSVNを使用しています。ビルドシステムでタグを自動作成していきます。新しいタグを作成した直後に、ビルド システムはタグの説明情報をタグ付きファイルの 1 つに配置し、コミットして、この変更されたファイルのタグを移動します。

タグがプロジェクトに設定され、プロジェクトがテストされた場合、タグに変更を加えるとチーム間で誤解が生じる可能性があることは理解できます。誰かがタグの古いバージョンをチェックアウトし、別の人が新しいバージョンをチェックアウトするかもしれません。しかし、正式に発表される前にタグを変更することは何か悪いことでしょうか?

タグを移動するかどうかは、プロジェクトの種類 (商用、オープンソース、個人)、プロジェクトに取り組んでいる人数、タグ作成からの経過時間、開発プロセスの種類によって異なると思います。

4

3 に答える 3

3

タグは、ソース コードのプロジェクト全体の特定のリビジョンを表すためのものであり、他の目的で使用しないでください。とはいえ、この原則を厳守すると、リリース番号を飛ばさなければならなくなる可能性があり、これは受け入れがたいことかもしれません。

複雑なビルド プロセスでは、ほとんどの作業をリリース候補ブランチで試して実行し、最後の瞬間にのみタグを付ける必要があります。ただし、途中で何かを修正する必要がある場合があり、特にその存在がまだ公式に宣伝されていない場合は、タグ付きバージョンに小さな制御された変更を加えることが許容されると考えています.

于 2012-09-25T11:48:37.717 に答える
2

バージョン管理システムでタグを移動するのはなぜ悪い習慣なのですか?

それは一般的に受け入れられている慣習だからです。必要な結果を得るには、ルールに従わなければなりません。そうしないと、混乱と混乱が生じます。

あなたの場合、一般的なルールに違反する不適切な形式のワークフローがあります。「正しい方法」とは、ルールではなく、ワークフローを変えることです。

少なくとも 2 つの可能なバージョンが表示されます。

  1. リポジトリ リビジョン N からの CI チェックアウト、ビルドの成功時に WC にファイルを追加、トランクにコミット、トランク HEAD をタグにコピー (タグは N+2 になります)
  2. CI は現在のようにタグを作成しますが、追加のメタデータをこのタグのカスタム リビジョン プロパティ (プロパティ) として追加する必要があります ( svn help propset、propset PROPNAME --revprop -r REV PROPVAL [TARGET]バージョン)
于 2012-09-25T14:36:23.253 に答える
2

タグは通常、リポジトリの特定の状態の不変のスナップショットと見なされます。CI ツールなどのいくつかのツールは、この前提で動作します。これは重要なルールであり、プロジェクトの特定の状態を参照する独自の方法を確保します。

これは、SVN のリビジョン番号や Git の SHA1 コミット ハッシュのようなものです。人やツールがコミット識別子を使用してコミットを参照するとき、彼らは特定のバージョンについて話していることを確信しています。

同じことがタグにも当てはまります。リポジトリの状態がタグ付けされると変更できないというルールを使用する場合、問題が発生した場合、問題がすべての人に存在することを誰もが安全に想定できることを意味します (人とツールを含む)。アプリケーションが動作または誤動作する場合、その特定のタグをチェックアウトする人に対しても動作または誤動作します。

これは覚えておくべき非常に重要な概念です。この仮定を破ると、CI ログを読んだり、他の開発者と話したりするときに、参照するタグのバージョンを使用してデバッグしようとする時間が長くなる可能性が高くなるからです。

于 2012-09-25T11:33:52.093 に答える