Mercurial 子存​​储库

发布于 2024-10-21 09:23:02 字数 802 浏览 2 评论 0原文

教程看了很多遍,感觉还是缺少了一些东西。 我将尝试给出一个具体的场景。请帮我找到我在哪里 错误的。

假设我有一个每个人都认为是“中心”的存储库。这 意味着每个新开发人员都会从它克隆并从它拉/推到它。 Central包含三个文件夹 -

  • Infra(即将成为共享代码)
  • .hg
    • infra.txt
  • dev1
    • dev1.txt
    • .hgsub(其中有一行 --> infra = (infra 的路径) )
    • 基础设施(子仓库)
      • .hg
      • infra.txt
  • dev2
    • dev2.txt
    • .hgsub(与 dev 1 中相同 - infra =(基础设施路径))
    • 基础设施(子仓库)
      • .hg
      • infra.txt

现在,假设一位开发人员克隆了 dev1,另一位开发人员克隆了 dev2。 我看到的是,当 dev1 的开发人员更改基础设施并推送 对中央存储库的更改,dev2 开发人员了解的唯一方法 关于基础设施中的更改是手动搜索传入的更改集 infra 作为子存储库。一般来说,这意味着如果我的项目有很多 子存储库(本身可能包含更多子存储库), 除了查看我的信息之外,我没有办法知道这些变化 手动子存储库。

我认为这不是工作方式... 有人可以帮忙吗?

预先感谢,

埃亚尔

I read the tutorial many times and I feel that I am still missing something.
I'll just try to give a concrete scenario. Please help me find where I'm
wrong.

Suppose I have a repository which everyone considers as "central". This
means that every new developer clones from it and pull/push from/to it.
Central contains three folders-

  • Infra (which is about to be a shared code)
  • .hg
    • infra.txt
  • dev1
    • dev1.txt
    • .hgsub (in which there's a line --> infra = (path of infra) )
    • infra (subrepo)
      • .hg
      • infra.txt
  • dev2
    • dev2.txt
    • .hgsub (the same as in dev 1 - infra = (path to infra) )
    • infra (subrepo)
      • .hg
      • infra.txt

Now, suppose that one developer clones dev1, and another one clones dev2.
What I see is that when the developer of dev1 changes infra and pushes the
changes to the repository in central, the only way of dev2 developer to know
about the change in infra is to manually search for incoming change-sets in
infra as a sub-repository. Generally, It means that if my project has many
sub-repositories (that may themselves contain some more sub-repositories) ,
I have no way to know about the changes except for going over my
sub-repositories manually.

I think that's not the way to work...
Can anyone help?

Thanks in advance,

Eyal

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

谁与争疯 2024-10-28 09:23:02

我想我找到了更好的东西。
在检查存储库中传入的更改集时,可以使用 --subrepos 标志。

这将递归地搜索传入的变更集,并向我们显示可以提取变更集的子存储库。

这样,人们就可以控制更改哪些子存储库,以及是否想要获取这些子存储库中的最新文件。

I think I have found something better.
You can use --subrepos flag when checking for incoming change-sets in a repository.

This will search for incoming change-sets recursively, and show us the sub-repositories in which change-sets can be pulled.

This way, one can control on which sub-repositories are changed, and whether she wants to get up-to date files in those sub-repositories.

落花浅忆 2024-10-28 09:23:02

您将必须拉取每个存储库。您可能认为这很乏味,但是 Mercurial 不会做出将更改拉入您的存储库的决定 - 这是一件好事。

您可以做的是创建一个简单的批处理脚本,对每个存储库运行“hg pull”命令。这至少使该过程自动化,因此当您确实想从所有存储库中提取数据时,感觉不那么乏味。

我们将所有子存储库移至一个存储库中,这使得管理需要更改所有库的更改/新功能变得更加简单。

我喜欢子存储库,但我认为它们最适合拉入其他人维护的整个存储库,并且保持相当稳定。当发生大量更改时,您需要大量的纪律和一定量的脚本来将手动工作量降至最低。

You are going to have to pull for each repository. You might think this tedious but there's no way mercurial is going to make the decision to pull changes into your repository for you - this is a good thing.

What you can do is create a simple batch script that runs a 'hg pull' command against each repository. That at least automates the process so it feels less tedious when you really want to pull from all repos.

We moved all our subrepos into one repository which makes it much simpler to manager a change/new feature that requires alterations to all our libraries.

I like subrepos but I think they are best suited for pulling in entire repositories that others look after that remain pretty stable. When there's a lot of changes, you need a lot of discipline and a certain amount of scripting to keep manual work down to a minimum.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文