3

SVN で次の一般的な StarTeam タスクを実行する方法を知りたいです。

1. タグを更新して、1 つのファイルだけの新しいリビジョンを含めるにはどうすればよいですか?

StarTeam でビュー ラベルを作成した後(SVN のタグに似ています) - ファイルの新しいリビジョンをそのビュー ラベルに含めることができました。そのビュー ラベルの作成

2. 別のタグに基づいてタグを作成する方法は?

バージョンをリリースしながら開発を続けると、チェックインされていても含まれない機能もあります。StarTeam では、以前のビューに基づいてビュー ラベル (タグのようなもの) を作成していました (そして、説明したことを実行します)。質問1）で。SVN では、別のタグに基づいてタグを作成できることを理解していますが、それは読み取り専用であり、ブランチが必要です。しかし、本当にブランチは必要ありません。

3. 既存のタグにチェックイン/追加する方法は?

StarTeam では、ビュー ラベルはトランク/ブランチ上にあるため、ビューが作成された後にファイルをチェックインし、それを含めるようにラベルを変更できます。SVN では、ブランチにチェックインする必要があります。

4

1 に答える 1

7

私は StarTeam に精通していないため、再現しようとしているワークフローを完全には理解していない可能性があります。

Subversion 自体は、タグとブランチを区別しません。慣例により、タグは決して変更しない単なるブランチです。ブランチでさえ単なる「svn コピー」操作であり、別個の「ブランチ」機能はありません。ブランチはただの安価なコピーであり、タグは規約によってのみ読み取り専用のブランチです。svn のコピーは非常に安価であるため、ブランチの作成について心配する必要はありません。タグはブランチよりも安価ではありません。ブランチの作成に関するドキュメントを読むことをお勧めします。それはさらに物事を説明します...そして、「安価なコピー」についてのボックス化されたセクションがあります.

StarTeam での「View Labels」の使用方法によっては、svn externalsが目的に役立つ可能性があります。私は一般的にそれらが好きではありませんが、シナリオによって異なります。

あなたの質問にもっと直接...

1) これは、ファイルに他の変更があるかどうかによって異なります。1 つのリビジョンからの変更を 1 つのファイルに保存しますか? または、1 つのファイルのすべての変更 (複数のリビジョン、1 つのファイルのみ)。うまくいけば、あなたは前者を意味します。その場合、通常の動作はマージすることです

次のシナリオがあるとします。

------------------------------------> /trunk
 |     | fix merged to 1.0 branch
 |     v
  \------------> /branches/1.0
    |  ^ |
    |    \ /tags/1.1  1.1 tag, fix released to customer(s)
    \ /tags/1.0 - 1.0 GA tag, release sent to customer(s)

トランクで開発します。リビジョン 10 で、製品はすでに 1.0 を出荷する準備ができています! 以下を使用してブランチを作成します。

svn copy /path/to/trunk /path/to/branches/1.0

その後、trunk での開発を続けながら、1.0 ブランチで追加の検証を少し行います。出荷の準備ができたら、タグを作成します。

svn copy /path/to/branches/1.0 /path/to/tags/1.0

このタグは、顧客に出荷するものと正確に一致する凍結された時点です。

1.0 リリースの顧客に必要なバグ/機能/更新が、トランクで既に行われていることを発見しました。あなたの場合、特定のファイルへの変更を述べました。

リビジョン 15 のトランクで変更が発生したとします。次に、(クリーンな /branches/1.0 作業コピーから) 次のようにします。

svn merge -c 15 /url/to/repo/path/to/trunk

理想的なケースでは、リビジョンの変更は自己完結型であり、リビジョン内のすべてのファイルが必要です。マージしたくない余分なものがある場合もあります。この場合、マージ後に、マージしたくないファイルへの変更を元に戻し、すべてをテストしてからコミットします。マージ -> 一部のファイルを元に戻す -> コミット ワークフローには欠点があります。これは、Subversion がマージが発生したものとして記録するにもかかわらず、その一部を除外していることです。問題のブランチがさらに変更される可能性が低い (または別のブランチに再統合される) 場合は問題にならないかもしれませんが、必要な 1 つのファイルの変更に対してパッチ ファイルを作成し、場合によっては手動でブランチに適用することをお勧めします。そのように。コマンド行の構文については 100% 確信があるわけではありませんが、非常に似ていると思います。

svn diff -c 15 /path/to/file (リポジトリまたは他の作業コピー内) > my-patch.diff

別のツールで適用します。私は通常、GUI でパッチを作成/適用するので、詳細は演習として残します。

それが完了したら、ブランチから新しいタグを再度作成します。これには、新しいマージされた変更が含まれます。

svn copy /path/to/branches/1.0 /path/to/tags/1.1

次に、1 つのファイルに変更があることを除いて、古いタグと同じ新しいタグがあります。＃3では、タグを再作成できることにも言及します（ただし、それが良いアイデアであるかどうかは、タグを何に使用しているかによって異なります）. r、しかし、タグが出荷されたコードを表していない場合にのみこれを行います.

2) 実際、タグは慣例により読み取り専用であるため、別のタグのタグは実際には違いはありません。ただし、代わりに最初のブランチにブランチを使用し、それからタグを作成する場合 (推奨どおり)、後で同じブランチに基づいて 2 番目のタグを作成できます (追加の変更をコミットした後)。最初のタグとは異なります。それ以降にそのブランチに適用された変更のみによってタグ付けされます。

3) 繰り返しますが、通常はブランチを使用します。ブランチ/タグが内部でのみ使用されている場合 (出荷されたコードのリリース タグを削除することはお勧めしませんが、実際には「失われた」わけではありませんが、通常は必要ないはずです - )、削除して再作成するだけです。タグ。タグ (作業コピー) のコンシューマは、タグが削除されて再作成された後、通常の「svn update」を実行するだけで、何も起こらなかったかのように正常に動作し続けます。これは＃1には使用できませんでしたが、タグを更新したいだけの場合は＃2に使用できます。秘訣は、タグ付けと分岐を組み合わせて、目的を達成することです。これを Web サイトなどにデプロイするためにも使用している場合は、分岐、タグ付け、および外部を組み合わせることができます。

たとえば、/tags/1.0 への外部エントリを持つ /path/to/production をチェックアウトできます。修正を適用する場合は、#2 の手順を実行して /tags/1.1 を作成し、外部エントリを調整します。または、ブランチを指すだけで、タグを再作成する必要はありません。

私はそれが半分有用なスタートであることを願っています.

于 2011-01-05T08:17:15.433 に答える