Subversion：是否有充分的理由不从多个修订版创建标签？答案

【问题标题】：Subversion: Is there any good reason not to create a Tag from multiple revisions?Subversion：是否有充分的理由不从多个修订版创建标签？
【发布时间】：2011-02-08 23:10:11
【问题描述】：

我知道这是可能的，并且有多种方法可以做到这一点，但是有什么好的理由不从多个修订中创建标签吗？

我打算做的是创建一个基于 SVNKit 和 Jakarta POI 的程序，它从各种 svn 修订版的 excel 电子表格/CSV 文件（Java 类文件和其他东西的混合）中读取构建工件列表，从中创建一个 TAG，这个 TAG 就是下一个提议的版本。

我喜欢这种方法，因为：

我们有一些文档（如果您愿意，可以作为基线）详细说明每个版本的具体内容。
它让我们的发布经理有事可做（无需简单地检查头部或学习分支和合并等复杂的事情）
开发人员可以根据需要随时签入，而不受“发布窗口”等任何概念的限制。 IE。限制开发人员在发布前签入。

我不信任这种方法，因为：

感觉就像我违反了基本的 svn 原则（虽然我不确定是什么）。

我之所以提出这个想法是为了让人们可以这么说，是因为有点怀疑。大家觉得呢？

【问题讨论】：

你会怎么做？从工作副本或其他东西中创建标签？
yes :) 但我需要先根据电子表格的内容创建工作副本。我正在考虑使用 SVNKit 和 Jakarta POI 来自动化这个过程。
我对此感到困惑：“它让我们的发布经理有事可做” 发布经理是指一个人吗？他目前没有任何工作要做，您想为他创作一些吗？（无意冒犯，我只是想了解你的动机）
为了让我们的发布经理管理我们目前的发布（目前是负责人），他们倾向于管理开发人员。这是因为开发人员控制头部在哪里，因此在哪里发布。我想我所说的“给我们的发布经理做点什么”的意思是，除了管理开发人员的提交之外，我给发布经理做点什么。我们可以分支我们的版本，但在很多情况下，它似乎比在合并时固定修订更复杂。
即使不使用分支，如果你只是想捕捉头部的确切状态，你只需要写下修订号（或者你可以做一个标签，但这有点小更复杂一点）并使用该数字进行构建（以及所有相关的 SVN 操作）。您所做的并不是“错误的”（它是您的存储库，您可以随意使用它做任何适合您的事情），但对我来说它“闻起来很臭”。我可能遗漏了一些东西，但从我目前的理解来看，您似乎正在为可能非常简单的东西实现复杂的功能。

标签： svn configuration baseline

【解决方案1】：

这样做并没有违反任何 svn 原则。标签不是一个内置的颠覆结构，只是人们用来帮助构建过程的约定。通常人们会希望他们的标签基于一个单一的修订，但这只是惯例。您是否真的遇到过这样的情况：要发布的好代码由某些文件的历史版本和其他文件的当前版本组成？

如果这种方法适合你，那就去吧。但是，为了避免让习惯于“标签”的正常定义的人感到困惑，也许您可以将目录称为其他名称？也许是“构建”？

【讨论】：

嗨，xorsyst，是的，我们确实遇到了这样一种情况，即要发布的好代码包含历史版本。这是因为我们有一个需要几个月的验证/文档/测试周期。
我补充一下，作为开发人员，我们最终可以在当前版本甚至候选版本所在的位置之前进行多次修订：)

【解决方案2】：

开发人员可以根据需要随时签入，而不受任何诸如“发布窗口”之类的概念的限制。 IE。限制开发人员在发布前签入。

执行此操作的传统 SVN 方式是始终在分支中工作，而不是在主干中。这样你可以随时提交，只是不会在“发布窗口”中合并到主干中（当主干被“冻结”时）

【讨论】：

嗨，苏玛，谢谢你。由于其复杂性，我尽量避免合并。将版本化工件表中的下拉组合框拨到最新版本比手动合并两个源文件要容易得多（如果管理依赖项）。 :)