Mercurial 2.0 携 Largefile 插件发布

  • Alex Blewitt
  • 金明

2011 年 11 月 18 日

话题:语言 & 开发

Selenic发布了Mercurial 2.0,这是他们三个月来对该 DVCS 工具的常规升级。

本次发布带来了Largefile 插件——一种将集中式数据存储带入迥异的分布式版本管理系统的方式。鉴于 Mercurial 的Revlog存储机制并不能很好地契合二进制大文件的存储,Largefile 插件提供了一个集中式存储,二进制大文件可以从那里按需下载。

如果二进制大文件经常会被更新,那么在任何 DVCS 中存储它们,都可能会出现问题;甚至即便二进制文件可以通过增量压缩(比如,仅仅存储变更的部分)来存储,大文件也会很快地使资源库膨胀起来。此外,假如这些资源已经成为了资源库历史的一部分,它们无法在不影响内容哈希值的情况下从资源库中精简掉(prune),因此也就无法修改资源库的版本。

取决于使用的版本管理系统的不同而不同,是否将大资源文件存放在不同的分支(比如,不经常获取[fetch]的分支)会影响到复制出的资源库(而不是源资源库)。Mercurial 的 Largefile 插件使用了不同的方法,在复制出的资源库中提供了(从效果上)指向大文件的符号链接。

当前检出[checkout]的版本并没有必要包含这些大文件,它们并不会随着复制[clone]或者获取[fetch]/推送[push]的操作而下载。但是,如果检出某个包含了一个或者多个这样大文件链接的版本,Mercurial 会打开一个单独的链接以从集中式存储服务器下载内容。很明显,这意味着为了检出资源库的某些版本,Mecurial 需要能够连接到集中式存储服务器,但是本地的 Mercurial 复本将会保持上次下载的大文件的缓存,而且假如它们已经被下载,就可以不用再去从服务器获取。

hg add命令有了一个新选项--large,允许指定文件为大文件(因此把该文件存入“集中式的、但是缓存的、按需下载的”存储)。或者,可以设置一个确切的文件大小(默认是大于 10Mb)或者使用命名模式(比如,*.zip)来自动标记大文件。注意,资源库格式必须通过hg lfconvert命令升级,以利用新格式的优势。同时注意,追踪大文件状态的dirstate命令,在 Mercurial 2.0 中目前是被限制在 2Gb 以内,但有希望在 2.0 发布之后会发布补丁。

Mercurial 2.0 同时也带来了graft命 令——给 Mercurial 实现了 cherry pick 功能。它使用了合并[merge]的机理以判断哪些修改应该被呈现,然后再将它们零碎地移植过来,而不创建一个新的合并节点。与其他的 cherry-pick 实现一样,如果代码修改已经被复制过来,它将不会被重复复制。

查看英文原文Mercurial 2.0 Released with LargeFiles extension

语言 & 开发