如何在Subversion中移动标记

我认为你永远不能用颠覆的运作方式来做到这一点。我认为最好的解决办法是看看 git 它似乎适合您的用例。你的生产系统可以“拉”在“地图”中被接受。虽然我认识到这不是颠覆,但是使用Git可能比使用SVN更接近于您的使用模式。

关于Git基于拉的开发模型为什么更适合您的场景的一个非常好的描述是 here .

还有一些关于如何开始类似迁移的教程 this .

我不认为需要从生产标签中“删除”文件。您应该将新文件复制到现有文件上并将其签入。这样你就可以保存历史了。

当然,您需要签出生产标签才能执行此操作。

这不是颠覆的好用法。

Subversion标记用于在树的历史记录中的特定快照中为其实例提供名称,并且应保持静态。

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

今天的版本可以在

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

我认为你是在试图解决错误的问题。

听起来你有一个主干,其中包含尚未发布的地图版本,当你进行发布时,你需要从主干上所有可能的更新中挑选出要更新的地图。

假设是这样,创建一个名为“release”的分支。(考虑创建一个新的空目录,并复制所需的每个映射版本(使用单独的SVN CP命令),如果这样做更快的话)。

现在分支中有了当前版本。用“release xxx”标记它(svn cp整个目录),其中xxx是最新版本的有意义的ID。

然后,随着地图被批准用于下一个版本,SVN CP会将它们发送到您的发布分支。我假设您不想使用合并,因为映射的是离散元素而不是源代码。

在下一个版本发布时,您可以再次标记。

现在你知道了,最新批准的地图是什么,每个版本中都有什么。如果你 真的? 记不住最新的版本号,你可以在不查看标签目录的情况下找到你需要知道的时间,你可以创建一个标签,SVN CP是最新的版本,然后在你做下一个版本的时候把它吹走并重新复制。

为什么不为当前的生产版本制作一个新标签?记住,颠覆不是简历。因此,复制完整目录树并不需要花费任何费用。

其中一种方法是移动到“稳定主干”模型。

• 从树干上做一个树枝作为你的工作区域。
• 停止直接向主干提交—让所有人切换到开发分支。
• 让管理稳定版本的人员签出主干,确保他们有提交权限。
• 当您希望“释放”一个映射时,请使用“重新集成合并”将更改拉入该文件/目录并提交更改。

这可能看起来有点颠倒,但相当可行。您可以让生产机器直接从后备箱拉出,或者为每个版本从后备箱制作一个新标签。对于后者,您需要某种方式将新标签与生产机器通信。可以使用某种消息传递、共享配置或命名约定。

但要知道,在这个模型中,你必须进入躯干“神圣”的思维模式。

如果我很好地理解了您的需求,我认为最好的方法是将所有映射作为主干的外部,然后制作一个脚本,在工作副本(或者服务器,如果您希望这样做的话)中将每个映射(外部)递归地标记为它的当前修订版。