Question

这个问题可以改为：

如何在特定文件的主干中包含对现有TAG的单个更改。

一个简单的问题，但我自己无法解决这个问题。

这个概念来自其他SCM工具，您只需在不同的修订版上移动标记，并将其“粘贴”到您需要的确切修订版本。这些其他工具对Tag的内容有本地的理解，SVN将所有内容概括为副本分支。

以下答案我在其他公告牌和相关帖子上看到过，因此已被考虑和拒绝：

这不是SVN的正确用法
- 实际上，SVN被设计为通用的，并且完成了许多使用模式
- 这是寻找答案的使命。我理解挑战，以及永远找不到答案的可能性。也许我会改用不同的工具。
为什么你这样使用SVN，最好这样做。
- 可以采用许多使用模式或SCM模型。就我而言特别：
  - Trunk表示正在进行的开发，并且会对其应用小补丁。
  - 生产是单一标签
  - 发展的转变非常短暂和积极，因此我们不能使用几个完整的生产版本。这意味着我无法一次创造生产中部署的每个小变更的新标签。
  - 因此，简而言之，“我的方案中不存在完整的打包生产版本”。
- 这是我需要的用例场景。

好吧，我不会放肆，我会阅读所提供的每一个解决方案，并根据需要重新考虑。

Answer 1

SVN中的标签和分支没有区别。所有不同之处在于团队遵循的有关如何使用标签和分支的政策。

因此，您可以将更改合并到标记中，并以与使用分支相同的方式提交新修订。通常您不想这样做是可以理解的，以便“标记”您用于发布的文件的确切版本。但如果真的需要，你可以从这个规则中做一次例外。

或者，您可以删除标记，然后使用正确的修订版重新创建它。

指向SVN图书的几个链接：“Tags”，“Branch Maintenance”

补充：所以，听起来这种重新标记不是一种罕见的非典型用例，而是团队中的常规练习。似乎标签不仅仅是为文件的特定快照命名，而是希望该名称跟随文件的后续更新，忘记其以前的位置。此外，您似乎发现分支机构对您的工作流程不方便。

好吧，我认为有一种简单而干净的方法可以实现SVN的功能。在我看来，最好“拥抱”分支并学习如何有效地使用它们。

Answer 2

我找到了一种简单的方法（即使用togoise SVN移动文件的标签）。

通过右键单击已签出的项目目录并选择“Tortoise SVN-＆gt; Repo-browser”来浏览您的仓库
导航到您要在标签/目录中更改的文件
右键单击该文件并选择“结帐”。
在高清上选择一个临时目录，然后点击确定。
使用更新后的版本覆盖此文件（使用本地文件exporer，而不是SVN repo浏览器）
右键单击该文件并选择“SVN checkin”。

工作完成。

使用CVS做同样的事情是微不足道的，只需转到所需的目录并输入： “cvs tag -F tagname filename” SVN并没有真正的标签，这使得使用起来很痛苦（在我看来）。

不确定为什么会被投票 - 这是我们解决问题中确切问题的方法。

Answer 3

Subversion中的标签和分支实际上只是目录。它们的概念不是嵌入在Subversion中，而是嵌入在你的大脑中。

正如其他人所说，标签是某个时间点存储库的快照，不应该更改。如果您打算更改标签，它确实应该是一个分支。

例如，

我想要一个显示已批准更改的标记：将其设为分支而不是标记。
我想展示最后一次构建使用的文件：Ditto。
我想显示已审核的代码：Ditto。

但这些不是分支！ 你抱怨声明。

很好，建议的存储库结构就是：一个建议。除trunk，tags和branches之外，您可以为这些可移动标记添加另一个目录：

$repo/trunk
$repo/branches
$repo/tags
$repo/moveable_tags

现在，您可以将您在 moveable_tags 下更改的标记，以及人们用于标记下的版本，快照等的标记。

我在我工作的某个位置之前修改了建议的存储库布局。我想从存储库中删除过时的分支和标签，但管理层和开发人员都反对。

我说删除这些并没有从存储库中删除它。如果需要，我可以轻松地将它们取回，但是通过删除它们，我从这两个目录中消除了许多不必要的混乱。但是，开发人员对此并不感到安全。当然，我可以找到它们，但它们可以吗？

相反，我在obsolete/tags，obsolete/branches和trunk目录级别添加了tags和branches个目录。我没有删除过时的标签和分支，而是移动了它们。 tags和branches没有混乱，经理和开发人员感觉更好，他们知道如果他们需要这些分支和标签就会找到它们。

让我们说你没有对标签做任何想象。您可以将标记用作快照，并且您希望更改和更新的任何内容都是分支。有时候可能需要更改标签。

而且，Subversion比大多数其他版本控制系统更擅长处理这个问题。那是因为标签包含其创建和更改的完整历史记录。在大多数其他版本控制系统中，如果甚至保留该标签的历史，那么该标签的历史就是二等公民。你可以看到标签。您可以看到该标记下的文件和版本，但您无法看到谁创建了该标记以及它是如何更改的。在Subversion下，标签包含其整个历史记录。

要对标记进行更改：

查看标签。
进行更改。
承诺改变。

或者，更好的是，对存储库URL使用svn cp，svn mv或svn delete，而不是针对工作目录。例如，我为2.0版创建了一个标签。突然间，我们意识到我们忘记了这个版本中出现的一个非常重要的变化。而不是结帐，你这样做：

$ svn cp -r 23933 -m"This change in this file should have been included in the tag" \
    $repo/trunk/foo/src/foo.java $repo/tags/2.0/foo/src/foo.java

当您查看此标记的历史记录时，您将看到。

 $svn log -v $repo/tags/2.0
 ------------------------------------------------------------------------
 r23945 | david | 2013-04-03 11:21:55 -0400 (Wed, 3 Apr 2013) | xxx lines
 Changed paths:
 M /tags/2.0/foo/src/foo.java (from /trunk/foo/src/foo.java:23933)

 This change in this file should have been included in the tag

 ------------------------------------------------------------------------
 r23932 | david | 2013-04-10 11:18:40 -0400 (Wed, 10 Apr 2013) | 1 line
 Changed paths:
 A /tags/2.0 (from /trunk:23921)

 Created release 2.0

我看到标签是在一周前从trunk上的修订版23921创建的。然后我看到文件foo.java在一周后从主干上的修订版23933更新。

Answer 4

你对@Alexey Kukanov的回答表明，你真正想要的是一个分支，而不是一个标签。标签是单个不变的时间点的历史记录。分支是代码的副本，随着时间的推移将进行进一步的更改。你在谈论后者。标准做法是为您支持的每个版本创建“bugfix”或“production”分支，并直接在分支[1]上提交更改或从主干中合并它们。

在这种情况下，标签将用于创建分支的“副本”，以指示“此特定时间此代码正好在生产中”。因此，如果需要，您可以轻松返回并与之进行比较。

[1] ......然后根据需要将它们合并到主干

Answer 5

我也需要这样做。你做什么从标签检查你的svn文件，而不是分支（所以像svn：// blahblah / tags / mytag，而不是svn：// blahblah / branches / mybranch），然后你在那里提交更改的文件，它将有更新的标签。

如何在SVN中移动标签

5 个答案: