标签: mercurial-subrepos

在我的存储库中,我为我正在使用的模块添加了几个子存储库.我总是将这些subrepos视为"仅拉动".我不打算对它们进行任何更改,但希望保留在新版本发布时轻松提取新更改的功能.

当我推送主存储库时,Mercurial尝试推送子存储库.有什么设置可以防止这种情况吗？

我在一个团队工作,我们在一个包含多个子库的mercurial存储库中有一个代码:

main/
main/subrepo1/
main/subrepo1/subrepo2/

Mercurial的默认行为是,当hg commit在"main"中执行a时,子存储库"subrepo1"和"subrepo2"中的任何未完成的更改也将被提交.类似地,当按下"main"时,也会推送"subrepo1"和"subrepo2"中的任何传出提交.

我们发现人们经常无意中提交并推送其子库中的更改(因为他们忘记了他们已经进行了更改,并且hg status默认情况下不会显示递归更改).我们还发现,在我们的团队中,这样的全球提交/推送几乎总是偶然的.

Mercurial 1.7最近用hg status -S和改善了情况hg outgoing -S,显示了子库存的变化; 但是,这仍然需要人们关注.

如果子目录中的更改/提交原本会被提交/推送,那么Mercurial是否有办法制作hg commit和hg push中止？

我们用C#开发.NET Enterprise软件.我们正在寻求改进我们的版本控制系统.我之前使用过mercurial并且一直在我们公司进行实验.但是,由于我们开发企业产品,因此我们非常关注可重用的组件或模块.我一直在尝试使用mercurial的子repos来管理组件和依赖,但是遇到了一些困难.以下是源代码管理/依赖关系管理的基本要求:

1. 可重复使用的组件
   1. 按源共享(用于调试)
   2. 依赖于第三方二进制文件和其他可重用组件
   3. 可以在消费产品的背景下开发并承诺源控制
2. 依赖
   1. 产品依赖于第三方二进制文件和其他可重用组件
   2. 依赖关系有自己的依赖关系
   3. 应通知开发人员依赖项中的版本冲突

这是我一直在使用的mercurial结构:

可重用的组件:

SHARED1_SLN-+-docs
            |
            +-libs----NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED1-+-proj1
            |                 +-proj2
            |
            +-tools---NANT

第二个可重用的组件,消耗第一个:

SHARED2_SLN-+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----SHARED2-+-proj3
            |                 +-proj4
            |
            +-tools---NANT            

消耗两种组分的产品:

PROD_SLN----+-docs
            |
            +-libs--+-SHARED1-+-proj1
            |       |         +-proj2
            |       |
            |       +-SHARED2-+-proj3
            |       |         +-proj4
            |       |
            |       +-NLOG
            |
            +-misc----KEY
            |
            +-src-----prod----+-proj5
            |                 +-proj6
            |
            +-tools---NANT

笔记

1. Repos在CAPS中
2. 假设所有儿童回购都是子项目
3. 第三方(二进制)库和内部(源)组件都是位于libs文件夹中的子库
4. 第三方库保存在单独的mercurial repos中,以便消费项目可以引用特定版本的库(即旧项目可以引用NLog v1.0,而较新的项目可以引用NLog v2.0).
5. 所有Visual Studio .csproj文件都在第4级(proj*文件夹),允许相关引用依赖项(即../../../libs/NLog/NLog.dll用于所有引用NLog的Visual Studio项目) …

我正在研究为我的组织从svn切换到mercurial的可行性,但有一个挂起我似乎无法找到解决方案.

有没有办法拉动和更新仓库和所有子目录而无需手动拉动和更新每个子仓库？

我想切换到mercurial,但如果那不可能,那么对我们来说这是不行的.

编辑:好上帝,我今天一定很累...关于SO的两个问题,我在询问后几分钟就能找到答案......

尽管涉及两个子部分,但我认为这是一个综合问题,因为它被分解成部分的方式并不重要.只要最终结果保留了所有有意义的历史记录以及检查,研究和构建/测试历史版本的能力,我就会以不同的方式实现我想要的目标.目标是退出hg和到目前为止使用的subrepo模型,然后转移到git中的统一树,但不会牺牲历史记录.

我开始的是一个Mercurial存储库,它包含一些顶级代码和许多有趣历史所在的子存储库.subrepos有一些分支/合并,但没有什么太疯狂.我想要实现的最终结果是单个git存储库,没有子模块,这样:

• 对于原始顶级hg repo中的每个提交,都有一个git提交,它会检查完全相同的树,因为您将检查相应的hg提交及其所有引用subrepo提交.

• 这些对应于连续顶级hg提交的git提交是彼此的后代,其提交对应于其间的所有相关子提交.

我对如何实现这一点的基本思想是迭代所有顶级hg提交,并且对于每个更改的顶级提交.hgsubstate,也迭代从旧修订到子模块的新修订的所有路径(可能涉及分枝).在每一步:

• 查看顶级和所有子目录的相应hg修订版.
• 从git索引中删除所有内容.
• 将从hg检出的所有内容都放到git索引中.
• 使用git-write-tree和git-commit-tree生成具有所需父级的提交,使用来自相应hg提交的authors,date和commit消息.
• 记录新git commit和hg提交之间的对应关系,以用于生成未来提交的父项.

这有用吗？有没有更好的方法来实现我想要的,也许首先用hg做subrepo崩溃？我不清楚的最重要的事情是如何执行所需的迭代,所以如何实现它的实用建议将是伟大的.

一个额外的约束:原始存储库涉及无法发布的内容(这是git-filter-branch基本转换完成后的额外步骤)所以涉及上传存储库以供第三方处理的解决方案是不可行的.

开始:

$ cat .gitmodules 
[submodule "utils/external/firepython"]
    path = utils/external/firepython
    url = git://github.com/darwin/firepython.git
[submodule "utils/external/textile"]
    path = utils/external/textile
    url = git://github.com/jsamsa/python-textile.git

虽然这仍然是一个Git回购,我需要运行git submodule init,之后会发生一些魔法.由于我现在将回购转换为Mercurial(使用hgext.git扩展名),我不知道该怎么做.是否有一个等效的过程(我需要在我的Mercurial仓库中使用这两个Git模块)？

我们的mercurial存储库在尝试更新到具有不再存在的subrepo/revision对的旧分支时会卡住.

abort: unknown revision '22e9bb6a6cd98be85b995f632b2f72d6298f9354'!

有没有办法告诉Mercurial更新到修订版或分支但不尝试更新子版本？

一个hg repo可以在我的本地文件系统中的另一个hg repo中存活吗？



我正在拉下bitbucket维基的'沙盒',我想知道这是否应放入repos/sandbox/wiki或repos/sandbox-wiki.

以前可以吗？

编辑:请参阅子存储库.

我在使用subrepos在Mercurial中设置项目时遇到问题.

目标:

我想像这样设置结构:

-- Build_Repo (this repo will be used to track dependencies)
  -- Subrepo_A (this is the main source)
    -- Modules (Part of Subrepo_A)
      -- Subrepo_B 

所以有三个存储库:Build,A和B.B嵌套在A中,A嵌套在根构建存储库中.构建仓库将用于跟踪依赖关系,subrepo A将用于跟踪主要源文件,subrepo B(和其他)将用于跟踪模块/插件开发.

问题/疑问

通过简单地将Subrepo_A路径和源添加到.hgsub文件并将其提交到构建仓库,我可以设置初始构建仓库和嵌套Subrepo_A.但是,当我将subrepo_B路径/源添加到构建存储库的.hgsub之后,然后尝试提交我收到错误消息:

abort:path'Subrepo_A/Modules/Sebrepo_B'在嵌套repo'Subrepo_A'中

Mercurial似乎不喜欢已嵌套的repo中的嵌套repo.这是真的吗,还是我错过了什么？关于如何管理构建/依赖关系的任何更好的想法？

如果Mercurial可以做到这一点,我很好奇.我想在项目中有一个子目录,它总是固定在手动指定的变更集上,或者更好 - 标记.

基本上我想要实现的是在主repo中有一个核心系统,然后是subrepos中的所有模块和组件,但我不希望那些subrepos指向tip,只是指向那些组件/模块的主要版本(因此标签).