每当我在生产服务器上更新Mercurial分支时，是否都必须合并并提交? [英] Should I have to merge and commit every time I update my Mercurial branch on the production server?

问题描述

我在最近的项目中使用Mercurial.在我要部署项目的Web服务器上，我有一个与生产设置稍有不同的配置文件.问题是当我pull和update时，我经常也必须同时merge和commit.

I'm using Mercurial in a recent project. On the web server where I'm deploying the project I have a slightly different config file with production settings. The problem is when I pull and update, I often have to merge and commit as well.

这是正确的工作流程吗?为了能够继续更新，我必须提交变更集，这似乎很奇怪，我认为合并会将它们集成到生产分支中，并在每次更新时继续这样做.这是我还不习惯的分布式版本控制范例吗?

Is this the correct workflow? It seems strange that in order to be able to continue to update I have to be committing the changesets, I figured a merge would integrate them into my production branch and continue to do so each time i update. Is this a distributed version control paradigm I'm just not used to yet?

推荐答案

这是经过处理的

This was sort of handled in this question, but I think your question is better in that it seeks a little more clarity.

简而言之:是的，这很正常.这有点膨胀:

In short: Yes, it's normal. Here's a bit of an expanation:

您首先从主存储库(其中的框为变更集)开始

You start out with this in the main repository (where the boxes are changesets):

main: --[E]--[F]--[G]

然后克隆到生产服务器，并添加一个变更集H，以进行部署自定义.因此，部署库如下所示:

then you clone to the production server and add a changeset, H, that does the deployment customization. So the deployment repo looks like this:

production: --[E]--[F]--[G]--[H]

然后在主存储库上进行了更多工作，添加了变更集I和J，使主存储库看起来像这样:

and then more work happens on the main repo, adding changesets, I and J, making the main repo look like:

main: --[E]--[F]--[G]--[I]--[J]

将其投入生产后的样子:

which when pulled to production looks like:

production:  --[E]--[F]--[G]--[I]--[J]
                            \         
                             \-[H]

具有两个头部，您可以合并以得到:

with two heads, which you merge to get:

production:  --[E]--[F]--[G]--[I]--[J]
                            \         \
                             \-[H]-----[K]

其中K只是J加上您最初在H中所做的更改.

where K is just J plus the changes you originally did in H.

现在，主体上还有更多工作要做，

Now more work happens in main, giving:

main: --[E]--[F]--[G]--[I]--[J]--[L]--[M]

您要投入生产的产品:

production:  --[E]--[F]--[G]--[I]--[J]--[L]--[M]
                            \         \
                             \-[H]-----[K]

然后合并并获得:

production:  --[E]--[F]--[G]--[I]--[J]--[L]--[M]
                            \         \         \
                             \-[H]-----[K]-------[N]

因此，每次从main引入更改时，您都在进行一次合并，并创建一个新的更改集(这次是N).

So every time you bring changes in from main, you're doing one merge, and creating one new changeset (this time N).

我认为还可以，而且是正常".

I think that's okay, and it is "normal".

但是，您可以通过使用我在上面与链接的问题中的一些答案来避免这种情况，并且可以使用一种新技巧来保持 modify 原始H的父母(和内容)，以便它总是移到新提示的末尾.

You can, however, avoid it by using some of the answers in the question I linked to above and there's a new trick you can use to keep modifying the original H's parents (and content) so that it always moves to the end of whatever is the new tip.

诀窍是 Rebase扩展，它将在生产中产生线性历史记录(尽管您可以仍然会进行本质上是合并的操作来获得它).我不喜欢它，因为我不喜欢在提交变更集之后对其进行更改，但是由于H永远不会离开生产环境，所以没关系.

The trick is the Rebase Extension and it would yield linear history on production (though you'd still be doing what's essentially a merge to get it). I'm not a fan of it because I don't like changing changesets after they're committed, but since H is never leaving the production box it's okay.

其他答案是 Mercurial队列和

The other answers were mercurial queues and making the production changes live in the dev repo and get triggered by something that's different in the production environment (like the Host: header).

这篇关于每当我在生产服务器上更新Mercurial分支时，是否都必须合并并提交?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！