StarTeam 用户的 Subversion 概念

Question

我想知道如何在 SVN

1 中执行以下常见 StarTeam 任务。如何更新标签以包含 1 个文件的较新版本？

在 StarTeam 中创建查看标签后（类似于 SVN 中的标签） - 我能够包含较新版本将文件添加到该视图标签中 - 例如，更新视图以仅包含该文件（而不包含自创建该视图标签以来也发生更改的其他文件视图标签

2. 如何基于以下内容创建标签另一个标签？

当开发在发布版本时继续进行时，某些功能虽然已签入，但不会包含在内。在 StarTeam 中，我曾经根据先前的视图创建视图标签（再次，像标签） （然后执行我在问题 1 中描述的操作）我知道在 SVN 中我可以基于另一个标签创建一个标签，但它是只读的，而且我需要一个分支，但我真的不需要一个分支。

3. 如何签入/添加到现有标签？

在 StarTeam 中，视图标签位于主干/分支上，因此我可以在创建视图后签入文件并修改标签。要包含它，在 SVN 中我必须签入分支

Answer 1

首先我要说的是，我不熟悉 StarTeam，因此我可能无法完全理解您尝试重现的工作流程。

Subversion 本身并不区分标签和分支。按照惯例，标签只是一个您永远不会修改的分支。即使分支只是一个“svn复制”操作，没有单独的“分支”功能。分支只是一个廉价的副本，而标签是按照惯例只读的分支。 svn 中的副本非常便宜，因此您不必担心创建分支太多 - 标签并不比分支便宜。您可能需要阅读 创建分支。它进一步解释了事情......并且有一个关于“廉价副本”的盒装部分。

根据您在 StarTeam 中使用的“查看标签”，可能会出现 svn externals 可能对您的目的有用。我一般不喜欢它们，但这取决于场景。

更直接地回答您的问题...

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

然后继续在主干上进行开发，同时还在 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 个文件中的更改创建一个补丁文件，并在某些情况下手动将它们应用到分支像那样。我对 cmd 行语法不是 100% 确定，但我认为它非常相似：

svn diff -c 15 /path/to/file (in repo or otherworking copy) > my-patch.diff

并使用另一个工具应用。我通常在 GUI 中创建/应用补丁，因此具体细节将留给您作为练习。

完成后，您再次在分支上创建一个新标签，其中将包含新的合并更改。

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

然后，您将拥有一个与旧标签相同的新标签，除了对 1 文件进行更改之外。在#3 中，我还将提到您可以重新创建标签（尽管这取决于您使用该标签的目的，这是否是一个好主意）。
r，但只有当标签不代表已发布的代码时我才会这样做。

2) 事实上，由于按照惯例，标签是​​只读的，因此标签与另一个标签之间不会有真正的不同。但是，如果您改为使用第一个分支，然后创建一个标签（按照建议），您可以稍后基于同一分支创建第二个标签（在提交其他更改后），它将与您的第一个标签不同仅标记自那时以来已应用于该分支的更改。

3）同样，您通常会使用分支。如果分支/标签仅在内部使用（我不建议删除已发布代码的发布标签，尽管它并没有真正“丢失”，但通常不需要 - ） ，您只需删除 &重新创建标签。您的标签（工作副本）的使用者可以在标签被删除和更新后执行正常的“svn update”。重新创建并将继续正常工作，就好像什么也没发生一样。这不能用于#1，但可以用于#2（当您确实只想更新标签时）。诀窍是结合标记和分支来实现你想要的。如果您还使用它来部署到网站或其他东西，您可以组合分支、标记和外部。

例如，可以检查 /path/to/products，其中有一个指向 /tags/1.0 的外部条目，当您想要应用修复时，请执行 #2 中的步骤并创建 /tags/1.1 并调整外部条目。或者，只需将其指向分支，无需重新创建标签。

我希望这是一个半有用的开始。