我在哪里：

Question

我即将对我的Mercurial存储库进行一些重大更改。由于我将使用Feature of Last Resort，我正在寻找一些建议，并保证我没有做一些愚蠢的事情。

我有一个Mercurial存储库，其中包含所有这些文件的完整历史记录：

/source
    /secret_subsystem
    /unclassified_subsystem
    /common_files

Source是Mercurial存储库。秘密子系统文件夹包含我们想要保留在内部的知识产权代码。未分类的子系统文件夹包含我们希望外包给第三方维护的代码。 common files文件夹包含两个子系统所依赖的代码。我们将保留所有权，但我们希望与第三方分享。

显然，我不能将整个存储库推送到第三方公司。第三方会看得太多。

我想去的地方：

Having read up on subrepositories，这是我认为我需要的地方：

拥有三个子存储库：secret_subsystem，unclassified_subsystem，common_files。由于this recommendation，确保/ source级别没有其他文件。

让外包商在他们的机器上的源级别创建一个全新的存储库，以及两个相应的子存储库。

将unclassified_subsystem和common_files推送到out-sourcer，根据需要撤回unclassified_subsystem，根据需要推出新的common_files存储库。

我想保留所有子系统的提交历史记录。

为此，我将对每个子存储库运行一次hg convert扩展命令三次。我将仅过滤到属于每个子存储库的文件。我可能还需要映射文件名以将文件从./common_files/foo.py移动到./foo.py（例如）。

1）将存储库划分为子存储库是一种实现安全性的合理方式 - 即。第三方只能看到和编辑我们的一些文件？

2）是否使用hg convert以合理的方式从现有存储库创建子存储库，同时仍保留历史记录？

3）将hg convert的过滤器删除（a）所有提交有关不在过滤的存储库中的文件的消息？它会过滤掉不在过滤的存储库中的文件的所有差异吗？

还有另一个隐含的问题：我是否正在进入一个受伤的世界？如果是这样，我将简单地放弃保留文件历史记录，甚至将它们分成独立的存储库并忘记跨存储库提交。

Answer 1

到目前为止我还没有使用过subrepos，但我可以回答2）和3）：

2）是的，听起来很合理。

3）是的。