在subversion中创建一个“标签”,指示下一版本中应该包含哪些文件

可以在特定修订上进行分支或标记。您可以修改分支,使其包含您希望在该分支中进行的特定更改或更新。分支后,可以更改任意数量的文件,并仅为该分支更新这些文件。因此,您可以单独将文件更新为旧版本,然后将其提交到分支。

如果我正确理解了您的问题,我相信可以通过在发布之前的某个时间点(例如,在此时间点,您希望包含在该发布中的所有主要功能都已完成)进行分支,然后仔细管理合并到该“发布”分支上的内容来处理。“主干”是免费的新东西。例如,如果确定了一个bug,那么它可以(a)固定在主干上,然后决定是否将其合并到发布分支中;或(b)固定在树枝上。这是我们遵循的过程,它运行得很好(但它也需要纪律和一定数量的正式过程)。

例如,Trac使用提交日志中的#语法解析每个修订的提交日志,以与任意数量的票据关联。

我认为你最好的选择是使用分支。根据您在新版本上的工作方式,您可以创建不用于活动开发的干净分支,也可以保持主干干净并使用分支进行活动开发。然后,当您拥有已完成并准备好进行下一次构建的文件时,您将仅将这些文件更改合并到clean分支中。

比如说,我们正在主干中工作,发布了1.0版。然后我们创建了一个名为maint-1.0的分支,没有人接触它。我们继续在主干中开发,当我们完成某些特性或功能时,我们将这些更改的文件移动到maint-1.0分支中。请注意,您可能需要有两个工作副本,只需将更改的文件复制过来即可。进行实际合并时,需要合并所有更改,而不仅仅是特定文件。

最终的结果是,maint-1.0分支在下一个构建中只有您想要的更改。

我认为其他的答案基本上都在那里,但为了明确起见,发布分支可以很好地处理这种情况。

与处理单个文件相比,这具有优势,因为可以根据需要升级/删除整个功能集—您不必手动查找不同的文件,从这里或那里删除更改。但这确实需要你有理智的承诺和评论——不要让你的开发者承诺“周五下午承诺,这样一切都安全”。