已删除的文件是否仍可通过 hg 克隆下载?

发布于 2024-10-16 13:09:52 字数 288 浏览 2 评论 0原文

在我们的 Mercurial 存储库中,我们添加了一个非常大的文件(并进行了 hg 推送),然后删除了该大文件(并进行了另一次推送)。

现在,如果有人进行 hg 克隆,他们还会拉下那个大文件吗?我知道它不会出现在他们的工作目录中,因为它已被删除,但该文件是否仍会被拉下来并存储在 Mercurial 内部存储中?

我想确保人们不必拉下该文件。我了解到真正大的文件应该存储在 Mercurial 之外,所以我删除了该文件。但我想知道人们是否仍然会拉下大文件 - 在这种情况下我想我会从头开始重新创建存储库。

In our Mercurial repo we added a really big file (and did an hg push), then deleted the big file (and did another push).

Now if someone does an hg clone will they still pull down that big file? I know it won't appear in their working directory as it was deleted, but will the file still be pulled down and stored in Mercurial internal storage?

I'd like to ensure people don't have to pull down the file. I've learned that really big files should be stored outside of Mercurial, so I deleted the file. But I was wondering if people will still be pulling down the big file - in which case I guess I will recreate the repository from scratch.

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

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

发布评论

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

评论(2

醉生梦死 2024-10-23 13:09:52

当然它仍然会在存储库中。

您始终可以更新回较旧的版本,如果您更新回提交文件时获得的版本,它将尽显其荣耀。

有两种方法可以缓解这种情况(当您提交时,而不是现在):

  • 大文件扩展之一,这些扩展本质上是将大文件添加到辅助存储库并将两者链接起来,这样,如果您更新到修订版,文件不存在,并且您还没有该文件,因此不会更新。 IE。它更像是一种“按需”拉取方式。
  • 如果文件从不更改,请使其在网络上可用,并创建某种指向它的链接而不是完整副本。

现在,您有四个选择:

  • 删除更改​​集添加了该文件以及其后的所有变更集。您可以使用 Mercurial 队列扩展来做到这一点。请注意,您需要在所有克隆中执行此剥离操作。如果只有一个用户将历史记录中有该文件的存储库推回到中央克隆,您就可以恢复更改集。
  • 手动从头开始重建存储库
  • 使用 hg Convert 命令和一些过滤,可以使用 --filemap 选项
  • 保持原样。多大了,会有什么大问题吗?

请注意,手动或通过 hg Convert 重建存储库将使所有克隆失效。任何尝试从旧克隆推送到新中央克隆的人都会收到一条有关不相关存储库的消息。如果您的任何用户不够聪明,没有意识到强制推送是一个坏主意,那么您在使用这种方法时就会遇到问题。

Of course it will still be in the repository.

You can always update back to older revisions, and if you update back to the revision you got when you committed the file, it'll be there in all its glory.

There are two ways to mitigate this (when you're committing, not now):

  • One of the big-files extensions, these essentially add big files to a secondary repository and link the two, so that if you update to a revision where the file doesn't exist, and you don't already have it, it will not get updated. ie. it's more a "on-demand" style of pulling
  • If the file never changes, keep it available on the network and just create some kind of link to it instead of a full copy

Right now, you got four options:

  • Strip away the changeset that added the file, and all the changesets that came after it. You can do that using the Mercurial Queues extension. Note that you need to do this stripping in all clones. If just one of your users push back the repository that has that file in its history to the central clone, you have the changesets back.
  • Rebuild the repository from scratch manually
  • Using the hg convert command and some filtering, the --filemap option can be used for this
  • Leave it as is. How big is it, will be much of a problem?

Note that rebuilding the repository, either manually or through hg convert will invalidate all clones. Anyone trying to push to your new central clone from an old clone will get a message about unrelated repositories. If any of your users are stupi^H^H^H^H^Hnot smart enough to realize that forcing the push is a bad idea, then you will have problems with this approach.

亢潮 2024-10-23 13:09:52

是的,该文件仍在历史记录中。如果您想完全删除它,则需要使用 Mercurial 队列 - 请参阅 Mercurial wiki 上的编辑历史记录

请记住,当修订 ID 发生更改时,这会破坏克隆。

Yes, the file is still in the history. If you want to delete it completely, you need to use Mercurial Queues — see Editing History on Mercurial wiki.

Just keep in mind this breaks clones as revision IDs change.

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