将更新推送到修剪的Mercurial分支 [英] Pushing updates to a pruned Mercurial branch

问题描述

我有两个相关的存储库，一个包含许多不能泄漏的敏感文件的主文件和一个使用hg convert和--filemap创建的'public'版本来排除敏感文件和目录。

p>

我希望对主服务器进行进一步的更新，不会影响可从服务器上激活的敏感文件，并更新从服务器以使主服务器可以进行更新。现在，这不会发生，因为它们被认为是'不相关的'存储库。如果Git可以实现这一点，但Mercurial不可行，迁移是可能的，尽管它由于在Windows机器上进行了一些开发，这将是一个麻烦事。奴隶还没有看到积极的外部使用，所以有可能如果有必要的话，可以将其重新创建并以其他方式重新创建。甚至有可能，如果绝对必要的话，完全转储主服务器并从服务器重新克隆，然后将所有敏感部分完全保留未版本化，但我非常希望不必这样做，因为其中一些文件 正在改变，我想跟踪这些改变。

有人有什么好主意？

更新：我一直在嘲笑关于Git的文档 - 可以使用Git临时区域轻松实现推送除这些以外的所有文件命令吗？

更新2：这对我没有帮助，但它可能会帮助出现类似问题的人：您可以使用 hg convert --filemap ，它只会跟踪对master的更新，但如果目标资源库是通过文件系统写入的，则这个 only 会起作用，并且不会工作电线。当然，它也没有帮助。

解决方案

好的，看起来真正的答案是 Mercurial不能做你想做的事情（这是为了在存储库和作为该存储库的一个严格子集的分支之间进行同步），因为它没有使用像修补程序队列这样的非常不方便的系统。 Git可能有，但由于它的Windows端口还没有准备好用于生产，所以我没有仔细考虑它。

然而，它确实发生了有可能以这样的方式重组项目，即可以将公共部分和私人部分拆分成单独的存储库，而只有相对较小的历史损失。 （实际上，它在我们处于分裂的三种方式中进行了分割 - 公共部分，我们放在子目录 local / 中的公共部分 - 特定于机器的部分（so它可以克隆到几乎相同规格的大部分机器上，而无需在少数奇怪的机器上维护和合并额外的分支）以及我们放在子目录 private / 。）诀窍结果并不是试图把一个干净的奴隶放在主人的内部，而是将主人的私人/本地部分拆分出来，并把它们作为（伪）子版本库放在第一阶段是将文件移动到 private / 和 local / 目录，将它们从主存储库中删除，并在替换符号链接在其他机器上出现问题时根据需要将它们添加到.hgignore中。值得庆幸的是，我们不得不通过这种方式移动大约95％的东西，而不是位置敏感的东西，其余的东西我们可以手动管理。这两个目录然后成为自己的仓库。

第二阶段我们已经基本完成了： hg convert 使用 - filemap 来创建公有版本的存储库，其中所有私人数据的痕迹已被删除。 （这实际上需要一点点的文件映射调整：不仅要排除所有当前的私有数据文件名，还要排除它们以前可能拥有的任何文件名.Mercurial跟踪文件移动/重命名的功能似乎并不完全健壮。）

此时，主服务器上的 .hg / 目录移至备份位置，从清洁的公共存储库中取出新鲜的物品。然后，我们运行测试以确保一切正常，并开始克隆新的基础知识库，并选择 local 存储库关闭从属机器，并对其进行测试，并且所有内容似乎都是好吧，尽管我们必须调整一些符号链接停止工作的地方（主要是在Windows机器上，尽管在一个地方，好奇的是，在Linux一侧，我将不得不挖掘为什么没有遵循符号链接当我得到一些空闲时间时，虽然我们解决了这个问题，但发现一个特定的文件可以并且真的应该自动重新生成）。

I have two related repositories, a master, which contains a number of sensitive files which must not be leaked, and a 'public' version, created with hg convert with --filemap to exclude the sensitive files and directories.

I would like further updates to the master that don't affect the sensitive files to be pushable to the slave, and updates to the slave to be pullable by the master. Right now this doesn't happen, as they are considered 'unrelated' repositories

If this is possible with Git, but not with Mercurial, migration is a possibility, though it will be a nuisance since some development happens on Windows machines. The slave is not yet seeing active outside use, so it's possible to nuke it and recreate it another way if necessary. It is even possible, if absolutely necessary, to dump the master entirely and re-clone from the slave, and then leave all of the sensitive portions completely unversioned, but I would greatly prefer not to have to do this, since some of those files are changing, and I'd like to keep track of those changes.

Does anyone have any good ideas?

Update: I've been poking at the documentation on Git -- can a "push all files except these" command be easily implemented using the Git staging area?

Update 2: This doesn't help me, but it might help someone with a similar issue: you can use hg convert --filemap repeatedly and it will only track the updates to the master, but this only works if the destination repository is written via filesystem, and won't work over the wire. It also doesn't help in the opposite direction, of course.

解决方案

Okay, it seems like the real answer is, "Mercurial can't do what you want" (which is to have synchronization between a repository and a branch which is a strict subset of that repository) short of using some hideously inconvenient system like the patch queues. Git might have, but since its Windows port isn't yet ready for production use, I didn't look that hard into it.

However, it did turn out to be possible to reorganize the project in such a way that it was possible to split up the public and private portions into separate repositories with only relatively minor loss of history. (Actually, it got split three ways while we were at it -- the public section, a public-but-machine-specific section that we put in subdirectory local/ (so it could be cloned to the bulk of the machines with nearly identical specs without having to maintain and merge extra branches on the few weird ones), and a private section that we put in subdirectory private/.) The trick turned out to not try to put a cleaned slave inside the master, but to split out the private/local parts from the master and put them as (pseudo-)sub-repositories inside the slave repository on the master machine.

Stage 1 was to move files into the private/ and local/ directories, remove them from the master repository, and add them to the .hgignore as needed when the replacement symlinks would have been problematic on other machines. Thankfully, about 95% of the stuff we had to move this way wasn't location-sensitive, and the rest we could manage by hand. Those two directories then became repositories of their own.

Stage 2 we had basically already done: a hg convert using --filemap to create a public version of the repository where all traces of private data had been removed. (This actually required a little bit of filemap tuning: you have to exclude not only all the current private data filenames, but also any filenames they might have had in the past. Mercurial's ability to track file moves/renames seems to be not entirely robust.)

At this point, the .hg/ directory on the master got moved to a backup location, and a fresh pull was made from the cleaned, public repository. We then ran our tests to make sure everything was working, and started cloning the new base repository and selected local repositories off to slave machines, and tested those, and everything seems to be okay, though we had to tweak a few places where symlinks stopped working (mostly on Windows boxes, though in one spot, curiously enough, on the Linux side, and I'm going to have to dig into why the symlink wasn't followed when I get some spare time, though we solved the problem when it was discovered that that one particular file could, and really should, be automatically regenerated).

这篇关于将更新推送到修剪的Mercurial分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！