检查 Mercurial 存储库的子集
首先，我有一个非常大的 cvs 存储库，并且我正在尝试将其切换到 Mercurial。 cvs 存储库由多个目录组成，有点像 this 问题。然而，每个子目录并不是一个完整的独立项目。每个项目都使用整体的一个子集，但它们的交集不为空。
这里有一个例子来说明：
/cvsroot
.../core
.../feature-1
.../feature-2
项目 1 使用 core 和 feature-1；项目 2 使用 core 和 feature-2。我不希望从事项目 2 的人员在其工作副本中拥有 feature-1 目录，因为它实际上是一组大约 30 个目录，并且空间量也不少。
有没有办法用 Mercurial 轻松（或者很好地）解决这个问题？我考虑过为交叉点使用一个单独的存储库，但这是次优的。这意味着进行额外的拉取和额外的更新，并可能编写一堆脚本来管理它。
我的另一个选择是复制每个中的交叉点。但这不好，因为它可能会导致公共代码分叉，因为不同的人处理它的不同部分。
First, I have a very large cvs repository and I'm trying to switch things over to mercurial. The cvs repository consists of several directories, sort of like the situation in this question. However, each subdirectory is not an entire independent project. Each project uses a subset of the whole but their intersections are not empty.
Here's an example to clarify:
/cvsroot
.../core
.../feature-1
.../feature-2
Project 1 uses core and feature-1; project 2 uses core and feature-2. I don't want people who work on project 2 to have the feature-1 directory in their working copies, because it's actually a set of about 30 directories and a not insignificant amount of space.
Is there a way to deal with this easily (or, alternatively, well) with mercurial? I thought about using a separate repository for the intersection, but that's suboptimal. It means doing an extra pull and extra updates and probably writing a bunch of scripts to manage it.
My other alternative was replicating the intersection in each. That's no good though because it's likely to cause the common code to fork, since different people work on different parts of it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 Mercurial 子存储库 应该会有所帮助。我将
core、feature-1和feature-2定义为独立的存储库，然后使用子存储库功能将它们链接在一起。项目 1 将引入core和feature-1，而项目 2 将引入core和feature-2。每个底层存储库仅存在一次，因此不同的项目正在有效地共享它们。您可以配置子存储库，以便当项目 1 执行提交和推送时，它会推送到
core和feature-1，或者您可以要求用户提交给它们通过导航到目录并将它们视为普通存储库来显式地进行处理。最后，您只能在存储库级别创建子存储库。换句话说，您无法在每个文件级别创建它们。
Using Mercurial subrepositories should help here. I would define
core,feature-1, andfeature-2as independent repositories and then link them together using the subrepository feature. Project 1 would pull incoreandfeature-1, while Project 2 would pull incoreandfeature-2. Each of the underlying repos only exists once, so different projects are effectively sharing them.You can configure the subrepos so that when Project 1 performs a commit and push, it pushes to both
coreandfeature-1, or you can require the user to commit to them explicitly by navigating into the directory and treating them like a normal repo.Finally, you can only create subrepos on a repository level. In other words, you can't create them on a per file level.