我知道这是可能的，并且有各种方法可以做到这一点，但有没有充分的理由不从多个修订版本创建标记？
我建议做的是创建一个基于SVNKit和Jakarta POI的程序，该程序在各种svn版本中从excel电子表格/ CSV文件（java类文件和其他东西的混合）中读取构建工件列表，从中创建一个TAG，这个TAG成为下一个提议版本。
我喜欢这种方法，因为：
我们有一些文档（如果你愿意的话，基线）详细说明每个版本的内容。
它为我们的发布经理提供了一些工作（不需要简单地检查头部或者必须了解分支和合并等复杂的事情）
开发人员可以在他们想要的时候随心所欲地办理登机手续，而不受“释放窗口”等任何概念的限制。即限制开发人员在发布之前办理登机手续。
我不相信这种方法，因为：
感觉我违反了基本的svn原则（虽然我不确定是什么）。
正是因为怀疑我才把这个想法放在那里让人们开始说话。你们觉得怎么样？
答案 0 :(得分：1)
这样做并没有违反任何svn原则。 Tag不是内置的subversion构造，只是人们用来帮助构建过程的约定。通常人们会希望他们的标签基于单个修订，但同样只是惯例。您是否真的有这样的情况：要发送的优质代码包含某些文件的历史版本，但是其他文件的当前版本？
如果这种方法适合你，那就去吧。但是，为了避免混淆任何习惯于'标签'的正常定义的人，也许你可以调用该目录吗？也许“建立”？
答案 1 :(得分：1)
开发人员可以在他们想要的时候随心所欲地登记，而不受任何“发布窗口”等概念的限制。即限制开发人员在发布之前就签入。
传统的SVN方法是始终在分支中工作，而不是在主干中工作。这样你就可以随时提交，你就不会在“释放窗口”中合并到一个主干中（当主干被“冻结”时）