我们处于这样一种情况：我们有一个“通用模块”存储库，它在不同的项目存储库之间共享。 我们面临的问题是，如果您回到项目的早期版本，我们无法真正知道该项目使用了哪些“通用模块”修订版。 我们可以检查日期和时间戳，看看它们是否匹配，但必须有另一种更优雅的方法来做到这一点。 通用模块存储库不会像项目本身那样频繁地更改。 我的问题是：你如何处理这个以及最佳做法是什么？
We are in a situation where we have one "general modules" repository which is shared between different project repositories. The problem we face is that if you go back to an earlier version of a project, we cannot really know which "general modules" revision has been used with this project. We could check the date and time stamp and see if they match, but there must be another more elegant way to do this. The general modules repository doesn't change as frequently as the projects itself. My question is: how do you deal with this and what are the best practices?
最满意答案
我认为你有什么选择，虽然我认为两者只会对未来有所帮助，但无法真正解决你过去的历史。
Subrepositories
Subrepos是您问题的原始Mercurial解决方案。 将常规模块repo克隆到主项目工作副本中，并将其工作副本更新为要使用的修订版。 然后你设置一个.hgsub文件，它告诉主项目它有一个subrepo，它应该去哪里以及它的来源。 然后，当您提交主项目时，将提交.hgsub，并将常规模块工作副本的哈希值保存到.hgsubstate文件中的修订版中。
但是它们存在问题，
递归提交和推送，这可能是不可取的; 它们可能难以理解，因此是错误的根源; 如果您移动源代码库，您的更新将失败，尽管有一个子路径配置选项可以解决此问题。这是使用subrepos的一个很好的演练。
来宾回购
我从来没有使用这些，所以我不能评论他们的利弊甚至他们的使用，但这里是Guest Repos Extension的链接。 我认为这个想法是它比subrepo设置更容错，所以如果guest虚拟机repo源丢失或指定的变更集丢失，它更容易修复。
我也看到了对嵌套repos的引用，对于guest repos来说略有不同，但我不确定它们是否真的是不同的东西。
I think there are a couple of options for what you're after, although I think both will only help for the future and can't really fix up your past history.
Subrepositories
Subrepos are the original Mercurial solution to your issue. You clone the general modules repo into your main project working copy and update its working copy to the revision you want to use. Then you set up a .hgsub file which tells the main project that it has a subrepo, where it should go and where the source of it is. Then when you commit the main project the .hgsub is committed and the hash of the general modules working copy is saved into the revision in a .hgsubstate file.
However there are issues with them,
recursive commits and pushes, which may not be desirable; they can be difficult to understand and therefore a source of errors; if you move the source repo your updates will fail, although there is a subpaths config option that gets around this.Here's a good walkthrough on using subrepos.
Guest repos
I've never used these so I can't comment on their pros or cons or even their use but here is a link to the Guest Repos Extension. I think the idea is that it's more fault tolerant than the subrepo setup, so if the guest repo source is missing or the changeset specified is missing it's easier to fix.
I've also seen references to nested repos, as a slightly different thing to guest repos, but I'm not sure if they genuinely are different things.
更多推荐
发布评论