我将所有源代码移动到SVN回购中几周，并且真正开始看到魔力。我现在有一个非常简单的问题，它将决定我对SVNing的处理方法。
我在一个客户的网站上工作了3个星期，在ProjA的主干上工作。就在我离开之前，我在“ProjA / tags / release-09.11.17”（datestamp版本号）下创建了一个主干分支，这样我就可以准确地构建紧急错误。
刚才客户打电话给我确认了一个简单的数学错误并修复了它。我想知道如何更新我们的仓库，我看到有几个选择：
1）提交对ProjA主干的更改，并删除“ProjA / tags / release-09.11.17”
2）提交对ProjA和“ProjA / tags / release-09.11.17”的更改
3）提交对ProjA的更改，为TODAY“ProjA / tags / release-09.11.19”创建一个新标签，并删除旧标签“ProjA / tags / release-09.11.17”。
我认为其中任何一个都有利弊。在接下来的几周内，ProjA将看到很多开发项目，客户在重新回到现场之前不会看到它。
想法和原因？谢谢！
答案 0 :(得分：2)
删除标签是一个坏主意（至少从我所知的标记/分支）。该标签可供日后参考 - 将其视为时间书签。如果你想找到你在该版本中添加的代码，那么代码将永远在你身边。
如果您想基于该标记启动一个新的开发分支，您始终可以使用svn cp执行此操作。您可以在那里提交您的更改，进行一些测试，然后将其标记为发布作为后续版本，就是这样 - 您无法更改已发布的内容。之后，您可能希望将修复程序移回主干。根据您在合并信息（通过svnmerge.py或核心svn样式元数据）方面设置的内容，以及根据您在分支中实际需要完成的工作量，这可能是微不足道的，也可能是您的痛苦颈部。
我的建议是尽量避免实际提交标签（除了最初的创建）。
答案 1 :(得分：1)
如果您不希望中继中的任何更改被释放，我会更改ProjA / tags / release-09.11.17然后将这些更改合并到主干
答案 2 :(得分：1)
我相信SVN的福音是/ tags用于完成你所做的事情 - 标记代码处于已知状态的特定时刻。我想你想要做的是在/ branches / client中创建一个分支，然后你可以通过trunk的合并保持最新。当你完成时，你也可以将带有日期戳的版本复制到/ tags，作为对内存的辅助。
答案 3 :(得分：1)
我建议您将更改提交到发布分支，然后从发布分支重新部署代码。然后，您可以将分支更改合并回主干以供将来版本使用。
使用该方法，您将保留发布代码的完整性，同时确保修复程序进入未来版本。
答案 4 :(得分：1)
我认为你正在向后看，如果有持续的，重叠的，打包的更改，首选的方法是在分支中进行这些编辑。错误修复，短期补丁将进入后备箱。
在处理长期项目时，可以将错误修复程序合并到分支中，以便将分支机构的最终合并放回到主干中。
因此，您的紧急修复程序将进入主干，并合并到分支/发布09.11.17。
答案 5 :(得分：1)
如果您不希望ProjA/tags/release-09.11.17和ProjA/trunk@HEAD之间的所有更改都处于发布ProjA/tags/release-09.11.XX（XX是该修正发布的日期），那么您可以这样做：
ProjA/tags/release-09.11.17复制到ProjA/branches/fix_math_bug ProjA/branches/fix_math_bug复制到ProjA/tags/release-09.11.XX ProjA/branches/fix_math_bug