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

Question

我一直在使用StarTeam进行版本控制，但是正在转向Subversion。我一直在阅读Subversion book，StarTeam似乎有一个主要特性，Subversion不会 - 标签的概念。我知道Subversion有标签，但是它们在StarTeam中意味着不同。在StarTeam中，我可以将一组文件标记为“准备好构建”，然后只检查这些文件并将其包含在特定版本中。然后，我可以创建一个冻结标签，指出该版本中包含哪些文件（类似于Subversion标签，除了它在那些特定版本上，不是目录中的所有内容）。

有没有办法在Subversion中获得这样的功能？我知道你可以指定要修改哪个版本，但是在你有代码并且即将发布版本，发现错误或者某人决定特定更改的情况下会发生什么情况不应包括在内。我知道你可以根据存储库和本地工作副本创建标签，但是这涉及检查不应包含的文件的特定修订并创建标签。随着准备建立“标签”，你不会把标签放在你不想要的文件的头版上。在Subversion中没有出现任何自动的方式来指定某个版本的修订。在分支中应该开发新功能的情况并不是这样，但是如果修订版本位于主干中（或者在哪里制作标签），则更多，但不应包括在内。它可能不需要恢复 - 更改可能是适当的，但在未来的版本中，不是现在的版本。如果您没有针对您需要的确切文件版本的特定修订版，您似乎必须从存储库和您的工作副本手动混合和匹配。

在类似的情况下，如果Subversion中的文件不是发行版的一部分，并且不需要加标签，会出现什么情况。在StarTeam中，您不会将准备好的标签附加到它们，但在Subversion中，它似乎是目录中的所有内容。有没有办法从构建和标签中排除这些文件？这是什么svndumpfilter排除是为了？

简而言之，有没有办法只在标签中包含某些文件的特定修订版本，还是必须是版本库中的特定修订版本，或是存储库中的手动文件组合以及工作副本？

Answer 1

如果我正确理解您的问题，我相信可以在发布之前的某个时刻通过分支来处理它（例如，在此版本中包含的所有主要功能已完成），然后仔细管理什么合并到该“发布”分支。 “主干”对新东西免费。例如，如果确定了一个错误，那么可以（a）固定在主干上，然后决定是否也应该将它合并到发布分支中;或（b）固定在分支上。这是我们遵循的过程，它运作得很好（但它也需要纪律和一定数量的正式流程）。

Answer 2

您在特定修订版本上进行分支或标记。您可以修改分支，使其包含您想要在该分支中进行的特定更改或更新。一旦你分支，你可以改变你想要的任何数量的文件，并只为那个分支进行更新。所以是的，你可以单独将文件更新到较旧的版本，然后将它们提交到分支。

Answer 3

Subversion仅允许以原子方式标记源树的整个修订版。您正在寻找的功能需要您的源代码管理系统和售票系统之间进行一些通信，该系统不仅保留要更改的内容，还需要为每张票证更改文件。

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

您需要一个模块来维护与新版本相关联的票据，然后计算哪些文件成为增量发行包的一部分。

Answer 4

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

比方说，例如我们正在干线，并发布版本1.0。然后，我们创建一个名为maint-1.0的分支，没有人接触。我们继续在后备箱中开发，当我们完成某些特性或功能时，我们将这些更改后的文件移动到maint-1.0分支中。请注意，您可能必须有两份工作副本，并简单地复制已更改的文件。做一个实际的合并将想要合并所有的改变，而不仅仅是特定的文件。

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

Answer 5

我认为其他的答案是非常多的，但只是为了明确说明，这种情况在发布分支中处理得很好。

这个想法是在开发的早期阶段（或者从早期版本开始 - 假设您希望所有的东西都来自您分支的版本），并且使用正常的合并机制来促进版本的修改后备箱释放。如果稍后决定修订（或修订集）的质量较差，则可以恢复这些合并。你的合并跟踪（在乌龟中这个效果非常好）显示了你所包含的内容以及仍然需要去做的事情，你可以跳过修订版本，不按顺序合并它们，并且通常会尽可能多地搞乱你的构建。很明显，跳过和不按顺序合并可能会为您创造更多的工作，因为您需要手动解决冲突 - 但它是一种在您需要时可用的工具。

与单个文件一起工作的优势在于，根据需要提升/删除整个功能集 - 您不必手动搜索不同文件，从而消除来自各处的更改。但是这确实需要你有明确的提交和评论 - 不要让你的开发人员犯下“在星期五下午提交以确保一切安全”。