3

我想知道如何在 SVN 中完成以下常见的 StarTeam 任务

1. 如何更新标签以包含仅 1 个文件的更新版本？

在 StarTeam 中创建视图标签（类似于 SVN 中的标签）后 - 我能够将文件的较新版本包含到该视图标签中 - 例如更新视图以仅包含该文件（而不是自创建该视图标签

2. 如何基于另一个标签创建一个标签？

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

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

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

4

1 回答 1

7

让我先说我不熟悉 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 文件中的更改创建一个补丁文件，并手动将它们应用于分支以用于案例像那样。我不是 100% 确定 cmd 行语法，但我认为它会非常相似：

svn diff -c 15 /path/to/file（在 repo 或其他工作副本中）> my-patch.diff

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

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

svn 复制 /path/to/branches/1.0 /path/to/tags/1.1

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

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

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

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

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

于 2011-01-05T08:17:15.433 回答