gpt4 book ai didi

version-control - Mercurial 与多个项目

转载 作者:行者123 更新时间:2023-12-03 08:49:46 26 4
gpt4 key购买 nike

我的 SVN 存储库中有几个具有不同发布周期的项目。版本是使用 SVN 中的经典标签结构创建的。当版本中存在要修复的错误时,会从标签创建分支,修复错误然后从那里 merge 到主干中。

现在,出于多种原因,我想通过中央推送站点从 SVN 切换到 mercurial。

问题:在 mercurial 中,组织多个项目之间共享少量代码的最佳方式是什么?我应该为每个项目创建多个推送站点吗?

请在答案中包含有关如何使用您首选的存储库设计版本重新创建我的发布标签、错误修复分支的描述。

编辑:我想安装尽可能少的扩展。

编辑2:

鉴于此 SVN 布局:

.
|-- project-a
| |-- branches
| | |-- 1.x
| | `-- feature-1
| |-- tags
| `-- trunk
`-- project-b
|-- branches
|-- tags
| |-- 1.0
| `-- 1.1
`-- trunk

(感谢@bendin!:))

使用多个 hg 推送存储库会更好吗
project_a-trunk
project_a-1.x
project_a-feature-1
project_b-trunk

为 Twig 。标签被折叠到适当的分支中。

或者您更愿意在本例中使用两个推送存储库
project_a
project_b

具有命名的分支,因此在一个 repo 中有多个头。

我看到的多头存储库的优势是我不必在多个存储库中寻找标签。我看到的缺点是 hg 书似乎不鼓励多头 repo 。你会/做什么?

最佳答案

一些颠覆存储库会将逻辑上不相关的东西(即具有不同版本号和发布周期的项目)分组到一个主干下:

.
|-- branches
| |-- project-a-1.x
| `-- project-a-feature-1
|-- tags
| |-- project-a-1.0
| |-- project-b-1.0
| `-- project-b-1.1
`-- trunk
|-- project-a
`-- project-b

这种布局在 Mercurial 中没有直接的模拟。每个有自己的发布周期和自己的版本号的项目都应该有自己的存储库。

一些颠覆存储库的结构是通过为每个项目提供自己的主干、标签和分支来做到这一点:
.
|-- project-a
| |-- branches
| | |-- 1.x
| | `-- feature-1
| |-- tags
| `-- trunk
`-- project-b
|-- branches
|-- tags
| |-- 1.0
| `-- 1.1
`-- trunk

您可以将每个项目视为物理 subversion 存储库中的一个逻辑存储库。每个项目都有自己的主干、标签和分支。这还有一个好处是您可以缩短标签和分支名称,因为您已经知道它们属于哪个项目。

这种布局也很容易用像 mercurial 这样的工具来表达。每个“项目”都成为一个反复无常的存储库。该存储库中的标签和分支是该项目的标签和分支。

关于version-control - Mercurial 与多个项目,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/929508/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com