Mercurial:轻量级副本/重命名

发布于 2024-11-06 12:22:58 字数 1226 浏览 0 评论 0 原文

来自 Mercurial wiki - GSoC Ideas 2010

项目想法

轻量级副本/重命名

(非常困难 - 一个成功的学生 将成为 Mercurial 的专家 存储格式及传输 协议)

目前不支持复制和重命名 太高效了。 Mercurial 复制 将源文件复制/重命名为新文件 目标文件的初始修订版 它的内部历史存储。为了 重命名,这尤其是 违反直觉,因为重命名一个大的 文件按文件的大小增长存储 尺寸。如果是水银的话就更好了 有某种方式引用 新文件的现有修订版, 同时保留向后 兼容性和有限 I/O 检索修订的保证。 请参阅 issue883 进行讨论。 有一个来自旧尝试的 mq 它位于此处

抱歉,如果这是一个明显的问题(我不擅长英语和编程)。我想知道“轻量级副本”是什么意思?

这是否意味着:当实现此功能时,具有相同内容(相同哈希值不同文件名)的多个文件将在存储库中仅存储一次(就像Git一样)?


更新:

感谢大家的回答。 Mercurial 的一位开发人员 - tonfa 也在 这个答案

穴居人:当轻量级副本出现时 已实施,将两个文件具有相同 内容(相同哈希值不同 名称)在存储库中仅存储一次 (就像 Git 一样)?

tonfa:不,此功能尚未计划 (这会破坏其他优化 最小化磁盘访问)

From Mercurial wiki - GSoC Ideas 2010:

Project Ideas

Lightweight copies/renames

(very difficult - a successful student
will become an expert in Mercurial's
storage format and transmission
protocol)

Copies and renames currently are not
too efficient. Mercurial copies the
copied/renamed source file to the new
initial revision of the target file in
its internal history store. For
renames, this is especially
counter-intuitive, as renaming a large
file grows the store by the file's
size. It would be better if Mercurial
had some way of referring to the
existing revision from the new file,
while preserving backwards
compatbility and bounded I/O
guarantees for retrieving revisions.
See issue883 for discussion.
There's an mq from an old attempt at
this located here.

Sorry if this is an obvious question (I'm not good at English and programming). I'm wondering, what does the "Lightweight copies" mean?

Is it mean: when this feature is implemented, multiple files with same content (same hash value different file names) will be stored only once in repository (just like Git)?


Update:

Thanks everyone for your answers. One of Mercurial's developers - tonfa also answered this question in a comment of this answer:

caveman: When light-weight copies are
implemented, will two files with same
content (same hash value different
names) store only once in repository
(just like Git)?

tonfa: no, this feature isn't planned
(it would break other optimizations to
minimize disk access)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

烟若柳尘 2024-11-13 12:22:58

现在,当您复制文件时,会在存储库中创建一个新文件,其中包含刚刚复制的文件的压缩快照。我们的想法是对其进行设置,以便副本以某种方式引用旧文件,然后具有基于该旧文件的修订日志条目,而不必拥有自己的快照来作为修订日志条目的基础。

这不会像 git 的工作方式那样。改变 Mercurial 以这种方式工作将非常有趣,而且不是最简单的提议。

Right now, when you copy a file, a new file is created in the repository that contains a compressed snapshot of the file you just copied. The idea would be to set it up so the copy references the old file somehow and then has revlog entries based on that instead of having to have its own snapshot to base the revlog entries off of.

This will not be like how git works. Changing Mercurial to work that way would be really interesting, and not the easiest proposition.

桃气十足 2024-11-13 12:22:58

我最好说复制/重命名的文件不会存储现在两倍的空间,而只会指向相同的修订版本。

不确定对于单独添加的具有相同内容的文件是否如此。根据描述,它们将被视为完全独立的文件,并占用 2 倍的空间。

I'd better say that copied/renamed file wouldn't store as twice space more as it now, but will just point to the same revision.

Not sure that this will be true for the files added separately with the same content. According to the description they will be treated as completely independent files and will occupy 2x space.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文