在公共 Mercurial 存储库中跟踪私人文件的最佳方法是什么？
“如果它不在源代码管理中，它就不存在。”
这个问题已在此处为 Git 解决：处理私有和公共存储库的技术？。那么 Mercurial 呢？
我有几个公共 Bitbucket 存储库（有多个提交者），我希望其中的源代码是公开的，但会从未跟踪的文件加载 API、SSH 密钥和其他敏感信息。然而，如果我们添加新的 Mailchimp 或 Hunch 或 Twilio API 密钥，这会导致有人通过电子邮件发送新的配置文件。有没有办法以某种方式保护这些文件不被公众看到并仍然跟踪它们？每个人都通过 Bitbucket 同步他们的存储库。
"If it’s not in source control, it doesn’t exist."
This question was addressed for Git here: Techniques to handle a private and public repository?. What about for Mercurial?
I have several public Bitbucket repos (with multiple committers) where I'd like the source to be public, but which load API, SSH keys and other sensitive info from untracked files. However this results in someone emailing around the new config file if we add a new Mailchimp or Hunch or Twilio API key. Is there a way to shield these files from public view somehow and still track them? Everyone is syncing their repo through Bitbucket.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有两种很好的方法来处理这个问题（除了 zerkms 的解决方案，它不能提供您想要的轻松同步，但无论如何我都会这样做）：
使用 Mercurial 队列。当您使用 hg qinit --create-repo 创建 Mercurial 队列时，它会创建一个可以在现有存储库之上进行 qpush 的覆盖系统。因此，您可以将秘密保存在队列中，并在需要时
qpush它们，在不需要时qpop它们。使用--create-repo，覆盖集（补丁）在其自己的存储库中处理。因此，知情者可以推/拉秘密覆盖存储库，而无法访问它的人可以使用基础存储库。补丁存储库可以是 bitbucket 上的私有存储库或托管在其他地方。或
完全按照 git 解决方案中的描述使用 subrepo .
There are two good ways to handle this (besides zerkms's solution, which doesn't offer the easy of synchronization you want, but is what I'd do anyway):
Use Mercurial Queues. When you create a mercurial queue with
hg qinit --create-repoit creates an overlay system that can beqpushed atop the existing repo. So you keep your secrets in queues andqpushthem when you need them, andqpopthem when you don't. With--create-repothe set of overlays (patches) is handled in a repository of its own. So people in the know can push/pull the secret overlay repo and people w/o access to it can use the base repo. The patch repo can be a private repo on bitbucket or hosted elsewhere.or
Use a subrepo exactly as described in the git solution.
创建内部包含模板的
filename.ext.sample文件（可能填充有虚拟数据），需要复制该文件并填充特定工作目录中的实际数据。这就是我通常做的事;-)
Create
filename.ext.samplefiles with templates inside (probably filled with dummy data), which need to be copied and filled with actual data in the particular working directory.That is what I usually do ;-)
Zerkms 的解决方案快速、简单且干净，可能是防止安全内容被跟踪/发布的最佳选择；然而正如你所说，“如果它不在源代码管理中，它就不存在。”我发现更多时候我试图排除源代码控制的并不是安全问题，而只是配置设置。我相信这些应该被跟踪，我现在的雇主有一个相当聪明的设置来处理这个问题，我将在这里尝试简化/概括/总结。
希望这里的想法非常清晰，我们在每个适当的级别定义设置，从而以逻辑和一致的方式对代码库的行为进行高度精细的控制。
scripts/configparse.sh脚本依次读取所有必要的配置文件，并根据它找到的所有设置构建.conf。config/env/控制不同环境中的行为，执行诸如指向正确的数据库服务器之类的操作。config/users/查找$USER.conf文件，该文件对于设置我关心的内容很有用，例如提高我的团队工作方面的日志记录级别，或自定义我更喜欢在我的所有机器上使用这种行为。config/hosts对机器执行相同的操作，查找$HOSTNAME.conf。对于特定于计算机的设置（例如应用程序路径或数据目录）很有用。config/local.conf是一个未跟踪的文件，可让您设置特定于结帐的值和/或您在版本控制中不需要的内容。所有这些设置的聚合都会输出到
.conf，这是代码库的其余部分在加载设置时查找的内容。Zerkms' solution is fast, easy, and clean, and likely your best bet for preventing secure content from being tracked / published; however as you say, "If it’s not in source control, it doesn’t exist." I find that far more often what I'm trying to keep out of source control is not a security concern, but simply a configuration setting. I believe these should be tracked, and my current employer has a rather clever setup for dealing with this, which I'll attempt to simplify / generalize / summarize here.
Hopefully the idea here is pretty clear, we define settings at each appropriate level, enabling highly granular control of the codebase's behavior in a logical and consistent fashion.
The
scripts/configparse.shscript reads all the necessary configuration files in turn and builds.confout of all the settings it finds.config/common.confis the starting point, and contains logical default values for every setting. Many will likely get overwritten, but something is specified here. It's an error for a setting to be found in another file that isn't first set in common.conf.config/env/controls the behavior in different environments, doing things like pointing to the correct database servers.config/users/looks for a$USER.conffile, useful for setting things I care about, such as increasing the logging level for aspects my team works on, or customizing behavior I prefer to use across all my machines.config/hostsdoes the same for machines, looking for$HOSTNAME.conf. Useful for machine-specific settings like application paths or data directories.config/local.confis an untracked file, and lets you set checkout-specific values and/or content you don't want in version control.The aggregate of all these settings is output to
.conf, which is what the rest of the codebase looks for when loading settings.