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

Question

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

1. 它会使原始电子邮件无效。
2. 基本规则不会在公司发布后对标记进行更新或删除。
3. 为了使其更复杂，标记的文档会使用标记链接相互引用。因此，文档更新将触发其他文档的更新。

我想知道如何在不重新发送链接仍然有效的发布电子邮件的情况下处理这个问题，并且不鼓励删除并重新创建标记（这将在未来产生不良做法）？

如果事情不明确，请原谅我，我将非常乐意详细说明。

Answer 1

我建议你走很长的路径：保留标记版本的原样，修复trunk中的错误（或者为这些修复创建一个新分支），然后创建一个新标记，发送更新的电子邮件。

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

如果发送新的更新电子邮件是一个问题，请确保在发布之前检查您发布的内容是否加倍（并且三倍），但要知道错误在发布之后才会被检测到。

另一个选择是将上述分支发布给您的beta测试人员，并且只有在您确定剩下的错误很少之后才能创建标记。

Answer 2

坦率地说，这听起来像你必须创建一个新版本;

如果已经不存在，我建议自动创建发布版本 - 如果只需要例如，你就必须付出更少的努力30分钟发布（编译，测试，标记，更新发布日志，传播邮件）。

最重要的是，我会提高你公司的意识，你需要分支机构。

可能的短期解决方案

我希望并且害怕在我找到你的同时 - 如果我错了，请纠正我。

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

1. 将mydoc.txt的工作副本“更新”为r56
2. 执行必要的更改
3. 提交更改
4. 再次将mydoc.txt更新为r89。
5. 将mydoc.txt，r89提交到新版本。

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

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

Answer 3

不要移动标签。永远。标签的实际价值是一个唯一的标识符 - 如果你移动它，那么你引用的是5.1.9版本吗？