使用 Mercurial 克隆或拉取标签后如何获取标签变更集?

发布于 2024-09-24 23:08:25 字数 885 浏览 0 评论 0原文

正如明确指南恰当地指出的(搜索“标签和克隆”):

当您运行 hgclone -r foo 来克隆从标签 foo 开始的存储库时,新的 克隆不会包含比标签引用的版本更新的任何版本, 包括创建标签的修订版本。结果是你会 在新版本中准确获取项目历史的正确子集 存储库,但不是您可能期望的标签

这意味着新克隆中的 hg Tags 不会显示 foo 标签。如果您在添加 foo 标记之前进行克隆,并且执行 hg pull -r foo,也会发生同样的情况。

(题外话:标签是我在 hg 中唯一不太明白的东西。我知道将其放入变更集中有好处(例如合并),但将元数据与源代码混合总是感觉很奇怪。

)显然,我要求的是一种自动化的方式,而不是作为单独的手动步骤拉取标签更改集。

我知道我可以在 incoming 挂钩中检查这种情况(因此它适用于克隆和拉取),或者包装 clonepull

但有更好/更简单的方法吗?


UPDATE hg bug tracker 已经存在此问题

As the definite guide aptly points out (search for "Tags and cloning"):

When you run hg clone -r foo to clone a repository as of tag foo, the new
clone will not contain any revision newer than the one the tag refers to,
including the revision where the tag was created. The result is that you'll
get exactly the right subset of the project's history in the new
repository, but not the tag you might have expected.

It means hg tags in your new clone does NOT show the foo tag. Same thing happens if you had cloned before foo tag was added, and you do hg pull -r foo.

(Digression: tag is about the only thing I don't quite get in hg. I understand there are advantages (e.g. merge) in putting it in a changeset, but it always feels weird to have meta data mixed with source code.)

It should be obvious that I'm asking for an automated way, instead of pulling the tag changeset as a separate manual step.

I know I could check for this scenario in an incoming hook (so it works for both clone and pull), or wrap clone and pull.

But is there a better/easier way?


UPDATE hg bug tracker already has this issue.

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

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

发布评论

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

评论(4

神妖 2024-10-01 23:08:25

您想要使用 bash 和嵌入式 Perl 脚本进行大规模破解吗?嗯,就是这样...

#!/bin/bash
if [[ "$1" == "" || "$2" == "" || "$3" == "" ]]; then
  echo 'hgclonetag <src> <tgt> <tag>'
  exit 1;
fi

REV=`hg log -R $1 --rev $3: --limit=2 | perl -F: -lane 'if (/:([\dA-Fa-f]+)$/) {print $F[2] if defined($flag);$flag=1;}'`
hg clone --rev $REV $1 $2

这会调用 hg log 命令来提取第一个与标签相关的修订版之后的修订号,然后克隆到该修订版。

目前这不适用于远程存储库:不幸的是,-R 开关仅适用于本地存储库。

You want a giant hack with bash and an embedded Perl script? Well, here it is...

#!/bin/bash
if [[ "$1" == "" || "$2" == "" || "$3" == "" ]]; then
  echo 'hgclonetag <src> <tgt> <tag>'
  exit 1;
fi

REV=`hg log -R $1 --rev $3: --limit=2 | perl -F: -lane 'if (/:([\dA-Fa-f]+)$/) {print $F[2] if defined($flag);$flag=1;}'`
hg clone --rev $REV $1 $2

This invokes the hg log command to extract the revision number after the first tag-related revision and then clones to this revision.

Currently this does not work on remote repos: -R switch only works on local repos unfortunately.

夏至、离别 2024-10-01 23:08:25

我想得越多,我就越相信正确的答案是克隆所有内容并更新到标签,这可以一步完成:

hg clone http://host/path#tagname

这样你就可以获得所有内容,然后< code>hg update 到标记名,将您的工作目录设置为正确的版本。考虑到增量压缩不一定要大得多,如果是的话,您可以从以前的本地克隆自动克隆其中的大部分。

The more I think about it the more I'm convinced the right answer is to just clone everything and update to the tag, which can be done in a single step:

hg clone http://host/path#tagname

That gets you everything and then does hg update to tagname which sets your working directory to the correct revision. Given delta compression that's not necessarily much larger, and if it is you can automate cloning the bulk of it from a previous local clone.

許願樹丅啲祈禱 2024-10-01 23:08:25

有一个后克隆挂钩。它被称为 post-clone (hgrc 手册页显示 post-ANYCOMMANDpre-ANYCOMMAND 存在),尽管正如您所指出的,您也可以使用*changegroupupdate 挂钩,因为克隆使用这两个函数(除非您使用 -U 抑制更新)。

如果您仅需要参考,那么只需添加一个 --localtag 即可获得名称,但没有额外的变更集。 您可以轻松地将类似的东西

hg clone -r tagname URL
hg tag --local tagname

构建到 shell 别名中。

除此之外,不一定能保证有一种方法可以拥有修订版 X 以及修订版 X 被标记的修订版,而不会同时具有您不想要的其他修订版,因为标签可能是在其他工作完成后应用的。当然,您可以始终更新到“X”并在您的工作目录中包含后续变更集,但它们仍然会在您的存储库中。

老实说,一旦我发现当你克隆一个标签时,标签名称不会很长,我承认一开始这让我很困惑,我发现没有必要将变更集与标签在其中。

There is a postclone hook. It's called post-clone (the hgrc manpage shows a post-ANYCOMMAND and pre-ANYCOMMAND exist) though as you pointed out you could also use *changegroup or update hooks too, since clone uses both of those functions (unless you suppress update with -U).

What about just adding a --localtag so you have the name but not the extra changeset if you need it for reference only. Something like

hg clone -r tagname URL
hg tag --local tagname

which you could easily build into a shell alias.

Other than that there's not necessarily guaranteed to be a way to have revision X and the revision where revision X is tagged without also having other revisions you don't want since the tag could have been applied after other work was done. You can, of course, always update to 'X' and to have subsequent changesets in you working dir, but they'll still be in your repo.

Honestly, once I figured out that the tag name doesn't come a long when you clone up to a tag, which I admit confused the heck out of me at first, I didn't find any need to bring along the changeset with the tag in it.

ぇ气 2024-10-01 23:08:25

是的,这可以通过后克隆/拉钩来完成,但是有一些骗子。

首先,它仅适用于本地存储库,因为您无法获取远程存储库中的标签列表。

其次,处理克隆/拉取参数和选项并不简单。 (对于克隆,我需要获取目标存储库,-r-u-U。对于拉取,我需要 -r-u。)我尝试使用 fancyopts,但它无法处理全局选项,这些选项在调度中处理掉。我设法破解调度,只给我命令的参数和选项,但感觉和看起来都很丑。

使用命令包装器可以消除第二个问题。

我希望有一天 hg 会添加一个选项来克隆和拉取以干净地完成它。

Yes it can be done by post-clone/pull hooks, but there are a couple of crooks.

First, it only works for local repo, since you can't get the list of tags in a remote repo.

Second, dealing with clone/pull arguments and options is not trivial. (For clone I need to get the target repo, -r, -u, -U. For pull I need -r and -u.) I tried to use fancyopts, but it can't deal with global options, which are processed away in dispatch. I managed to hack dispatch to give me only the args and opts of a command, but it feels and looks ugly.

Using command wrapper would eliminate the second problem.

I hope one day hg will add an option to clone and pull to do it cleanly.

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