svn - StarTeam用户的Subversion概念

Question

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

1.如何更新标签以包括仅1个文件的较新修订版？

在StarTeam中创建视图标签(类似于SVN中的标签)后-我能够在该视图标签中包含文件的较新版本-例如更新视图以仅包括该文件(不包括自创建该视图标签以来也已更改的其他文件)

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

当发布某个版本时继续进行开发时，尽管已签入某些功能，但这些功能并未包括在内。在StarTeam中，我曾经根据先前的视图创建视图标签(再次类似于标签)，然后执行我描述的操作问题1)。我了解在SVN中，我可以基于另一个标签创建一个标签，但是它是只读的，并且需要一个分支。但是我真的不需要分支。

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

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

Answer 1

首先说一下我对StarTeam不熟悉，所以我可能不完全了解您要复制的工作流程。

Subversion本身不能区分标签和分支。按照惯例，标签只是您永远不会修改的分支。即使分支只是“svn复制”操作，也没有单独的“分支”功能。分支只是便宜的副本，而标记是仅按照惯例是只读的分支。 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

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

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

此标签是一个冻结的时间点，与您要交付给客户的时间完全匹配。

您发现1.0版客户所需的bug /功能/更新已在主干上完成。就您而言，您已声明了对特定文件的更改。

假设更改发生在修订版15的主干中。然后，您需要做(从干净的/branches/1.0工作副本开始):

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

在理想情况下，修订版的更改是独立的，并且需要修订版中的所有文件。有时还有一些您不想合并的东西。在这种情况下，合并后，将更改还原到您不想合并的文件，测试所有内容，然后提交。合并有一个缺点->还原一些文件->提交工作流，这是Subversion会记录合并的发生，但是您已经排除了合并的一部分。如果所讨论的分支不太可能进一步更改(或重新集成到另一个分支)，则可能无关紧要，但是我更愿意为所需的1个文件中的更改创建补丁文件，并在情况下手动将其应用于分支像那样。我不确定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并调整外部入口。或者，只需将其指向分支，而无需重新创建标签。

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