如何处理 SVN 中标记文档的更改答案

【问题标题】：How to handle changes to tagged documents in SVN如何处理 SVN 中标记文档的更改
【发布时间】：2013-10-25 11:41:47
【问题描述】：

我在主干上的文档很少，它们已针对特定版本进行了更新，并标有版本号（主干上的文档将继续进行）并在整个公司的发布电子邮件中发布。问题 - 我们正在识别标记文档所需的更改（例如 - 某处的拼写错误或在 RN 中提到的模块修订号错误）。在这种情况下，您可能会说更新主干上的文档并创建一个新标签

我想知道如何在不重新发送链接仍然有效且不鼓励再次删除和重新创建标签的情况下处理此问题（这将在未来造成不良做法）？

如果有不清楚的地方请见谅，我会很乐意详细说明。

【问题讨论】：

【解决方案1】：

我建议你走很长的路：保持标记版本不变，修复主干中的错误（或者可能为这些修复创建一个新分支），然后创建一个新标签，发送更新的电子邮件。

这会更痛苦，但从长远来看会产生更少的问题。文档引用应该是自动计算的，因此传播所有更改的手动工作更少，更不容易出错。

如果发送新的更新电子邮件是个问题，请确保在发布前双重（和三重）检查您正在发布的内容，但要知道错误往往在发布后才被发现。

另一种选择是将上述分支发布给您的 beta 测试人员，并仅在您相当确定剩下的错误最少之后才创建标签。

【讨论】：

嗨 Attila，感谢您的回复并感谢您的时间。我应该更清楚。这里有两个方面 1. 代码 2. 发布文档都位于不同的位置，并且每个都有自己的主干，并且都在每个 sprint 结束时标记。 1.代码在分支上工作，如果标记后的任何更改被视为不同的版本 2.在发布电子邮件发送后将其作为发布文档中的 req 更正进行管理（如拼写错误、不正确的链接和模块的修订）确实存在的问题不需要对代码进行任何更改，但需要更新文档。希望这是有道理的？
@user2919782 - 我写的内容适用于两个存储库。

【解决方案2】：

这听起来，坦率地说，就像您必须创建一个新版本一样；

如果还没有到位，我建议自动化发布版本的创建 - 如果只需要例如30 分钟发布（编译、测试、标记、更新发布日志、循环邮件）。

最重要的是，我会提高贵公司对您需要分支机构的认识。

我既希望又担心我的理解是正确的 - 如果我错了，请纠正我。

当您只允许在主干上工作时“修复”旧版本，我想到的唯一解决方案是将主干用作分支：假设您在修订版 56 的 mydoc.txt 中发现了一个错误。与此同时，人们正在愉快地反复研究它。经过多次更改，最后一次提交导致修订版 89；

这里发生的事情是，从 1-3 开始，您实际上在一个分支上工作。再次需要 4 和 5 来修复这种残忍。

SVN 会给你一些想法来执行 1-5，恕我直言，这是有充分理由的：这个操作应该在一个单独的分支上完成。至少在这种情况下，我会选择适当的分支，更不用说客户订购旧版本的更改了。

【讨论】：

嗨 Leo，感谢您的回复并感谢您的时间。我应该更清楚可能是。这里有两个方面 1. 代码 2. 发布文档都位于不同的位置，并且每个都有自己的主干，并且都在每个 sprint 结束时标记。 1.代码在分支上工作，如果标记后的任何更改被视为不同的版本 2.在发布电子邮件发送后将其作为发布文档中的 req 更正进行管理（如拼写错误、不正确的链接和模块的修订）确实存在的问题不需要对代码进行任何更改，但需要更新文档。希望这是有道理的？
我什至会更进一步，将发布文档视为发布的一部分：毕竟，严格来说，它们只是代码的人类可读表示。如果代码正确，那就更好了：您只需为相同的源代码标签制作新版本...

【解决方案3】：

不要移动标签。曾经。一个标签的真正价值是一个唯一的标识符——如果你移动它，你指的是哪个 5.1.9 版本？

【讨论】：