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 实现一样，如果代码修改已经被复制过来，它将不会被重复复制。
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论