Mercurial：保持两个分支同步但具有一定的持久性差异？

Question

我是一名使用django自行开发的网站开发人员，我正试图了解如何使用mercurial部署网站。我想拥有的是能够保留一个可用于生产和开发工作的存储库。生产/开发之间总会存在一些差异（例如，他们可能使用不同的数据库，开发将始终打开调试）但总的来说它们将是同步的。我也希望能够直接在生产服务器上进行更改（整理html或css，简单的错误修正等）。

我打算使用的工作流程如下：

• 创建2个分支，prod和dev（所有设置最初设置为生产设置）
• 更改settings分支中的settings.py和其他一些内容。所以现在我有2个头，从现在开始，存储库总是有2个头。
• （在开发机器上）对dev进行更改，然后使用'hg transplant'将相关的变更集复制到生产中。
• 推送到主存储库
• （在生产服务器上）从主仓库中拉出，更新到prod head

注意：只要将更改移植到dev中，您也可以直接进行更改。

此工作流程的缺点是，无论何时进行更改，您不仅必须将其提交到您进行更改的任何分支，还必须将其移植到其他分支。有没有更合理的方式来做我想要的事情，也许使用补丁？或者失败了，有没有办法让提交过程自动将变更集自动移植到另一个分支，这会是一个好主意吗？

Answer 1

我可能会使用Mercurial Queues来做这样的事情。将主存储库保留为开发版本，并使用for-production补丁对生产进行必要的更改。

Answer 2

以下是两种可能的解决方案，一种使用mercurial，另一种不使用mercurial：

1. 使用主机名在prod和devel之间切换。我们在设置文件的顶部进行了一次检查，查看SERVER_NAME环境变量。如果它是www.production.com，则它是prod DB，否则它会选择指定的或默认的dev / test / stage DB。
2. 使用Mercurial，只需要一个包含dev的克隆和一个克隆的克隆，在dev中进行所有更改，并在部署时从dev到prod。在拉动之后，你将有两个头从一个共同的祖先分叉（最后一次部署）。一个头只有一个变更集，只包含开发和prod部署之间的差异，另一个将拥有所有新工作。将它们合并到prod clone中，当然选择冲突的prod变化，并且你有一个可部署的设置，并准备在'dev'上做更多的工作。无需分支，移植或使用队列。只要你从未将prod设置中的变更集拉到'dev'中，从dev开始就需要合并，如果只是几行就没什么可做的。

Answer 3

我用本地设置解决了这个问题。

1. 附加到settings.py：

   try:
   from local_settings import *
   except ImportError:
   pass
   

2. touch local_settings.py

3. 将^local_settings.py$添加到您的.hgignore

我所做的每个部署都有自己的本地设置（通常是不同的数据库内容和不同的原始电子邮件地址）。

PS：稍后才阅读“javascript部分的缩小版”。为此，我建议使用更新后挂钩和配置设置（如JS_EXTENSION）。

示例（从我的头顶开始！未经测试，必要时进行调整）：

1. 将JS_EXTENSION ='。raw.js'放入settings.py文件中;
2. 将JS_EXTENSION ='。mini.js'放在生产服务器上的local_settings.py文件中;
3. 从以下位置更改JS包含：

   <script type="text/javascript" src="blabla.js"></script>

   至：

   <script type="text/javascript" src="blabla{{JS_EXTENSION}}"></script>

4. 制作一个更新后的钩子，查找*.raw.js并生成.mini.js（原始的缩小版本）;
5. 将.mini.js$添加到您的.hgignore

Answer 4

也许尝试这样的事情:(我只是考虑这个问题，在我的情况下，它是一个sqlite数据库）

• 将settings.py添加到.hgignore，以使其远离存储库。
• 从两个单独的分支中获取settings.py个文件，并将其移至两个单独的文件settings-prod.py和settings-dev.py
• 创建一个部署脚本，将相应的settings-X文件复制到settings.py，以便您可以采用任何一种方式进行部署。

如果您有其他几个文件，请为它们执行相同的操作。如果你有很多文件，但它们都在同一个目录中，你可以创建一对目录：production和development，然后将相应的一个复制或符号链接到一个deploy目录。

如果你做了这样的事情，你可以省去分支你的存储库的需要。

Answer 5

我实际上是使用命名分支和直接合并而不是移植（这是更可靠的IMO）。这通常有效，但有时候（当你编辑了另一个分支上的不同文件时），你需要注意不要在合并时再次删除差异。

如果你没有太多改变不同的文件，它会很有效。