你如何管理小的变化，你想要保持本地在变化无常？

Question

我正在考虑将一个已有14年历史的cvs存储库(完整的历史)迁移到mercurial。我想我已经完成了所有的技术转换，但是我仍然有一些关于如何有效地在mercurial中工作的问题。

在个别开发人员的cvs沙箱(包括我自己的沙箱)中，我看到了很多地方未提交的更改，这些更改还没有准备好推送到主线。我的理解是这是件坏事。我对hg的大多数实验表明，没有承诺的改变是一件坏事。不能与他们合并就足够了。所以我想知道的是在日常编码中使用mercurial的其他人是如何处理它的。当更新存储库时，如何处理代码的不完全更改？如何处理不想与其他开发人员共享的本地更改？

Answer 1

我是这样处理的：

在我的本地存储库中，我提交了每个更改，即使我正在进行实验。如果我对这个实验没有意见，并且经过了测试，我就把它推到远程存储库。如果没有，它将留在我的本地存储库中(或者返回到旧版本)。

这个想法是，远程存储库只包含我的项目的工作的、经过测试的版本。

Answer 2

有几件事我要补充。

一是建议合理使用架架的工作流，该工作流与TortoiseHg一起作为标准提供。

每当我想提交当前工作目录的一部分时，我都会搁置不想提交的更改，重新编译(以确保没有搁置导致编译失败的位)，然后运行我的测试。然后我会提交完整的，工作和测试集。最后，我将运行反搁置来恢复我的更改。

如果我有更持久的更改，比如我希望我的开发机器上的配置文件总是指向本地主机端口3333，而不是生产服务器，那么我将研究如何使用Mercurial队列扩展，它是随汞和TortoiseHg一起提供的。

Answer 3

我不认为未承诺的改变本质上是一件坏事。您指的是“无法与它们合并”--如果您对某个文件进行了未提交的更改，并且您提取并更新了对该文件的更改，Mercurial将启动合并过程，就像您已经提交了它一样，然后请求进行合并。你有什么不同的意思吗？

因此，对于您还不希望与其他开发人员共享的本地更改，您有两种方法。第一种方法是保留工作副本中的更改，但不推送它们，另一种是将它们放在一边，从工作副本中删除。选择哪一个取决于您是否希望在工作时使用这些更改。

如果将它们保存在工作副本中，则传入的更改将正常工作，因此您只需避免创建传出更改，这意味着避免提交它们。如果文件是新的，那很容易--只是不要hg add它们。如果它们已经被跟踪，那么您可以明确地将它们排除在hg commit --exclude foo.txt提交之外。如果您有大量的文件要排除，或者将从许多提交中排除它们(例如，对于对本地配置文件的永久更改)，请查看排除扩展。

如果您准备将更改移到一边，则有另一组选项。最简单的方法就是在文件上使用hg diff来生成一个描述它们的补丁，您可以将它保存在安全的地方，然后当您想要返回更改时，hg patch --no-commit重新应用该修补程序。通过安装搁置延伸、阁楼延伸或其他相关设备，您可以使这一过程更加顺畅。您也可以使用队列扩展，但这是使用大锤打破螺母。您甚至可以只提交更改，然后更新回父服务器并在那里提交其他工作，将更改留在一个简单的匿名分支-- hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')中(尽管手动操作可能更容易！)。不过，你必须小心不要推那个改变。