我即将对我的 Mercurial 存储库进行一些重大更改。由于我将使用最后手段的功能，我正在寻找一些建议和保证，我不会做愚蠢的事情。
我在哪里：
我有一个 Mercurial 存储库，其中包含所有这些文件的完整历史记录：
/source
/secret_subsystem
/unclassified_subsystem
/common_files
源是 Mercurial 存储库。秘密子系统文件夹包含我们想要保留在内部的知识产权代码。未分类的子系统文件夹包含我们想要外包给第三方维护的代码。公共文件夹包含两个子系统所依赖的代码。我们将保留所有权，但我们希望与第三方共享。
显然，我不能将我的整个存储库推送给第三方公司。第三方会看到太多。
我想去的地方：
在 阅读 了 subrepositories 之后，我认为我需要这样做：
有三个子存储库：secret_subsystem、unclassified_subsystem、common_files。由于此建议，请确保 /source 级别没有其他文件。
让外包商在其机器上的源代码级别创建一个全新的存储库，以及两个相应的子存储库。
将 unclassified_subsystem 和 common_files 推送到外包商，根据需要拉回 unclassified_subsystem，根据需要推送新的 common_files 存储库。
维护历史：
我想尽可能多地维护所有子系统的提交历史。
为此，我将运行hg convert扩展命令 3 次，每个子存储库运行一次。我将过滤到仅属于每个子存储库的文件。我可能还需要映射文件名以将文件从 ./common_files/foo.py 移动到 ./foo.py （例如）。
我的问题：
1）将存储库划分为子存储库是实现安全性的合理方式 - 即。第三方只能查看和编辑我们的一些文件？
2) 是否使用hg convert合理的方式从现有存储库创建子存储库，同时仍保留历史记录？
3)hg convert的过滤器会去掉 (a) 所有关于不在过滤存储库中的文件的提交消息吗？它会过滤掉不在过滤存储库中的文件的所有差异吗？
还有另一个隐含的问题：我是否正在进入一个受伤的世界？如果是这样，我将简单地放弃保留文件历史记录，甚至将它们设为单独的存储库并忘记跨存储库提交。