Mercurial“供应商分支”来自外部存储库？
我想在 Mercurial 中存储一个项目，其中包含来自 Git 和 SVN 存储库的外部代码（可以由我修改）。在 SVN 中，我将使用 供应商分支 解决此问题并复制周围的代码，但我明白在 Mercurial 中，它是最好为不同的项目拥有不同的存储库，并在需要时在它们之间进行拉取。
项目布局将如下所示：
- externalLibraryA [comes from a SVN repo] - ...with some extra files from me - externalLibraryB [comes from a SVN repo] - ...with some extra files from me - externalPluginForExternalLibraryB [comes from a Git repo]
在 Subversion 中，我将创建 vendor 目录和 trunk 目录，首先将所有外部库复制到 vendor 中，然后然后在trunk中的正确位置。 （我认为）我也可以在 Mercurial 中使用 subrepositories 执行此操作，但这是最好的方法要这样做吗？
我尝试为外部库设置不同的存储库，但似乎无法将 externalLibraryARepo 拉入主存储库的 externalLibraryA 目录？它位于主目录中，这不是我想要的。我还可以创建一个 Mercurial 镜像存储库并将其作为子存储库包含在我的主存储库中，但随后此子目录中的更改将转到镜像存储库，而我希望它们保留在主存储库中。
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo] - ...with some extra files from me - externalLibraryB [comes from a SVN repo] - ...with some extra files from me - externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我可能只是将其存储在一个存储库中 - 请注意，在您提供的链接中，他们最终使用其构建系统将不同存储库的二进制输出汇集在一起。我不清楚他们的理由。
如果您试图解决的根本问题是如何以干净的方式更新外部，我可能会使用 匿名分支 。
即，将外部库添加到您的项目中，以及您的修改。确保它有效。使用ExternalA-v1.0 进行标记。破解你的实际项目。现在，ExternalA, Inc. 推出了他们的产品的新版本。将您的存储库更新为ExternalA-v1.0 标签。导入他们的新版本并在上面应用您的修改。犯罪。现在您有两个头：一个包含最新版本的代码（适用于ExternalA-v1.0），另一个包含最新版本的ExternalA（可能不适用于您的代码）。然后你将两者合并并协调。再次标记，现在使用ExternalA-v2.0。根据需要重复。
您仍然可以将外部存储库保存在单独的存储库中，但我认为使用这些外部存储库的项目不需要始终与那里的更改保持同步 - 看起来供应商分支的全部意义在于具有某种隔离点受抚养人和受抚养人之间。当然，将更改从 externalA 项目移动到正在使用的项目将是一项手动操作（嗯，一个副本，就像在 SVN 中一样）。
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
这取决于您的团队是否会自定义您的供应商代码。我们的团队在存储库上维护命名的“供应商”分支方面取得了巨大的成功，并在按项目名称命名的分支上进行了我们自己的定制。然后，该供应商代码可以轻松地作为子存储库包含在项目中。
这种方法的一个警告：如果在子存储库中正在进行积极的开发，最好将其作为单独的克隆直接编辑子存储库，否则有必要密切关注顶级存储库，这样您就不会无意中碰撞您的 .hgsubstate 转发到错误的修订版本并破坏您的构建。
请注意指向子存储库的不同命名分支的版本之间的顶级存储库（您的项目）的合并，因为这可能会导致子存储库中的“供应商”和“项目”分支在递归时发生合并，这可能是不可取的。
请注意，此功能将来也可能会发生变化，因为最近几个月在 Mercurial-devel 邮件列表上正在进行一些关于子存储库递归的未来的“热烈”讨论。
编辑：
我刚刚也在相关链接中看到了此讨论，这似乎相关： https://stackoverflow.com/a/3998791/1186771< /a>
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771