公开存储库的子集，同时保留历史记录
我有一些受版本控制的代码（使用 Mercurial），并且想分享其中的一些代码，同时隐藏我无法发布到公共领域的其他部分（至少在现阶段）。
理想情况下，我希望保持公共代码的修订历史记录完整，更重要的是，能够在公共存储库和包含公共和私有代码的存储库之间推/拉更改。但是，不应该能够从公共存储库历史记录中恢复任何私人信息。
从我到目前为止收集到的信息来看，应该可以使用 提取公共内容hg Convert 与 filemap 并排除，尽管这会更改所有修订 ID 并阻止两个存储库之间的任何交互。
为了完整起见，我想我应该补充一点，该存储库最初是从 cvs 转换而来的。
如有任何想法，将不胜感激
I've got some code under version control (using mercurial), and would like to share some of it, whilst hiding other parts which I cannot release into the public domain (at least at this stage).
I'd ideally like to keep the revision history of the public code intact, and, more importantly, be able push/pull changes between the public repository and the repository containing both public and private code. It should not, however, be possible to recover any of the private info from the public repository history.
From what I've gleaned so far, it should be possible to extract the public stuff using hg convert with a filemap and excludes, although this would change all the revision ids and preclude any interaction between the two repositories.
For completeness I guess I should add that the repository was originally converted from cvs.
Would be grateful for any ideas,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这并不总是实用，但如果您的存储库的公共部分可以限制（或移动到）当前存储库的子目录，那么您可以：
hg Convert) 其自己的存储库中的子目录然后，您将管理两个存储库：
It is not always practical, but if the public part of your repo can be limited (or move to) to a subdirectory of your current repo, then you could:
hg convert) that subdirectory in a repo of its ownYou would then manage two repos:
如果您可以使用子存储库，这可能是最好的方法，但使用
convert不需要排除各个部分之间的交互。如果公共和私有内容完全不相交，请使用convert将原始存储库拆分为两个完全不相交的子集（重新生成所有变更集 ID），然后重新创建您的“超集”存储库通过克隆一个并拉动另一个（使用--force克服 hg 对不相关存储库的反对）。您最终会得到一个稍微非常规的存储库，其中有两个无父级变更集和两个头。合并头部，您将再次获得公共和私有的统一视图，公共存储库的祖先实际上位于其自己的分支上。If you can use subrepos, that's probably the best way to go, but using
convertneed not preclude interaction between the pieces. If the public and private stuff is completely disjoint, useconvertto split the original repo into two completely disjoint subsets (regenerating all changeset IDs), then recreate your "superset" repo by cloning one and pulling the other (using--forceto overcome hg's objection to unrelated repositories). You'll end up with a slightly unconventional repo which has two parent-less changesets and two heads. Merge the heads and you have a unified view of public and private again, with the public repo's ancestry effectively on a branch of its own.