子存储库、hg 克隆和符号链接

发布于 2024-10-07 03:47:54 字数 761 浏览 3 评论 0原文

我对 Mercurial 很陌生,我读过很多关于这个主题的文章,但我一直无法找到明确的答案。

mercurial 指南 说:“为了提高效率,只要源和目标位于同一文件系统上(请注意,这仅适用于存储库数据,不适用于工作目录)。”

Repository wiki 页面 表示:“与 .据说存储库根目录中的 hg 目录位于工作目录中”。

现在,要在主存储库中“链接”子存储库,我会这样做:

hg init main
cd main
echo subrepo = ../subrepo > .hgsub
hg clone ../subrepo subrepo           # (1)
hg add
hg ci -m "initial rev of the main repo"

上面的定义是否意味着我在执行 (1) 时实际上正在创建 subrepo副本 ??或者我只是创建一个到 ../subrepo 的符号链接?根据ls的输出,它是一个实际的副本。但这对我来说听起来很奇怪......如果有人能对这个主题有所了解,我将不胜感激。

I'm quite new to mercurial, I've read a lot on this topic but I've been unable to find a clear answer.

The mercurial guide says: "For efficiency, hardlinks are used for cloning whenever the source and destination are on the same filesystem (note this applies only to the repository data, not to the working directory)."

The Repository wiki page says: "All of the files and directories that coexist with the .hg directory in the repository root are said to live in the working directory".

Now, to "link" a subrepo in a main repo I do:

hg init main
cd main
echo subrepo = ../subrepo > .hgsub
hg clone ../subrepo subrepo           # (1)
hg add
hg ci -m "initial rev of the main repo"

Does the definition above mean that I'm actually creating a copy of subrepo when I perform (1)?? Or am I creating just a symlink to ../subrepo? According to the output of ls, it is an actual copy. But it sounds so strange to me... If someone could put a bit of light on this subject, I'd appreciate.

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

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

发布评论

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

评论(2

悸初 2024-10-14 03:47:54

首先,Mercurial的那部分,我不是专家,但这是我所理解的。

不,您没有创建到整个目录的链接。相反,文件在其中被硬链接。

这意味着保留磁盘上的空间以保持目录结构独立,但文件都是相同的,因为它们只是克隆的,因此它们被构造为返回原始文件的链接。

当您开始通过 addcommit (ci) 命令操作存储库时,Mercurial 会破坏硬链接并构建单独的文件对于每个,按需。

现在,这纯粹是一个技术问题,你不需要知道或关心这个。如果它更容易,只需将克隆视为原始存储库的完整副本、单独的文件等等。硬链接部分只是为了节省相同内容的磁盘空间。

由于典型的项目有许多文件,并且典型的变更集仅更改几个文件,并且克隆的典型原因是您将进行一组固定的更改,因此硬链接是有意义的,因为存储库目录中的许多文件在存储库的生命周期内将与原始版本 100% 相同。

对于那些不这样做的人,所有这些都由 Mercurial 默默地为您处理。

First of all, that part of Mercurial, I'm not an expert, but here's what I've understood.

No, you didn't create a link to the whole directory. Instead, files were hardlinked inside it.

This means that space on disk is reserved to keep your directory structure separate, but the files are all identical, because they were just cloned, so they are constructed as links back to the original.

When you start manipulating the repository, through your add or commit (ci) commands, then the hardlinks are broken by Mercurial and separate files are constructed for each, on demand.

Now, this is purely a technical thing, you don't need to know or care about this. If it makes it easier, just think of a clone as a complete copy of the original repository, separate files and all that. The hardlink part is just to save diskspace for the things that are the same.

Since a typical project has many files, and a typical changeset only changes a few files, and a typical reason to clone is that you're going to do a fixed set of changes, hardlinks makes sense since many of the files in the repository directories will be 100% identical to their original for the lifetime of the repository.

For those that aren't, all of that is silently handled by Mercurial for you.

避讳 2024-10-14 03:47:54

让我们首先看看当您在不讨论子存储库的情况下进行克隆时会发生什么。当您

$ hg clone A B

这样做时,Mercurial 将为 A/.hg/store/data 中的文件创建硬链接。因此,如果跟踪一个名为 x 的文件,那么在克隆之后,您将看到该文件

A/.hg/store/data/x.i

B/.hg/store/data/x.i

是硬链接的 - 这意味着这两个文件名实际上引用了同一文件。正如 Lasse 指出的,这是明智的做法,因为您可能永远不会对 x 克隆提交更改,因此没有理由为 制作两个不同的 xi 文件AB 克隆。另一个优点是,创建硬链接比复制文件要快得多,特别是在 xi 非常大的情况下:硬链接是恒定时间操作。

在上面的示例中,您将子存储库 subrepo 添加到 main 存储库。子存储库由两部分组成:

  1. 子存储库本身。这就是您创建时创建的内容

    $ hg 克隆 ../subrepo
    
  2. 子存储库元数据时创建的内容。这是您存储在 .hgsub 文件中的内容。您必须告诉 Mercurial 您想要子存储库的位置以及 Mercurial 可以从哪里克隆它。

您询问是否复制或符号链接存储库,您肯定复制(克隆)了它,正如您也使用 ls 确认的那样。之后,您向 Mercurial 添加了一些元数据,告诉它可以在哪里找到子存储库。这与普通文件系统意义上的符号链接无关,它只是 Mercurial 的一些元数据。

Let us start by looking at what happens when you clone without talking about subrepositories. When you do

$ hg clone A B

then Mercurial will make hard links for the files inside A/.hg/store/data. So if a file called x is tracked, then after the clone you will see that

A/.hg/store/data/x.i

and

B/.hg/store/data/x.i

are hard linked -- this means that the two filenames really refer to the same file. As Lasse points out, this is smart since you might never commit a change to x clone, and so there is no reason to make two different x.i files for the A and B clones. Another advantage is that it is much faster to make a hard link than to copy a file, especially if x.i is very large: the hard link is a constant time operation.

In your example above you are adding a subrepository subrepo to the main repository. A subrepository consist of two things:

  1. the subrepository itself. This what you creates when you do

    $ hg clone ../subrepo
    
  2. the subrepository meta data. This is what you store in the .hgsub file. You must tell Mercurial where you want the subrepository and where Mercurial can clone it from.

You ask if you copy or symlink the repository, and you certainly copied (cloned) it, as you have also confirmed with ls. Afterwards you added some meta data to Mercurial that tells it where it can expect to find the subrepository. This has nothing to do with a symbolic link in the normal filesystem sense, it is just some meta data for Mercurial.

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