Mercurial 6.441 正式安装版分布式版本控制工具

Mercurial是一款专业的分布式版本控制工具。编程人员都不会错过的专业分布式版本控制软件Mercurial。该软件具有丰富的功能，用于初始化项目，添加文件并跟踪它们，保存更改，复制和移动文件，修复早期版本中的错误，使用共享存储库，删除历史记录等。Mercurial提供可扩展的源代码和版本控制管理。适应任何类型的项目，无论其规模和贡献者数量如何。它使用Python创建，并为所有主要平台提供可分发的二进制文件，以帮助开发人员完成工作。它具有易于使用和功能齐全的特点。需要它的用户赶紧到该网站下载体验！

常见问题:

我应该在错误报告中包括什么？

有足够的信息来重现或诊断该错误。如果可以，请尝试使用'hg -v'和'hg --debug'开关来确定Mercurial在做什么。

如果您可以在简单的存储库中重现该错误，则将非常有帮助。最好的方法是创建一个简单的shell脚本来自动化该操作过程，然后可以将其添加到我们的测试套件中。

当我未提交更改时，为什么Mercurial不让我合并？

如果hg merge失败并且消息中止：未提交未提交的更改，则意味着合并两个分支的正常过程无法继续。

考虑工作目录干净时的正常合并情况，也就是说，没有未提交的更改，并且hg diff不产生输出。 Mercurial将要合并的修订（“其他分支”）与工作目录的修订（“本地分支”）组合在一起。它将合并的结果留在您的工作目录中供您测试。批准合并结果后，您将其提交。关键见解：所有这些更改都是合并的结果，即它们来自本地主管或其他主管或组合（合并）。

现在考虑如果工作目录已经包含修改后的文件，即hg diff产生输出，该怎么办。在这种情况下，Mercurial涉及三个问题：您未承诺的更改，本地负责人和另一个负责人。这将是不连贯的，因为Mercurial一次只允许合并两个标头（变更集）。您可能认为Mercurial应该将未提交的更改保存在某个位置，以便您可以执行合并然后还原原始更改，但这会带来额外的复杂性。 （如果您的合并与未提交的更改影响相同的代码，该怎么办？这意味着在您提交首次尝试的合并后，将需要在工作目录中再次进行合并！）因此，Mercurial将不会尝试；当您尝试合并两个标题时，它要求您具有一个干净的工作目录。

简而言之，Mercurial尝试将一个操作与另一个操作（本地更改和合并）分开，并避免将工作目录置于特殊状态（挂起本地更改，直到它们可以与当前修订版本合并为止）。

围绕此限制有四种方法：

放弃未提交的更改（仅当它们是临时的一次性更改且不再需要它们时才适用）

提交您的更改（仅在完成，工作准备就绪并提交后才适用）

创建一个新的工作目录

搁置您的更改

前两个应该是不言自明的。

创建一个新的工作目录需要更多的开销，但是它既简单又通常很快（除非您的存储库很大）。例如：

原始=`pwd`

汞克隆-u。 。 ../temp-merge

CD ../ temp-merge

汞合并

[...测试合并...]

Hg commit -m“与...合并”

汞推＃到您以前的存储库

cd $ pwd

汞更新＃到新的合并更改集

对于各种解决方案，将半成品更改留在一边是一个有趣的问题，包括但不限于：

差异+补丁

使用搁置扩展

MQ（Mercurial队列）（不适合初学者！）

推送时出现“没有可用空间”或“超出磁盘配额”

推送时出现“没有可用空间”或“超出磁盘配额”的信息，但是有足够的空间或/，并且对于远程hg存储库所在的设备没有配额限制。

问题可能来自Mercurial使用/ tmp（或由环境变量$ TMPDIR，$ TEMP或$ TMP定义的目录之一）解压缩它在行上收到的内容

束。后，减压可以达到设备极限。

当然，您可以将$ TMPDIR设置为默认外壳程序配置文件中的另一个远程位置，但是它可以被Mercurial以外的进程使用。

当我“ hg push”到远程存储库时，为什么工作目录似乎为空？

当您将更改推送到存储库时，包含该存储库的工作目录不会更改。但是，更改存储在历史记录中，并且在对存储库执行操作时可用。因此，即使普通目录列表为空，在这样的远程存储库中运行的命令（例如hg log）也会显示完整的历史记录。 （将hgweb用于存储库发布也可以利用此历史记录，而不必在工作目录中使用一组文件。）

显然，您可以运行hg update来使文件出现在这样的存储库中，但是除非您真的想在这样的目录中工作，否则保持目录“空”可能是一件很整洁的事情。这可以通过在存储库的目录中发出hg update null命令来完成。

我提交了一个大的二进制文件/文件，如何将其永久删除？

如果要删除不应添加的文件，请使用带有--filemap选项的ConvertExtension，将Mercurial存储库“转换”为另一个Mercurial存储库。如果要在删除文件之前保持历史记录相同，则需要确保设置convert.hg.saverev = False。如果convert.hg.saverev = True，则转换将在附加标题下将源版本ID嵌入到新版本中（如果通过hg log --debug可见）。

汞状态显示更改的文件，但汞差异不显示！

当文件内容或徽标相对于任何父级更改时，汞状态报告。 hg diff仅报告相对于第一个父级的更改。您可以使用--git选项查看标签信息，使用-r查看相对于另一个父级的hg差异和增量。

如何确保只有已知的人才能提交/提交/提交/推送更改？

由于Mercurial允许用户使用其存储库克隆来执行所需的任何操作，并与他们喜欢的任何人共享它们，因此Mercurial通常不会对提交施加任何限制（但是，请注意，集中版本控制系统的提交和Mercurial提交的操作是不完全相同）。但是，关键操作实际上是推送操作，因为在这一点上，更改会在存储库的克隆之间转移，并且“官方”存储库希望能够拒绝“未验证的”更改集：即，来自未知或变更集未经授权做出贡献的人员的变更。因此，尽管在任何个人（已知或未知）中可能存在许多克隆，以完成他们喜欢的工作，但是进入“官方”资源库的任何工作都必须有“经过验证”或“授权”的人员来推广该工作；人们对工作的适用性负有有效责任。

尝试提供验证功能的扩展是commitsigs扩展。

（尽管可以说，在集中式版本控制系统中，每个人都登录到中央存储库，并且更容易验证提交者的任务，但是并不能保证不会以某种方式包含其他人提交的工作毕竟，您可以通过其他方式共享存储库的内容-也许用户可以让系统上的其他人直接访问他们在文件系统中的签出-因此通过“授权”提交作品的演员无法保证他们会自己完成所有工作，但由他们负责。）

使用说明:

使用Mercurial存储其数据

Mercurial中的基本存储类型是revlog。 revlog是命名对象的所有修订的集合。每个修订以完全压缩或以前版本的压缩二进制增量存储。根据重建文件所需的数据量来决定何时存储完整版本。这使我们能够确保无论存储多少修订版本，都无需读取大量数据即可重建对象。

实际上，只要我们知道阅读的时间和地点，我们就应该总是能够通过一次阅读来完成阅读。这是索引的来源。每个修订日志都有一个索引，其中包含文本的特殊哈希（nodeid），其父哈希以及我们需要读取的重定位数据的位置和数量。因此，通过读取索引并读取一次数据，我们可以及时重建与对象大小成比例的任何版本。

同样，revlog及其索引仅被附加。这意味着O（1）也寻求添加新版本。

Revlog于指示文档，列表和变更集的所有修订。对于清单等对象和项目makefile等对象，具有大量修订版本的典型对象的缩率可能从100变为1，超过2000变为1。

水星处理二进制文件

Core Mercurial跟踪但从未修改文件的内容，因此它是二进制安全的。有关解释文件内容的命令的更多讨论，请参见BinaryFiles，例如merge，diff，export和annotate。

Windows行尾和Unix行尾

有关将文件提交到资源库时自动将Windows行尾转换为Unix行尾并在更新工作空间时自动转换回Unix行尾的技术，请参见Win32TextExtension。这不是默认的Mercurial行为，需要用户编辑其配置文件才能打开它。在行尾采用这种策略可能意味着启用挂钩，以防止不合规的提交进入您的存储库，这反过来又迫使人们贡献代码来启用扩展。

计算水银差和增量

Mercurial差异的计算方法与传统diff算法产生的差异非常不同（但输出当然与补丁完全兼容）。该算法是基于Python的difflib的优化的C实现，旨在产生比“最小”更易于人类阅读的差异。同样的算法也用于内部增量压缩。

在研究增量压缩算法的过程中，我们发现此实现比基准测试中的竞争对手更简单，更快，并且比传统diff算法的理论“最小”差产生的增量更小。这是因为传统算法假定插入，删除和不变元素的成本是相同的。

存储列表和变更集

列表只是给定的所有文件列表的修订版，以及与项目中的节点ID对应的文件的修订版。因此，获取项目的给定版本意味着仅查找其列表并重建其指向的所有文件修订。

变更是签到变更和变更说明中所有文件的列表，以及用户和日期相似的一些元数据。它还包含列表的相关修订的节点ID。

计算水银哈希

Mercurial对对象的内容及其父对象的哈希值进行哈希处理，以创建唯一标识对象内容和历史的标识符。由于它避免了将对象恢复到较早状态时可能发生的图形循环，因此极大地简化了历史记录的合并。

所有文件修订版都具有关联的哈希值（节点ID）。这些是列出列表中给定项目的修订，以及列表哈希中的更改。变更集哈希（变更集ID）也是变更集内容及其父变量的哈希，因此它唯一地标识项目的整个历史记录。

储存库完整性检查

每次检索revlog对象时，都会根据其哈希检查其完整性。 Adler32校验和仔细检查还无意中使用了它

zlib压缩。

运行“ hg verify”以解压缩并重建存储库中每个对象的每个修订版，并使用它们来交叉检查所有索引元数据。

但是，仅凭这一点还不足以确保有人没有篡改存储库。为此，您需要加密签名。

软件特色：

Mercurial通常允许您引用三个版本：按修订号，按变更集ID和按标签。

版本号与在本地存储库中提交的简单十进制数相对应。重要的是要理解，这种分类可能因机器而异。 Mercurial的分布式，分散式架构。

这是变更集ID的来源。变更集ID是一个160位的标识符，它唯一地描述了变更集及其在变更历史记录中的位置，无论它在哪台机器上。用户用40位十六进制数表示。这通常是不切实际的，当任何明确的子字符串指定版本时，Mercurial都会接受该数字。通常还打印这些数字是“短格式”，即前12位数字。

与其他Mercurial用户讨论修订时，应始终使用某种形式的变更集ID而不是本地修订号，因为他们的系统可能具有不同的版本号。

最后，标签是任何分配的字符串和更改集ID之间的对应关系。

在许多其他版本控制系统中，所有开发人员都将更改提交到集中式存储库。在Mercurial，每个开发人员通常都在自己的存储库中工作。 Mercurial的基本概念是在存储库之间转移变更集。这是通过克隆，推动和拉动完成的（另请参见“通信更改”）。

要在现有项目上启动任务，开发人员通常会这样做。使用hg clone命令创建存储库的本地副本。此操作将创建一个包含所有内容及其所有历史记录的新存储库文件。

如果其他开发人员对其存储库进行了更改，则可以使用hg pull命令执行她并更改存储库。如果您对存储库进行了更改，并且想要将其传输到另一个存储库（例如，共享存储库），则可以使用hg push命令来进行。

安装方式;

1.下载并解压缩该软件以获取安装程序，该程序分为32位和64位安装程序包，然后根据计算机系统进行选择。

2.阅读许可协议，选中[我接受协议]选项，然后单击[下一步]进入下一步安装。

3.选择安装位置，默认安装文件夹为C：\ Program Files \ Mercurial。

4.选择开始菜单文件夹，用户可以选择默认的Mercurial。

5.选择其他任务，用户可以根据需要进行检查。

6.准备安装，单击[安装]按钮以执行安装操作。

7.弹出以下信息界面，单击[下一步]。

8.完成Mercurial安装，单击[完成]以结束安装。

软件特色：

灵活的自动修订控制系统

Mercurial的目的是帮助开发人员有效地修改文档，跟踪更改并帮助团队更轻松地协作，从而显着提高生产力。它易于使用，轻巧且可完全自定义，旨在满足所有用户的需求。

使用自动修订控制模型，团队可以轻松跟踪项目的历史记录和成员，同时尝试解决同一问题，比较每个解决方案并选择最佳解决方案。换句话说，他们可以相互协作，更轻松地解决不兼容问题，并在发生错误时恢复到早期版本。

控制台界面和扩展文档

Mercurial是开源版本控制系统领域的重要参与者。与直接竞争对手不同，它具有易于理解的命令集和易于学习的声誉。另外，Mercurial可以从其他各种存储库导入修订历史，例如，使用CVS，Git或Subversion创建的存储库。

Mercurial不需要依赖项，因此部署很容易。它使用命令控制台启动其主应用程序，显示其每个命令和说明。如果您不熟悉版本控制系统，请详细阅读详细文档以帮助您入门。

水星的命令

Mercurial可以克隆存储库并管理由大量贡献者提交的变更集，以便任何团队成员都可以浏览特定的修订。您可以从其他存储库中提取更改，也可以将更改推送到另一个存储库中。

您可以将更改保存在本地，也可以轻松地通过网络共享更改，以便其他用户可以浏览更改集并提供自己的建议。