如何始终了解 Mercurial 中的所有标签? [英] How can I always know about all tags in Mercurial?

问题描述

我不使用 Mercurial，但我想开始，所以我正在阅读它.我广泛使用的唯一 SCM 系统是 CVS.我读过的关于 Mercurial 的大部分内容都是有道理的，而且听起来不错.但我对它的标签方式时而感到震惊和困惑.

I don't use Mercurial, but i'd like to start, so i'm reading about it. The only SCM system i've used extensively is CVS. Most of what i've read about Mercurial makes sense, and sounds good. But i'm alternately shocked and perplexed by that way it does tags.

标签只是变更集的昵称(变更集"实际上是指变更集产生的状态).凉爽的.从标签到变更集 ID 的映射存储在 .hgtags 文件中.也很酷..hgtags 文件是版本化的.

A tag is just a nickname for a changeset (and by 'changeset' we really mean the state resulting from the changeset). Cool. The mapping from tags to changeset IDs is stored in the .hgtags file. Also cool. The .hgtags file is versioned.

什么?

这有很多违反直觉的后果.例如，如果我提交了一个我想要标记的变更集(例如，将形成版本 1.0 的代码)，我必须在标记后再次提交，以将更新的标记文件放入存储库.如果我稍后更新到该标记的变更集，则工作副本将不包含该标记的任何知识.如果我做了一些工作，从而建立了一个新分支(例如，对于错误修复，朝着 1.1 前进)，那么该分支将不知道它所生长的标签.除非我手动复制它.

This has lots of counterintuitive consequences. For instance, if i commit a changeset which i then want to tag (say, the code which will form release 1.0), i have to commit again after tagging, to put the updated tag file into the repository. And if i then update to that tagged changeset at some later date, the working copy won't contain any knowledge of that tag. If i do some work, thus founding a new branch (say, for bugfixes, heading towards 1.1), that branch won't have any knowledge of the tag from which it grew. Unless i copy it over manually, that is.

随着原始主干和我的新分支上的开发继续进行，并创建标记以标记重要的变更集(主干上的 2.0 版本，分支上的 1.1 和 1.2 错误修复版本)，两个分支都将在无知中继续进行另一个分支的标签.所以，如果我完成了一个分支的工作，并且想要切换到另一个分支上的某个特定变更集(例如，我完成了 1.2 错误修复版本，但现在必须从基于 2.0 的 2.1 错误修复开始)，我现在被填满了.我当前的变更集不知道 2.0！

And as development continues both on the original trunk and my new branch, with tags being created to mark important changesets (the 2.0 release on the trunk, the 1.1 and 1.2 bugfix releases on the branch), both branches will proceed in ignorance of the other branch's tags. So, if i finish working on one branch, and want to switch to some particular changeset on another (say, i finish the 1.2 bugfix release, but now have to start on the 2.1 bugfix, based on 2.0), i am now stuffed. My current changeset doesn't know about 2.0!

我能做什么?

• 我可以请在 2.x 分支上工作的人读出 2.0 的实际变更集 ID，并明确使用它，但这太可怕了.
• 我可以命名我的分支，也可以使用标签，这样我就可以跳到 2.x 分支的头部，从而了解新标签，然后跳回 2.0 标签.假设分支与标签不同，是普遍可见的——是这样吗?即使是这样，这似乎也很笨重.
• 我可以在存储库之外维护一个全局 hgtags 文件，并使用几个钩子在更新时拉入副本，覆盖本地副本，并将任何更改复制回犯罪.我不确定这在多用户环境中如何工作，开发人员正在将更改推送到共享存储库；我可能需要一个单独的存储库来存放 hgtags 文件.
• 我可以使用本地标签，它位于版本控制机制之外，从而避免了整个问题.与共享全局标签一样，我必须建立一种机制来在开发人员之间同步 localtags 文件.

• I can ask someone who's working on the 2.x branch to read out the actual changeset ID for 2.0, and use that explicitly, but this is appalling.
• I could name my branches, as well as using tags, so that i could hop across to the head of the 2.x branch, thus learning about the new tags, and then skip back to the 2.0 tag. Assuming that branches, unlike tags, are universally visible - is that the case? Even if it is, this seems clunky.
• I could maintain a single global hgtags file outside the repository, and use a couple of hooks to pull in a copy on an update, overwriting the local copy, and to copy back any changes on a commit. I'm not sure how this would work in a multi-user environment, where developers are pushing changes to a shared repository; i might need a separate repository just for the hgtags file.
• I could use local tags, which stand outside the versioning mechanism, and so avoid the whole problem. As with shared global tags, i would have to put in place a mechanism to synchronise the localtags file between developers.

这些解决方案似乎都不是很好.我该怎么办?

None of these solutions seem totally great. What should i do?

这里的一个假设是我正在使用单个存储库中的命名分支来管理分支，而不是每个分支的存储库.如果我做后者，情况会更好吗?

An assumption here is that i'm managing branches using named branches in a single repository, rather than repository-per-branch. Would the situation be any better if i did the latter?

推荐答案

对 .hgtags 文件进行版本控制可以让您

Versioning the .hgtags file allows you to

• 编辑标签并查看谁编辑了它们(以及为什么他们留下了正确的提交信息)
• 使用正常机制在存储库之间传输标签

但是，这里发生了一些混乱.

However, there are some confusion going on here.

• 你写的

[...] 如果我稍后更新到该标记的变更集，则工作副本将不包含该标记的任何知识.[...]

[...] And if i then update to that tagged changeset at some later date, the working copy won't contain any knowledge of that tag. [...]

这是错误的，标签是从所有 heads 中的 .hgtags 文件中收集的.这意味着您可以更新到旧标签(hg update 0.1)，仍然可以看到所有标签(hg tags).

That is wrong, tags are collected from the .hgtags files found in all heads. That means that you can update to an old tag (hg update 0.1) and still see all your tags (hg tags).

你问树枝是否普遍可见.是的，它们是——命名分支的名称可以在需要指定变更集的任何上下文中使用，标签也可以.

You ask if branches are universally visible. Yes they are -- the names of named branches can be used in any context where you need to specify a changeset, as can tags.

在开始使用它们之前，请确保您了解命名分支的含义.它们实际上不是制作错误修复分支所必需的.您可以选择简单地返回 (hg update 1.0) 并修复错误然后提交.这将创建一个新的头，您的开发线朝着 1.1 发展(这会给您 多个头).因此，您无需创建命名分支即可将新的开发分支添加到您的存储库.

Make sure you understand what named branches are before you begin using them. They are actually not necessary for making a bugfix branch. You can instead choose to simply go back (hg update 1.0) and fix the bug and then commit. That will create a new head, which your line of development towards 1.1 (this gives you multiple heads). So you don't have to create a named branch to add a new branch of development to your repository.

拥有多个头完全等同于拥有多个克隆.你甚至可以来回转换:你可以使用

Having multiple heads is completely equivalent to having multiple clones. You can even convert back and forth: you can use

% hg clone -r X-head repo repo-X

将 X-head 变更集及其祖先从 repo 中的其他变更集中解开.您可以通过简单地将所有变更集拉到一个大克隆中来组合多个克隆.

to untangle the X-head changeset and its ancestors from the other changesets in repo. And you can combine multiple clones by simply pulling all changesets into one big clone.

命名分支相似，但又不同.它们允许您在每个变更集中嵌入一个命名.因此，您的历史记录中可以有多个名为foo"的变更集.当您执行 hg update foo 时，您最终将处于这些变更集的最顶端.这样，命名分支就起到了一种浮动标签的作用.

Named branches are similar, yet different. They allow you to embed a named in each changeset. So you can have several changesets in your history with the name "foo". When you do hg update foo you will end up at the tip-most of these changesets. In this way, named branches function as a kind of floating tag.

如果您对更改集的永久标签的想法感到不舒服，您可以尝试 书签扩展.这也将为您提供可用于更新的浮动标签"，但它们不会永久成为历史记录的一部分，因为它们没有版本控制.

If you are uncomfortable with the idea of a permanent label for your changesets, you can instead try the bookmarks extension. That will also give you "floating tags" which you can use for updating, but they wont be permanently part of the history since they aren't versioned.

我希望这会有所帮助.

这篇关于如何始终了解 Mercurial 中的所有标签?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！