Question

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

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

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

以来也发生更改的其他文件

2。如何根据其他代码创建代码？

在发布版本的同时继续开发时，虽然签入了一些功能，但是不会包含某些功能。在StarTeam中，我曾经基于之前的视图创建了一个视图标签（再次像标签一样）（然后执行我在问题1）中描述的内容。据我所知，在SVN我可以创建一个基于另一个的标签，但它是只读的，我需要一个分支。但我真的不需要分支机构。

第3。如何签入/添加到现有代码？

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

Answer 1

让我先说我不熟悉StarTeam，所以我可能不完全理解您尝试重现的工作流程。

Subversion本身不区分标签和分支。按照惯例，标签只是一个您永远不会修改的分支。即使分支只是一个“svn copy”操作，也没有单独的“分支”功能。分支只是一个廉价的副本，而标记只是按惯例只读的分支。 svn中的副本非常便宜，所以你不必担心创建分支 - 标签不比分支便宜。您可能需要阅读Creating a Branch上的文档。它进一步解释了......并且有一个关于“廉价副本”的盒装部分。

根据您对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

然后继续开发trunk，同时在1.0分支上进行一些额外的验证。准备好发货时，您可以创建一个标签：

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

此标记是一个冻结的时间点，与您向客户发送的内容完全匹配。

您发现已在trunk上完成的1.0版本客户所需的错误/功能/更新。在您的情况下，您已声明对特定文件的更改。

假设更改发生在修订版15的主干上。然后你会这样做（从一个干净的/branches/1.0工作副本）：

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

在理想情况下，修订的更改是自包含的，并且需要修订中的所有文件。有时候还有一些你不想合并的东西。在这种情况下，在合并之后，将更改还原到您不想合并的文件，测试所有内容，然后提交。合并有一个缺点 - ＆gt;还原一些文件 - ＆gt;提交工作流，这是subversion将记录合并发生，但你已经排除了部分。如果有问题的分支不太可能进一步改变（或重新集成到另一个分支），这可能无关紧要，但我更喜欢为您想要的1文件中的更改创建补丁文件，并手动将它们应用于分支像那样。我不是100％肯定cmd行语法，但我认为它非常相似：

svn diff -c 15 / path / to / file（在repo或其他工作副本中）＆gt;我的-patch.diff

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

完成后，再次从分支机构创建一个新标记，其中包含新的合并更改。

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

然后您有一个与旧标记相同的新标记，除了对1文件进行更改之外。在＃3中我还会提到你可以重新创建标签（虽然它取决于你使用标签的内容是否是一个好主意）。 r，但我只会在标签不代表发货代码的情况下执行此操作。

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

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

e.g。 / path / to / production可以签出，其中包含/tags/1.0的外部条目，当你想要应用修复时，你执行＃2中的步骤并创建一个/tags/1.1并调整外部条目。或者，只需将其指向分支，无需重新创建标记。

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

StarTeam用户的Subversion概念

1 个答案: