我希望Subversion有一个更好的移动标签的方法。我知道移动标签的唯一方法是从标签中删除文件，然后再次复制它。修订树浏览器似乎无法很好地处理。这还需要使中继和标签下的目录结构保持同步。

用例：我们有成千上万个"地图"，我们想标记每个地图的哪个版本是"生产"版本。我们需要能够轻松获得所有地图的生产版本。

谁能提出解决我们用例的更好方法？
我也考虑过属性，但后来我们无法轻松获取所有文件的正式版。合并到标签似乎也不是一件容易的事。
(最初发布到http://jamesjava.blogspot.com/2007/12/subversion-moving-tags.html)

解决方案

回答

我认为不需要从生产标记中"删除"文件。我们应该将新文件复制到现有文件上并检入。这样我们将保留历史记录。

当然，我们需要签出生产标签才能执行此操作。

回答

我认为我们无法通过Subversion的运行方式来做到这一点。我相信最好的解决方案是查看git之类的工具，该工具似乎适合用例。我们正在生产的系统可以"拉"入被接受的"地图"。虽然我意识到这不是颠覆，但使用git可能比svn更接近使用模式。

关于git的基于pull的开发模型为何与方案更好地匹配的一篇很好的文章在这里。

还有关于如何开始这样迁移的教程。

回答

为什么不为当前的生产版本创建新标签？记住，Subversion不是CVS。因此，制作完整目录树的副本不会花费我们任何费用。

回答

这不是颠覆的好用。

Subversion标记用于为树的实例命名(如其历史记录中的特定快照一样)，并且应保持静态。

也许我们可以使用当前日期，也可以使用递增数字作为标记的一部分？我们可以在标签下有一个目录，其中包含任何特定日期的生产版本。以最新日期为当前生产版本。

可以在以下位置找到今天的版本

/svn/tags/production/2008/09/15/mapproject

回答

一种方法是转到"稳定主干"模型。

• 从树干上建立一个分支以用作工作区域。
• 停止直接向主干提交-让每个人都切换到开发分支。
• 由管理稳定版本的人员签出中继，确保他们具有提交权限。
• 当我们希望"释放"地图时，请使用"重新集成合并"将更改引入该文件/目录并提交更改。

这可能看起来有点颠倒，但相当可行。我们可以让生产机器直接从行李箱中拉出，也可以为每个发行版从行李箱中制作一个新标签。对于后者，我们将需要某种方式将新标签传达到生产机器。某种消息传递，共享配置或者命名约定可能有效。

但是请注意，我们必须进入主干的心态，在这种模式下，主干有些"神圣"。

回答

如果我了解需求，我认为最好的方法是将所有地图作为主干的外部，然后制作一个脚本，以递归方式将每个地图(外部)标记到工作副本中的当前修订版(或者服务器(如果我们希望这样做)。

回答

我认为我们正在尝试解决错误的问题。

听起来好像我们有一个包含尚未发布的地图版本的主干，并且在进行发行时，我们想从主干上所有可能的更新中选择要更新的地图。

假设是这种情况，请创建一个名为" Release"的分支。 (请考虑创建一个新的空目录，并复制所需的每个地图版本(使用单独的svn cp命令)，如果这样做会更快。

现在，我们已经在分支中获得了当前版本。用" Release XXX"标记它(在整个目录中svn cp)，其中XXX是最新版本的有意义的ID。

然后，由于批准了下一个版本的地图，请将其svn cp到发行分支。我假设我们不想使用合并，因为映射的是离散元素而不是源代码。

在下一个发行版时，我们可以再次标记。

现在我们知道什么是最新批准的地图以及每个发行版中的地图。如果我们真的不记得最新的发行版号，并且可以花点时间知道而不是仅查看标签目录，则可以创建一个标记svn cp最新版的标签，然后将其删除并在执行下一个版本时重新复制。