如何防止某些修改传播到水银中? [英] How can I keep some modifications from propagating in mercurial?

问题描述

我正在开发一个Web数据库，该数据库已经用于大约十二个单独的安装中，其中大多数也由我管理.每个安装都有相当多的本地配置和自定义.刚刚从svn转换为mercurial之后，我想利用其分布式特性来跟踪本地修改.我已经将每个已安装的服务器设置为其自己的存储库(并配置了不为.hg目录提供服务的apache).

I am developing a web database that is already in use for about a dozen separate installations, most of which I also manage. Each installation has a fair bit of local configuration and customization. Having just switched to mercurial from svn, I would like to take advantage of its distributed nature to keep track of local modifications. I have set up each installed server as its own repo (and configured apache not to serve the .hg directories).

我的困难是开发树还包含本地配置，因此我想避免将其每一部分都放在未版本控制的配置文件中.因此，如何进行设置以避免将本地配置传播到主存储库和已安装的副本?

My difficulty is that the development tree also contains local configuration, and I want to avoid placing every bit of it in an unversioned config file. So, how do I set things up to avoid propagating local configuration to the master repo and to the installed copies?

示例:我有一个很长的config.ini文件，应该对其进行版本控制和分发. 干净"版本包含数据库连接参数的占位符，我不希望开发服务器的密码最终出现在已安装副本的存储库中.但是我会不时做出需要传播的更改(例如，新的默认设置).在类似情况下，有几个文件.

Example: I have a long config.ini file that should be versioned and distributed. The "clean" version contains placeholders for the database connection parameters, and I don't want the development server's passwords to end up in the repositories for the installed copies. But now and then I'll make changes (e.g., new defaults) that I do need to propagate. There are several files in a similar situation.

到目前为止，我能解决的最好问题包括安装mq并将本地修改内容转换为补丁程序(实际上是两个补丁程序，它们在逻辑上是分开的变更集).每次我想对 local 存储库提交常规更改集时，都需要弹出所有补丁，提交修改，然后重新应用补丁.当准备好推送到主存储库时，我必须再次弹出补丁，推送并重新应用它们.这都是令人费解的并且容易出错.

The best I could work out so far involves installing mq and turning the local modifications into a patch (two patches, actually, with logically separate changesets). Every time I want to commit a regular changeset to the local repo, I need to pop all patches, commit the modifications, and re-apply the patches. When I'm ready to push to the master repo, I must again pop the patches, push, and re-apply them. This is all convoluted and error-prone.

我能看到的唯一另一种选择是忘记推送，而仅将变更集作为补丁传播，这似乎是更糟糕的解决方案.有人可以建议一个更好的设置吗?我无法想象这是一个如此不寻常的配置，但是我对此一无所获.

The only other alternative I can see is to forget about push and only propagate changesets as patches, which seems like an even worse solution. Can someone suggest a better set-up? I can't imagine that this is such an unusual configuration, but I haven't found anything about it.

在遵循了这里的建议之后，我得出的结论是，命名分支加上重新提供了一个简单且可行的解决方案.我以自己的答案的形式添加了描述.请看看.

After following up on the suggestions here, I'm coming to the conclusion that named branches plus rebase provide a simple and workable solution. I've added a description in the form of my own answer. Please take a look.

推荐答案

在遵循了这里的建议之后，我得出的结论是，命名分支加rebase提供了一种简单而可靠的解决方案.我已经使用以下方法一段时间了，并且效果很好.基本上，围绕局部更改的历史记录分为命名的分支，可以通过重新设置轻松地对其进行重新排列.

Having followed up on the suggestions here, I came to the conclusion that named branches plus rebase provide a simple and reliable solution. I've been using the following method for some time now and it works very well. Basically, the history around the local changes is separated into named branches which can be easily rearranged with rebase.

我使用分支local来获取配置信息.当我所有的回购都支持阶段时，我将标记本地分支secret；但是如果没有它，该方法将起作用local依赖于default，但是默认值不依赖于local，因此可以独立地进行推送(使用hg push -r default).运作方式如下:

I use a branch local for configuration information. When all my repos support Phases, I'll mark the local branch secret; but the method works without it. local depends on default, but default does not depend on local so it can be pushed independently (with hg push -r default). Here's how it works:

1. 假设开发的主线在default分支中. (您可以有更多分支；这是为了具体).有一个主(稳定)存储库，其中不包含密码等.

1. Suppose the main line of development is in the default branch. (You could have more branches; this is for concreteness). There is a master (stable) repo that does not contain passwords etc.:

---o--o--o   (default)

在每个已部署(非开发)克隆中，我创建一个分支local并将其所有本地状态提交给它.

In each deployed (non-development) clone, I create a branch local and commit all local state to it.

...o--o--o   (default)
          \
           L--L    (local)

上游更新始终是默认设置.每当我提取更新时，我都会将它们合并到local(n是一系列新更新):

Updates from upstream will always be in default. Whenever I pull updates, I merge them into local (n is a sequence of new updates):

...o--o--o--n--n    (default)
          \     \
           L--L--N     (local)

本地分支跟踪default的演变，如果出现问题，我仍然可以返回旧配置.

The local branch tracks the evolution of default, and I can still return to old configurations if something goes wrong.

在开发服务器上，我从相同的设置开始:具有配置设置的local分支，如上所述.这将永远不会被推动.但是在local的尖端，我创建了第三个分支dev.这是新的发展发生的地方.

On the development server, I start with the same set-up: a local branch with config settings as above. This will never be pushed. But at the tip of local I create a third branch, dev. This is where new development happens.

...o--o   (default)
       \
        L--L    (local)
            \
             d--d--d     (dev)

当我准备将某些功能发布到主存储库时，我首先将整个dev分支重新建立到default的尖端:

When I am ready to publish some features to the main repository, I first rebase the entire dev branch onto the tip of default:

hg rebase --source "min(branch('dev'))" --dest default --detach

上一棵树变为:

...o--o--d--d--d   (default)
       \
        L--L    (local)

重新设置的变更集现在属于分支default. (对于功能分支，将--keepbranches添加到rebase命令以保留分支名称).新功能在local中不再有任何祖先，我可以在push -r default中发布它们，而无需拖延本地修订. (切勿将local 合并为 default；相反).如果您在推动时忘记说-r default，那么没问题:您的推动被拒绝，因为它将添加一个新的头部.

The rebased changesets now belong to branch default. (With feature branches, add --keepbranches to the rebase command to retain the branch name). The new features no longer have any ancestors in local, and I can publish them with push -r default without dragging along the local revisions. (Never merge from local into default; only the other way around). If you forget to say -r default when pushing, no problem: Your push gets rejected since it would add a new head.

在开发服务器上，我将重新建立了基础的rev合并到local中，就像我刚刚将它们拉出一样:

On the development server, I merge the rebased revs into local as if I'd just pulled them:

...o--o--d--d--d   (default)
       \        \
        L--L-----N    (local)

我现在可以在local的顶部创建一个新的dev分支，然后继续开发.

I can now create a new dev branch on top of local, and continue development.

这具有我可以在版本控制的配置安装程序上开发的好处；我不需要弄乱补丁；历史记录中保留了以前的配置阶段(如果我的Web服务器在更新后停止工作，则可以更新回 configured 版本)；当我准备发布更改时，我只需要重新设置一次基准.如果修订版本与本地配置更改冲突，则重新编制基准和随后的合并可能会导致冲突.但是如果要实现，最好在合并工具可以帮助解决它们的情况下发生.

This has the benefits that I can develop on a version-controlled, configured setup; that I don't need to mess with patches; that previous configuration stages remain in the history (if my webserver stops working after an update, I can update back to a configured version); and that I only rebase once, when I'm ready to publish changes. The rebasing and subsequent merge might lead to conflicts if a revision conflicts with local configuration changes; but if that's going to happen, it's better if they occur when merge facilities can help resolve them.

这篇关于如何防止某些修改传播到水银中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！