在不同的机器上保持hg版本控制文件的不同版本?

时间:2010-12-05 10:13:42

标签: version-control mercurial

我正在开发一个依赖外部程序的项目,需要知道它们的路径。我在几台机器上开发和使用该项目,使用mercurial进行版本控制。路径与机器有关,因此我将它们保存在机器特定的配置文件中。我希望每个主机的配置文件都是版本控制的,但是我需要确保来自一个主机的配置文件在主机之间推送或拉动时永远不会覆盖另一个主机的配置文件。有没有办法实现这个目标?

2 个答案:

答案 0 :(得分:3)

原则上,Wim是对的:机器特定的配置不应该是项目源控制的一部分。只要你独自行走,这不是一个真正的问题,但是一旦你想提供项目的泛型版本,就必须摆脱它们。在这种情况下,您可能不满意这样一个事实,即更改历史记录包含具有计算机特定数据的文件。

尽管如此,在版本控制文件中使用机器特定数据可能是有意义的(我个人是为我的 dot-rc 文件和shell脚本执行此操作)。在这种情况下,我建议将通用特定的配置分成不同的文件,并在构建或运行时包含/利用特定的,具体取决于在当前使用的机器上。

如果无法自动检测当前计算机,您仍然可以在每台计算机上创建一个未版本化的符号链接,指向相应的特定配置文件。例如,在机器 foo 上,文件布局可能如下所示:

  • generic.conf 版本控制
  • specific-foo.conf 版本控制
  • specific-bar.conf 版本控制
  • specific.confspecific-foo.conf 无版权符号链接

符号链接的替代方法是使用hook自动创建specific.conf,例如每次调用hg update时。由于在存储库的 hgrc 文件中设置了挂钩,因此可以在每台计算机上单独定义它。以下是计算机 foo 上的存储库克隆的.hg/hgrc文件中相应的 hooks 部分的示例:

[hooks]
update = cp specific-foo.conf specific.conf

答案 1 :(得分:0)

机器特定的配置设置不应在与项目代码相同的存储库中进行版本控制。

但是,在代码存储库中放置一个非活动的示例配置文件仍然是个好主意。此示例可以显示您提到的外部程序路径的一堆典型位置,这些路径被注释掉。这样,您就可以更轻松地在新机器上运行项目。