1

我有一个应用程序“myapp”，它使用与其他应用程序“common”和“common-www”通用的两个模块。

这些在主存储库中排列为薄壳

myapp-master
    myapp
    common
    common-www

每个子存储库都设置为具有“生产”和“主干”存储库的稳定/默认配置。

稳定（“生产”）上的瘦壳主控的 .hgsub 文件是：

myapp = https://myhostingprovider/repos/myapp/grp/production
common = https://myhostingprovider/repos/common/grp/production
common-www = https://myhostingprovider/repos/common-www/grp/production

主存储库本身位于：

https://myhostingprovider/repos/myapp/master/production

这很棒——我有一个主存储库，在应用程序和子模块中具有一致的版本控制。

问题在于能够维护主存储库的稳定/默认视图，因为 .hgsub 文件需要指向不同的存储库：

myapp = https://myhostingprovider/repos/myapp/grp/trunk
common = https://myhostingprovider/repos/common/grp/trunk
common-www = https://myhostingprovider/repos/common-www/grp/trunk

由于我必须在 .hgsub 文件中放置绝对路径，因此我最终得到了两个完全独立的瘦壳主存储库——一个用于开发，一个用于生产——并且无法在发布周期内将更改从开发推送到生产。

这种用于远程托管的主存储库方法是共享库的典型方法吗？您能否推荐另一种工作方式（关于 hgsub 路径是绝对路径的远程托管）？

任何想法非常感谢？

4

2 回答 2

1

我正在考虑的另一个选择是忽略关于瘦壳存储库的建议，并为每个从主项目稳定存储库直接引用的依赖模块提供默认URL 。

myapp（“稳定”存储库）

myapp (stable)
    contrib
        common (default)
        common-www (default)
        module x (default)
        module y (default)
        ...
    src
        myapp-specific source (stable version)

myapp（“默认”存储库）

myapp (default)
    contrib
        common (default)
        common-www (default)
        module x (default)
        module y (default)
        ...
    src
        myapp-specific source (default version)

所以 - 这些将是直接相关的存储库，我们可以在开发和生产之间推/拉。

显然存在一个问题，即“稳定”应用程序具有指向“默认”存储库的子存储库。但是，由于主存储库不会自动将子存储库更新到最新版本，因此可以手动处理。在对“common”的稳定版本进行更新之后，子存储库将手动更新为正确的修订版。

于 2012-08-20T14:15:46.297 回答
1

1）您的设置完全可以按原样使用。当您想要合并开发和生产之间的代码更改时，您可以单独合并受影响的子存储库，因此从主干到 myapp 的生产。而且很常见。和常见的 www。这种方法技术含量低，并且合并是在普通回购之间进行的，所以直截了当 Mercurial。

这两个主存储库仍然在开发/生产分支中的应用程序和模块之间提供一致的版本控制，但不直接用于合并。

我自己使用这种方法。你做了三个合并而不是一个超级合并，但好处是每个合并都易于执行和理解。

2) .hgsub 引用不必是绝对的，因为您使用的是 repo 托管。事实上，对 shell 主存储库的建议是所有 hgsub 引用都是微不足道的，比如 foo=foo。

https://www.mercurial-scm.org/wiki/Subrepository#Use_.27trivial.27_subrepo_paths_where_possible

相对引用始终相对于主存储库，因此琐碎的引用要求远程服务器上的布局与本地沙坑上的布局相匹配。

例如，您可以在服务器上：

myapp-production-master
    myapp
    common
    common-www
myapp-trunk-master
    myapp
    common
    common-www

3) 作为替代方案，我使用稍微不同的布局，这会导致非平凡的 .hgsub 引用，但可以轻松地在主项目之间混合和匹配子存储库。

在服务器上，我按分支对事物进行分组。创建一个新分支实际上只是复制文件夹。我在源代码库旁边有（多个）主项目。例如，在服务器上，生产分支文件夹可能如下所示：

production
    myapp
    common
    common-www
    specific-mac
    specific-win
    myapp-mac-master
    myapp-win-master

myapp-mac-master 的 .hgsub 看起来像

myapp = ../myapp
common = ../common
common-www = ../common-www
specific-mac = ../specific-mac

当我克隆出 production/myapp-mac-master 时，我进入了本地磁盘：

myapp-mac-master
    myapp
    common
    common-www
    specific-mac
于 2012-08-18T02:40:35.937 回答