Mercurial(分布式版本控制系统)

　　Mercurial是一款功能强大的分布式版本控制系统，软件具备了初始化项目、添加文件并跟踪他们、保存更改、复制和移动文件、修复早期版本中的错误、使用共享存储库、删除历史记录等丰富的功能，Mercurial提供可扩展的源和版本控制管理系统，可以适应任何类型的项目，无论其大小和贡献者的数量。它以Python创建，为所有主要平台提供可分发的二进制文件，帮助开发人员完成工作，其具备了简单易用、功能完善等特点，有需要的用户赶紧到本站下载体验吧！

软件功能

　　灵活的自动修订控制系统

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

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

　　控制台界面和扩展文档

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

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

　　Mercurial的命令

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

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

软件特色

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

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

　　这是变更集ID的来源。变更集ID是160位 唯一描述变更集及其在中的位置的标识符 改变历史，无论它在哪台机器上。这是用户表示为40位十六进制数。就是这样往往不实用，Mercurial会接受任何明确的子串 指定版本时的那个数字。它通常也会打印这些数字是“简短形式”，这是前12位数字。

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

　　最后，标签是已分配的任意字符串与变更集ID的对应关系。

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

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

　　如果另一个开发人员对她的存储库进行了更改，则可以执行 她使用hg pull命令更改了您的存储库。如果您已对存储库进行了更改，并希望对其进行传输 到另一个存储库（比如说，到共享存储库），你会这样做 使用hg push命令。

安装方法

　　1、下载并解压软件，得到安装程序，其分为32位与64位安装包，根据电脑系统进行选择。

　　2、阅读许可协议，勾选【I accept the agreement】的选项，再点击【next】进入下一步的安装。

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

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

　　5、选择附加任务，用户可以根据需要勾选。

　　6、准备安装，单击【install】按钮执行安装操作。

　　7、弹出如下的信息界面，点击【next】。

　　8、完成Mercurial的安装，点击【finish】结束安装。

使用说明

　　使用Mercurial存储其数据

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

　　事实上，只要知道读取的时间和地点，我们就应该始终能够通过一次读取来完成。这是索引的来源。每个revlog都有一个索引，其中包含文本的特殊散列（nodeid），其父项的散列，以及我们需要读取的重新定位数据的位置和数量。因此，通过一次读取索引和一次读取数据，我们可以按时间重建与对象大小成比例的任何版本。

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

　　Revlog用于表示文件，清单和变更集的所有修订。具有大量修订的典型对象的压缩对于诸如清单之类的对象，对于诸如项目makefile之类的事物而言可以从100到1变化到超过2000到1。

　　Mercurial处理二进制文件

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

　　Windows行结尾与Unix行结尾

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

　　。

　　计算Mercurial差异和增量

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

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

　　存储清单和变更集

　　一个清单简直就是在给定的所有文件的清单修订与沿项目的nodeids相应的文件修订。因此，抓取项目的给定版本意味着只需查找其清单并重建其指向的所有文件修订版。

　　一个变更是在办理登机手续变更与变化的描述和类似的用户和日期一些元数据中的所有文件的列表。它还包含清单相关修订版的nodeid。

　　计算Mercurial哈希值

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

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

　　存储库完整性检查

　　每次检索到revlog对象时，都会根据其哈希检查其完整性。它也偶然被底层zlib压缩使用的Adler32校验和双重检查。

　　运行'hg verify'解压缩并重新构建存储库中每个对象的每个修订版，并使用这些内容交叉检查所有索引元数据。

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

常见问题

　　我应该在我的错误报告中包含哪些内容？

　　有足够的信息来重现或诊断错误。如果可以的话，试试吧使用' hg -v '和' hg --debug '开关来弄清楚到底是什么Mercurial正在做。

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

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

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

　　考虑正常的合并情况，当工作目录是干净的 - 也就是说，没有未提交的更改，而hg diff不产生输出。Mercurial将正在合并的修订版（“其他分支”）与工作目录的修订版（“本地分支”）相结合。它将此合并的结果留在您的工作目录中供您测试。批准合并结果时，您提交它。关键洞察力：所有这些变化都是合并的结果，即它们来自本地头部，或其他头部，或它们的组合（合并）。

　　现在考虑如果工作目录已经包含修改过的文件会发生什么 - 也就是说，hg diff产生输出。在这种情况下，Mercurial有三个表示担心：你未提交的变更，本地负责人和另一个负责人。这将是不连贯的，因为Mercurial只允许一次合并两个头（变更集）。您可能认为Mercurial应该在某处保存您未提交的更改，以便您可以执行合并然后恢复原始更改，但这会带来额外的复杂性。（如果您的合并影响了与未提交的更改相同的代码，那会怎么样？这意味着在您提交首先尝试进行的合并后，工作目录中将需要另一个合并！）因此Mercurial不会尝试; 当你尝试合并两个头时，它要求你有一个干净的工作目录。

　　简而言之，Mercurial试图将一个操作与另一个操作分开（本地更改与合并），并避免将工作目录置于某种特殊状态（暂停本地更改，直到它们可以与当前修订组合）。

　　围绕此限制有四种方法：

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

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

　　创建一个新的工作目录

　　抛开你的改变

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

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

　　原稿=`pwd`

　　hg clone -u。。../temp-merge

　　cd ../temp-merge

　　hg合并

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

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

　　hg push＃到你以前的存储库

　　cd $ pwd

　　hg update＃到新的合并变更集

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

　　差异+补丁

　　使用Shelve扩展

　　MQ（Mercurial Queues）（不适合初学者！）

　　我在推送时得到“没有剩余空间”或“超出磁盘配额”

　　我在推送时得到“没有剩余空间”或“超出磁盘配额”，但是有足够的空间或/并且我对远程hg存储库所在的设备没有配额限制。

　　问题可能来自于mercurial使用/ tmp（或由环境变量$ TMPDIR，$ TEMP或$ TMP定义的目录之一）来解压缩在线路上收到的捆绑。然后，解压缩可以达到设备限制。

　　您当然可以将$ TMPDIR设置为默认shell配置文件中远程的另一个位置，但它可能会被除mercurial之外的其他进程使用。

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

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

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

　　我提交了一个大型二进制文件/文件如何永久删除它们？

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

　　hg status显示已更改的文件，但hg diff不显示！

　　当文件内容或标志相对于任一父项更改时，hg状态报告。hg diff仅报告相对于第一个父项的更改内容。您可以使用--git选项查看标记信息，以使用-r将hg diff和deltas相对于另一个父项进行查看。

　　如何确保只有已知人员可以提交/提交/提交/推送更改？

　　由于Mercurial允许用户使用他们的存储库克隆做任何他们想做的事情，与他们喜欢的任何人共享它们，Mercurial通常不会对提交施加限制（但是，请注意，提交集中版本控制系统和Mercurial的提交操作并不完全一样）同一件事情）。然而，关键操作实际上是推动操作，因为它是在这样的点上，在存储库克隆之间传递变化，并且“官方”存储库希望能够拒绝“未经验证的”变更集：即，来自未知或未被授权贡献的人的变更集变化。因此，尽管许多克隆可能存在于任何个人（已知或未知）做他们喜欢的事情，但任何进入“官方”存储库的工作都必须有“经过验证”或“授权”的人推动该工作; 该人有效地对工作的适用性负责。

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

　　（虽然可以说，在集中式版本控制系统中，每个人都登录到中央存储库，验证提交者的任务更容易，但也不能保证其他人提交的工作不会以某种方式包含由毕竟，可以通过其他方式共享存储库的内容 - 也许用户可以让系统上的其他人直接在文件系统中访问他们的结账 - 从而通过“授权”提交工作的行为人不能保证他们自己完成所有工作，只是他们对此负责。）

更新日志

　　Mercurial 5.1：

　　定期发布功能。可用的新功能概述。这是定期安排的季度功能发布。

　　命令：

　　书签：还可以使书签缓存取决于更改日志

　　书签：竞赛条件的实际修复删除书签

　　书签：实际上会触发比赛，删除测试中的书签

　　书签：撤销修复删除竞赛的尝试

　　书签：如果设置了新配置，则将书签保留在.hg / store中

　　书签：在编写文件时使用上下文管理器

　　书签：使用正确的商店进行“模糊检查”

　　分支：如果从非分支头cset关闭分支，则中止

　　Branchcache：将最大提示存储在for循环中的变量中

　　命令：删除对旧版^ cmd注册（API）的支持

　　提交：添加--force-close-branch标志以关闭非头部变更集

　　提交：添加一个检查是否正在尝试关闭已经关闭的分支头

　　提交：在每次成功调用后添加打印文件状态的功能

　　提交：允许--interactive在命名目录时再次工作（issue6131）

　　提交：改进合并的更改日志的文件字段

　　提交：在中止分支关闭时使错误消息更具体

　　提交：尊重 - 不与--amend组合编辑

　　移植：移植abortgraft和readgraft移动到cmdutil

　　帮助：检查子主题是否存在，如果不存在则引发错误（issue6145）

　　日志：添加配置以使'hg log -G'始终topo-sorted

　　日志：标记topo-sorted set

　　日志：传递getcopies（）函数而不是getrenamed（）到显示器（API）

　　合并：如果未完成操作，则禁止合并中止（issue6160）

　　补丁：对最后一行提示使用一个固定大小的短消息（issue6158）

　　推送：按下已关闭的分支时添加了明确的警告消息（issue6080）

　　标签：避免双重翻转列表

　　验证：还在验证运行期间检查完整清单有效性

　　验证：引入“级别”的概念

　　验证：引入一个实验性的--full标志

　　核心：

　　文档：手册页和HTML帮助现在可以分类命令命令，而不是按字母顺序排序

　　Minirst：支持带有标记''''的subsubsubsubsections（标题级别5）

　　Revlog：添加选项以跟踪预期的压缩上限

　　Revlog：加快isancestor

　　Templatekw：make {file_ *}与两个合并父项进行比较（issue4292）

　　Templater：支持旧式关键字（API）

　　Util：make util.dirs（）和util.finddirs（）包含根目录（API）

　　扩展：

　　Largefiles：最后一行提示<40 english chars（issue6158）

　　Mq：修复合并检测方法

　　Rebase：修复空文件副本的内存重新定位

　　Rebase：调整内存工作甚至w /脏工作目录的描述

　　搁架：修改--interactive上的帮助文本

　　取消搁置：添加交互模式

　　取消搁置：添加空间以提供帮助

　　取消搁置：将来自ui.warn的Corruptedstate错误消息更改为error.Abort

　　取消搁置：将不合适的交互标记为实验性的

　　未排序：

　　中止：增加对移植物的支持

　　中止：增加了对hetedit的支持

　　中止：增加了对合并的支持

　　中止：增加了对rebase的支持

　　Abort：增加对unshelve的支持

　　自动化：对运行Linux测试的初始支持

　　Bisect：不要因重写提交而崩溃

　　Blackbox：禁用非常详细的日志记录（issue6110）

　　Catapipe：添加对COUNTER事件的支持

　　更改日志：为null修订定义changelogrevision.p [12]副本

　　更改日志：修复变更集中空副本条目的处理

　　更改日志：可选择在变更集附加项中存储已添加和已删除的文件

　　继续：增加对rebase的支持

　　继续：增加对unshelve的支持

　　副本：仅在pathcopies（）的末尾过滤无效副本（issue6163）

　　副本：跟踪没有源文件的合并库中的副本（issue6163）

　　Debugrevlog：修复空数据的平均大小计算（issue6167）

　　Drawdag：将副本信息写入更改集时不要崩溃

　　Extdata：当我们得到一个revset解析错误时，避免在子进程内崩溃

　　扩展：不使用'ui'参数（API）删除对extsetup（）的支持

　　Filemerge：提出最后一行提示<40 english chars（issue6158）

　　Graphmod：删除对混合父/祖父母样式（BC）的图线的支持

　　清单：通过使用pure删除已删除的文件来避免损坏（issue5801）

　　匹配：删除未使用的匹配.__ iter__实现（API）

　　匹配：使用''而不是'。' 用于根目录（API）

　　Procutil：允许runbgcommand的调用者假定进程启动

　　Remotefilelog：检查是否在getrenamedfn（）覆盖中启用了RFL

　　Remotefilelog：在getrenamedfn（）覆盖中处理变更集中的副本

　　Remotefilelog：我们即将获取文件时的日志

　　Remotefilelog：告诉runbgcommand不阻止子进程启动

　　Root：添加对-Tformatter选项的支持

　　Sslutil：将对SSLKEYLOGFILE的支持添加到wrapsocket

　　Sslutil：certifi返回的fsencode路径（issue6132）

　　Statecheck：增加了对STATES的支持

　　子目录：最后一行提示<40 english chars（issue6158）

　　测试：使remotefilelog-gcrepack中的grep模式可移植（issue6122）

　　测试：解决libressl与错误字符串不同的问题（issue6122）

　　跟踪：添加对发射计数器的支持

　　Worker：支持具有返回值的函数的并行化

　　Zsh：也为chg启用完成支持

　　行为改变：

　　Graphmod：删除对混合父/祖父母样式（BC）的图线的支持

　　内部API更改：

　　命令：删除对旧版^ cmd注册（API）的支持

　　扩展：不使用'ui'参数（API）删除对extsetup（）的支持

　　日志：传递getcopies（）函数而不是getrenamed（）到显示器（API）

　　匹配：删除未使用的匹配.__ iter__实现（API）

　　匹配：使用''而不是'。' 用于根目录（API）

　　Templater：支持旧式关键字（API）

　　Util：make util.dirs（）和util.finddirs（）包含根目录（API）