我公司的构建过程使用CVS进行如下操作：
在Subversion中，我无法看到相同的方法，无需手动将修改后的文件从分支文件夹复制到标记文件夹，如下所述： http://svn.haxx.se/users/archive-2005-05/0345.shtml
但是，如果修改了多个文件，这将非常耗时且容易出错。
是否有更好的方法在Subversion中强制标记，或者我们是否必须完全改变我们的方法？
由于
答案 0 :(得分：1)
您所要做的就是将该分支重新复制到标记。 Subversion 不仅会重置所有内容，而且与CVS不同，它会存储您重命名的历史记录。
但是，我会推荐一些东西......
简化分支和标记名称。在CVS中，分支和标签共享相同的命名空间。在Subversion中，他们没有。您不需要R和B前缀。
摆脱下划线。你可以在Subversion中使用点。例如，您的版本现在可以是Release-1.0而不是Release_1_0。哎呀，我甚至不打扰Release部分。只需拨打代码1.0和分支1.0。
现在，主要的事情是：不要重复使用标签！不不不。这就是CM社区中一个反模式。 反模式是一种糟糕的CM实践。
自Subversion以来，在Subversion中移动标签并不像在CVS中那样糟糕，与CVS不同，它保留了标签和更改的历史记录。但是，标记应该是特定时间点的快照。也就是说，当我谈论1.0版时，我不必说“你的意思是我们上周做的1.0版，还是前一周做的。
我理解你在做什么，但有更好的方法。首先，Subversion中的标记非常非常快。你做了svn cp...而且你已经完成了。在CVS中，可能需要40到50分钟（这可能是您启动标记重用业务的原因）。
我建议您只需在标记的末尾添加一些内容即可。例如，你可以把类似的东西：1.0-2012-Feb-29，所以你知道你正在谈论发布于2012年2月29日的1.0版。你仍然知道它的1.0版，因为它仍然以1.0开头，但是你知道哪个你正在谈论的1.0版。
最大的问题是为什么要标记这些版本？在Subversion中，很多人只是使用Subversion修订版ID作为快速标记。您可以谈论您的软件的修订版20321。然后，您只在实际发布实际版本时进行标记。
我们使用Jenkins作为构建系统，因此每个提交都有一个单独的构建。 QA将我们的构建直接从Jenkins中进行测试。我们的开发人员简单地说，采用版本1.0的Build＃29（版本1.0只是对分支的引用）。稍后QA会说他们已经认证了一个特定版本的发布，我们将回到Jenkins并将该特定版本标记为Release-1.0或其他。
在我的最后一个地方，我们确实将每个版本标记为Release-1.0-B-xxx，其中“xxx”是Jenkins版本号。我们将这些构建标记放在我们的Subversion存储库中的/project/tags/BUILDS/下，因此当您想要svn ls /project/tags查看版本是什么时，它们就不会显示出来。然后，当我们实际发布时，我们将构建标记复制到实际的发布标记：
$ svn cp http://build/src/foo/tags/BUILDS/1.0-B-233 http://build/src/foo/tags/1.0
我希望这会有所帮助。 Subversion处理了你对CVS的很多问题。标记是即时的，存储库中的每个更改都在整个存储库中都有一个修订版号，您只需将其用作构建标记即可。此外，即使您移动标签，Subversion也会跟踪更改，制作时以及制作者。您甚至可以询问新旧标签之间的区别。
但是，标签应该是不可变的。我甚至有一个预提交钩子，允许你创建标签，但一旦设置就不能修改它们。
答案 1 :(得分：0)
改变你的方法：你发布了一组二进制文件，然后发布了一组假装是同一个东西的不同二进制文件。这不是一个好习惯。
所以，鉴于你要改变，在SVN中创建一个发布分支很简单 - 你复制到另一个目录就完成了。复制很便宜，所以继续做很多次。您将遇到的唯一问题是您将获得许多分支目录，但您可以随时删除旧目录。
一旦你对发布分支进行了修复（嗯，但是确定），那么你必须将更改合并到你的主干上 - 这很简单，应该就像将整个目录从tag branch合并到trunk一样简单。只有更改的文件才会成为合并的一部分，因为SVN使用补丁和应用机制来执行合并，只有所做的更改才会应用到主干。
或者，您可以修复trunk并将它们合并到您的发布分支上，但是虽然您可以仅针对包含修复的单个修订执行此操作，但这可能会导致您的中继代码发生重大变化，从而导致合并困难。
您的第三个选择就是将您的发布分支分支到新的发布分支并在那里进行修复。请注意，SVN具有原子修订号，因此您可以直接将修补程序应用于发布分支，并记下2组修订号 - R_Release_1_0 v 1是原始版本，R_Release_1_0 v2是固定版本，但就像我在开头所说的那样这不是最好的做法（TBH这就是我们所做的，它对我们有用，所以我不会批评它，你只需要了解你正在做什么以及为什么这样做。）