颠覆StarTeam用户的概念

Question

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

1.如何更新标记以包含更新的仅一个文件的修订版？

在StarTeam中创建视图标签(与SVN中的标记类似)之后，我能够在视图标签中包含一个更新的文件修订版--例如，更新视图只包含该文件(以及其他自创建视图标签后也不会更改的视图)

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

当在发布版本的同时继续开发时，一些特性将被不包含，尽管它们是签入的。在StarTeam中，我常常基于先前的视图创建视图标签(同样，类似于标记)(然后执行我在问题1中描述的)。我知道在SVN中，我可以基于另一个标记创建一个标记，但是它是只读的，我需要一个分支。但我真的不需要分支，真的。

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

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

Answer 1

让我在序言中说我不熟悉StarTeam，所以我可能不完全理解您试图复制的工作流。

Subversion本身并不区分标记和分支。按照惯例，标记只是一个分支，您从不修改它。甚至一个分支也只是一个"svn副本“操作，没有一个单独的”分支“特性。一个分支只是一个廉价的副本，而标记是一个只按约定读取的分支。svn中的副本非常便宜，所以您不必担心创建分支--标签并不比分支便宜多少。您可能需要阅读创建分支机构上的文档。它进一步解释了事情..。还有一个关于“廉价拷贝”的盒装版。

根据您在StarTeam中使用“查看标签”的情况，svn外部可能对您的目的很有用。我一般不喜欢他们，但这取决于情况。

直接回答你的问题..。

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版的主干上发生了更改，那么您应该这样做(从干净/分支/1.0工作副本)：

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

在理想情况下，修订的更改是独立的，并且需要修订本中的所有文件。有时，也有额外的东西，你不想合并。在这种情况下，合并之后，恢复对不希望合并的文件的更改，测试所有内容，然后提交。合并->还原某些文件的->提交工作流有一个缺点，那就是subversion将记录合并发生的情况，但您已经排除了其中的部分。如果所讨论的分支不太可能进一步更改(或重新集成到另一个分支)，这可能无关紧要，但我更喜欢为您想要的1文件中的更改创建一个补丁文件，并在这种情况下手动将它们应用到分支中。在cmd行语法上，我不是百分之百肯定，但我认为这是非常相似的：

svn diff -c 15 /path/to/file (在回购或其他工作副本中)> my-patch.diff

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

一旦完成该操作，您将再次在分支上创建一个新标记，该标记将包含新的合并更改。

svn复制/路径/到/分支/1.0/path/to/tag/1.1

然后，您将有一个与旧标记相同的新标记，但对1文件的更改除外。在#3中，我还将提到您可以重新创建标记(尽管它取决于您使用标记的是什么取决于它是否是一个好主意)。r，但只有当标记不表示已提供的代码时，我才会这样做。

2)事实上，由于按照约定，标签是只读的，因此来自另一个标记的标记实际上并没有什么不同。但是，如果您为第一个分支使用一个分支，然后按照建议的那样创建一个标记，那么您以后可以根据同一个分支创建第二个标记(在提交了额外的更改之后)，并且它将与您的第一个标记不同的是，从那时起仅应用于该分支的更改。

3)再一次，你通常会使用一个分支。如果分支/标记仅在内部使用(I 不建议删除已发布代码的发布标记，尽管它并不是真正“丢失”，但它通常不应该是必需的)，您可以只删除并重新创建标记。标签的使用者(工作拷贝)可以在标签被删除和重新创建后进行正常的"svn更新“，并且将继续正常工作，就好像什么都没有发生一样。这不能用于#1，但可能用于#2，而实际上您只是想更新一个标记。诀窍是将标记和分支结合起来，以实现您想要的结果。如果您也使用它部署到一个网站或其他什么，您可以组合分支，标记，和外部。

例如，可以签出具有外部条目/tag/1.0的/path/ to /production，当您想应用修复时，可以执行#2中的步骤，创建/tag/1.1并调整外部条目。或者，让它指向分支，而不需要重新创建标记。

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